Tối ưu hóa quá trình di chuyển dữ liệu trong MongoDB: Kỹ thuật chia lại cấu trúc cho tốc độ và khả năng mở rộng

Cần phân đoạn bộ sưu tập 2TB và phân phối dữ liệu trên tất cả các phân đoạn của bạn trong vòng chưa đầy 24 giờ? Tận dụng việc chia lại phân đoạn để tăng tốc độ di chuyển dữ liệu của bạn!

Trong bài đăng này, chúng tôi sẽ đề cập đến một kỹ thuật gọi là “phân chia lại thành phân đoạn”, sử dụng phân chia lại phân đoạn để truyền dữ liệu qua các phân đoạn trong cụm của bạn một cách nhanh chóng.

Chúng tôi sẽ đi qua:

1. Cân nhắc trước và trong quá trình di chuyển.
2. Cách bắt đầu, theo dõi và hủy bỏ quá trình di chuyển dữ liệu nhanh hơn.

Nếu bạn chưa quen với sharding hoặc muốn xem lại cách MongoDB cung cấp khả năng mở rộng theo chiều ngang, vui lòng xem hướng dẫn Hướng dẫn sử dụng MongoDB .

Mục lục

• Lý lịch
• Những lợi ích của reshard-to-shard là gì?
• Khi nào tôi nên sử dụng reshard-to-shard?
• Khi nào tôi không nên sử dụng reshard-to-shard?
• Điều kiện tiên quyết để chia lại phân đoạn là gì?
• Tổng quan về kỹ thuật reshard-to-shard
• Ví dụ về phân đoạn lại thành phân đoạn
• câu hỏi thường gặp

Lý lịch

Khi một tập hợp ban đầu được phân đoạn trên một cụm nhiều phân đoạn, bộ cân bằng sẽ bắt đầu di chuyển dữ liệu từ phân đoạn chứa tập hợp được phân đoạn gần đây sang các phân đoạn khác trong cụm để phân phối đồng đều tập hợp trên các phân đoạn. Khi bộ cân bằng đang di chuyển dữ liệu, một phân đoạn chỉ có thể tham gia vào một lần di chuyển tại một thời điểm, bất kể có bao nhiêu bộ sưu tập cần di chuyển. Có nghĩa là trong cụm 3 phân đoạn, mỗi lần chỉ có hai phân đoạn có thể di chuyển dữ liệu giữa chúng. Việc chia lại phân đoạn không có cùng giới hạn do sự khác biệt về thực thi nội bộ.

Vì việc chia lại phân đoạn đang ghi lại tất cả dữ liệu nên nó có thể ghi dữ liệu song song trên tất cả các phân đoạn trong cụm, tăng thông lượng và giảm đáng kể thời gian di chuyển dữ liệu giữa các phân đoạn so với những gì bộ cân bằng có thể thực hiện. Chia lại phân đoạn sẽ xây dựng một bộ sưu tập mới với khóa phân đoạn mới ở chế độ nền trên mỗi phân đoạn trong khi vẫn giữ bộ sưu tập hiện có của bạn để ứng dụng của bạn sử dụng. Sau khi tất cả các tài liệu được sao chép vào bộ sưu tập mới, quá trình chuyển đổi sẽ xảy ra. Bộ sưu tập hiện có với khóa phân đoạn cũ bị loại bỏ để nhường chỗ cho bộ sưu tập mới được tạo bởi hoạt động phân đoạn lại.

Những lợi ích của reshard-to-shard là gì?

Đầu tiên, nó nhanh hơn nhiều! Bằng cách tận dụng phân đoạn lại, một khách hàng đã có thể phân đoạn và phân phối bộ sưu tập 3,5 TB của họ trên 4 phân đoạn trong 22,5 giờ. Quá trình tương tự sẽ mất 30 ngày nếu để phương pháp di chuyển khối mặc định của bộ cân bằng.

Thứ hai, nó tác động tối thiểu đến khối lượng công việc của bạn! Sau khi bộ cân bằng di chuyển dữ liệu, nó phải tiến hành thao tác dọn dẹp được gọi là xóa phạm vi trên phân đoạn đã tặng dữ liệu vì chỉ một phân đoạn có thể sở hữu từng tài liệu cụ thể. Xóa phạm vi là một hoạt động chuyên sâu về I/O có thể ảnh hưởng đến hiệu suất của cụm của bạn. Việc chia lại phân đoạn không cần tiến hành xóa phạm vi vì nó tiến hành loại bỏ tập hợp cũ sau khi chuyển sang tập hợp mới bằng khóa phân đoạn mới.

Thứ ba, bạn tự động lấy lại dung lượng ổ đĩa của mình! Bằng cách loại bỏ bộ sưu tập cũ, nó giải phóng không gian lưu trữ để bất kỳ bộ sưu tập nào sử dụng mà không phải thực hiện thao tác chẳng hạn như gọn nhẹ . Điều này có nghĩa là bạn có thể thu nhỏ dung lượng lưu trữ nhanh chóng và dễ dàng hơn sau khi thao tác nếu muốn.

Ví dụ: một khách hàng đã tiêu thụ gần 2,8 TB trên shard0 trước khi hoạt động phân chia lại phần bộ sưu tập lớn nhất của họ hoàn tất.

Khi quá trình chia lại hoàn tất, 1,9TB dung lượng lưu trữ đã được trả lại ngay lập tức! Họ đã chuyển từ tiêu thụ 2,7 TB dung lượng lưu trữ lên 873 GB dung lượng lưu trữ.

Khi nào tôi nên sử dụng reshard-to-shard?

Trả lời: Khi ban đầu bạn sắp xếp một bộ sưu tập có kích thước bất kỳ trên bất kỳ số lượng phân đoạn nào.

Có một số tình huống trong đó việc cân bằng có thể nhanh hơn (ví dụ: dưới 100 GB), nhưng bạn vẫn phải tính đến việc xóa phạm vi và lấy lại bộ nhớ thông qua đồng bộ hóa nhỏ gọn hoặc ban đầu. Do đó, nếu bạn có khả năng, chúng tôi khuyên bạn nên chia lại phân đoạn cho dù bộ sưu tập bạn muốn phân mảnh lớn đến mức nào.

Khi nào tôi không nên sử dụng reshard-to-shard?

Bạn không nên sử dụng chiến thuật chia lại phân đoạn khi:

• Ứng dụng của bạn không thể chịu được tình trạng tắc nghẽn ghi trong hai giây để cho phép chuyển sang bộ sưu tập được phân chia lại.

  • Thời lượng ghi có thể bị chặn đối với bộ sưu tập được phân chia lại theo mặc định là hai giây, có một tham số có thể định cấu hình có thể sửa đổi thời lượng chặn.

    
    

• Bộ sưu tập của bạn là bộ sưu tập theo chuỗi thời gian
  • Nếu bạn cố gắng chia lại bộ sưu tập theo chuỗi thời gian, bạn sẽ nhận được thông báo lỗi cho biết việc chia lại bộ sưu tập theo chuỗi thời gian không được hỗ trợ.

Đối với các tình huống được liệt kê ở trên, hãy sử dụng phương pháp truyền thống để phân tách bộ sưu tập và để bộ cân bằng di chuyển dữ liệu.

Điều kiện tiên quyết để chia lại phân đoạn là gì?

1. Cụm MongoDB chạy MongoDB 5.0 trở lên
2. Bạn phải chọn một khóa phân đoạn thích hợp cho bộ sưu tập của mình.
3. Xây dựng các chỉ mục cần thiết để hỗ trợ cả khóa phân đoạn tạm thời và khóa phân đoạn mong muốn.
4. Ngoài ra, vì bạn sẽ sử dụng phân đoạn lại để tăng tốc độ di chuyển dữ liệu, vui lòng tự làm quen với yêu cầu và hạn chế resharding .

Để thực hiện thành công thao tác chia lại phân vùng, cụm của bạn phải có:

• 1,2 lần kích thước bộ sưu tập trên mỗi phân đoạn có sẵn trên mỗi phân đoạn.
  • Ví dụ: nếu bạn đang phân đoạn bộ sưu tập 1TB trên 4 phân đoạn, thì kích thước bộ sưu tập được phân đoạn là 250 GB trên mỗi phân đoạn khi được phân phối trên 4 phân đoạn. Bạn muốn có tối thiểu 300 GB dung lượng lưu trữ trên mỗi phân đoạn.
• Công suất I/O dưới 50%
• Mức sử dụng CPU dưới 80%

Khách hàng sử dụng Atlas có cụm không đáp ứng các yêu cầu về bộ nhớ, I/O và CPU để thực hiện phân đoạn lại có thể dễ dàng tạm thời mở rộng quy mô cụm của họ và/hoặc tùy chỉnh lưu trữ để tăng tài nguyên của cụm của họ để cho phép hoạt động phân chia lại thành công. Họ có thể trở lại bình thường sau khi hoạt động đã được hoàn thành.

Tổng quan về kỹ thuật reshard-to-shard

Có hai bước rất đơn giản để thực hiện thao tác chia lại phân đoạn thành phân đoạn:

1. Phân mảnh thành Khóa phân mảnh tạm thời
2. Phân đoạn lại thành khóa phân đoạn mong muốn của bạn

Tại sao trước tiên tôi lại phân đoạn thành khóa phân đoạn tạm thời và điều đó sẽ không gây hại cho ứng dụng của tôi?

Hãy giải thích!

Bước một: phân đoạn với khóa phân đoạn tạm thời

Hiện tại, việc chia lại phân đoạn không hỗ trợ chia lại kích thước thành cùng một khóa phân đoạn (việc này sẽ thành công dưới dạng "không hoạt động" vì bạn đã ở trạng thái mong muốn). Để khắc phục hạn chế này, kỹ thuật phân đoạn lại thành phân đoạn yêu cầu cố ý phân đoạn thành một khóa phân đoạn tạm thời khác với khóa phân đoạn mong muốn. Do MongoDB hỗ trợ cho cả phân đoạn phạm vi và phân đoạn băm, khóa phân đoạn tạm thời có thể được sửa đổi rất ít so với khóa phân đoạn mong muốn mà bạn đã chọn cho bộ sưu tập của mình.

Khóa phân đoạn tạm thời nên chọn một chiến lược phân vùng khác chỉ cho một trong các trường khóa phân đoạn của bạn. Do giới hạn đối với một số truy vấn chẳng hạn như updateOne(), updateMany(), deleteOne(), v.v. yêu cầu truy vấn bao gồm khóa phân đoạn, bạn sẽ sử dụng một chiến lược phân vùng khác. MongoDB chỉ sử dụng các chiến lược phân vùng như một cách để xác định cách phân phối dữ liệu của bạn trên các phân đoạn trong cụm của bạn và nó không thay đổi các giá trị trong tài liệu. Có nghĩa là ứng dụng của bạn có thể sử dụng updateOne hoặc truy vấn khác yêu cầu khóa phân đoạn với cả hai chiến lược phân vùng.

Ví dụ: nếu khóa phân đoạn mong muốn mà bạn đã chọn cho bộ sưu tập của mình là:

 {"_id": "hashed"}

Khóa phân đoạn tạm thời để sử dụng ban đầu cho bộ sưu tập của bạn phải là:

 {"_id": 1}

Đối với các khóa phân đoạn phức hợp, chỉ một trong các trường khóa phân đoạn của bạn cần sử dụng chiến lược phân vùng khác. Ví dụ: nếu khóa phân đoạn mong muốn mà bạn đã chọn cho bộ sưu tập của mình là:

 { launch_vehicle: 1, payload: 1}

Khóa phân đoạn tạm thời của bạn phải là:

 { launch_vehicle: 1, payload: "hashed"}

Chiến thuật phân đoạn lại thành phân đoạn yêu cầu phân đoạn lại ngay lập tức vào khóa phân đoạn mà bạn sẽ sử dụng lâu dài sau khi quá trình phân đoạn ban đầu của bộ sưu tập bằng khóa phân đoạn tạm thời hoàn tất. Điều này giữ hơn 99% dữ liệu trên một phân đoạn trong khi hoạt động chia lại phân đoạn thực thi, giúp giảm đáng kể tác động của các truy vấn quảng bá.

Nếu bạn muốn đảm bảo 100% dữ liệu của mình nằm trên một phân đoạn, bạn có thể tắt bộ cân bằng trước khi phân đoạn lần đầu bộ sưu tập bằng khóa phân đoạn tạm thời. Việc vô hiệu hóa bộ cân bằng đảm bảo không có sự di chuyển nào xảy ra trước khi quá trình chia lại phân đoạn được bắt đầu. Chúng tôi sẽ đề cập đến cách bạn có thể tắt bộ cân bằng trong ví dụ bên dưới.

Vì bạn sẽ tạo cả hai chỉ mục cho khóa phân đoạn tạm thời và mong muốn của mình, trong khi quá trình phân chia lại đang được tiến hành, các truy vấn sử dụng khóa phân đoạn mong muốn của bạn sẽ hoạt động hiệu quả vì chúng có thể tận dụng chỉ mục cho khóa phân đoạn mong muốn trong khi bộ sưu tập của bạn tạm thời được phân vùng bằng khóa phân đoạn tạm thời của bạn.

Bước hai: chia lại thành khóa phân đoạn mong muốn của bạn

Bước thứ hai là thực hiện thao tác chia lại kích thước bình thường ngoại trừ việc bạn đang tận dụng tác dụng phụ của cách hoạt động của quá trình chia lại kích thước để mang lại lợi ích cho bạn.

Resharding có bốn giai đoạn chính:

• Khởi tạo - bộ sưu tập đang trải qua phân đoạn lại được lấy mẫu và phân phối dữ liệu mới dựa trên khóa phân đoạn mới được xác định.

  
  

• Chỉ mục - hoạt động chia lại phân đoạn tạo một bộ sưu tập phân đoạn tạm thời trống mới trên tất cả các phân đoạn dựa trên khóa phân đoạn mới và xây dựng các chỉ mục bao gồm các chỉ mục khóa không phải phân đoạn hỗ trợ bộ sưu tập hiện có.

  
  

• Sao chép, Bắt kịp và Áp dụng - tài liệu được sao chép vào các phân đoạn theo khóa phân đoạn mới và bất kỳ sửa đổi nào đối với tài liệu trong khi thực hiện thao tác chia lại phân đoạn đều được áp dụng.

  
  

• Cam kết - bộ sưu tập tạm thời được đổi tên và thay thế bộ sưu tập đang được chia lại và bộ sưu tập cũ hiện tại bị loại bỏ.

Sau khi xem xét các giai đoạn trên, bạn có thể thấy cách bạn sẽ nhận được lợi ích của việc di chuyển dữ liệu nhanh, bộ sưu tập được phân đoạn được phân bổ đồng đều trên các phân đoạn của bạn sau khi thao tác hoàn tất và tất cả dung lượng lưu trữ được giải phóng trong một lần.

Khi hoạt động chia lại phân đoạn hoàn tất, bạn có thể tiến hành các hoạt động dọn dẹp, chẳng hạn như loại bỏ chỉ mục khóa phân đoạn tạm thời và thu nhỏ cụm và/hoặc bộ nhớ của bạn để phù hợp với nhu cầu ở trạng thái ổn định của bạn.

Ví dụ về phân đoạn lại thành phân đoạn

Giả sử bạn đang làm việc trên một ứng dụng sẽ theo dõi máy bay thương mại để khách hàng có thể được thông báo nếu chuyến bay của họ có khả năng bị hoãn. Bạn đã nghiên cứu các mẫu truy vấn của ứng dụng và xem xét những thuộc tính nào góp phần tạo nên một khóa phân đoạn tốt.

Khóa phân đoạn bạn đã chọn cho bộ sưu tập của mình là:

 { airline: 1, flight_number: 1, date: "hashed" }

Với khóa phân đoạn được xác định, bạn có thể bắt đầu kiểm tra các điều kiện tiên quyết để thực hiện thao tác phân đoạn lại thành phân đoạn. Đầu tiên, bạn tạo khóa phân đoạn tạm thời của mình. Như đã nêu trước đây, bạn muốn khóa phân đoạn tạm thời của mình là phiên bản được sửa đổi rất ít của khóa phân đoạn mong muốn.

Vì vậy, khóa phân đoạn tạm thời bạn đã chọn là:

 { airline: 1, flight_number: 1, date: 1}

Tiếp theo, bạn xây dựng các chỉ mục để hỗ trợ cả khóa phân đoạn tạm thời và khóa cuối cùng.

Các chỉ mục có thể được tạo bằng Mongo shell thông qua lệnh db.collection.createIndexes() :

 db.flight_tracker.createIndexes([ {"airline": 1, "flight_number": 1, date: "hashed"}, {"airline": 1, "flight_number": 1, date: 1} ])

Các bản dựng chỉ mục có thể được theo dõi bằng mongo shell thông qua lệnh sau:

 db.adminCommand({ currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] })

Nếu bạn muốn đảm bảo rằng không có sự di chuyển nào xảy ra giữa quá trình phân đoạn bộ sưu tập của bạn và khi quá trình phân đoạn lại được gọi, bạn có thể tắt bộ cân bằng bằng cách chạy lệnh sau:

 sh.stopBalancer()

Nếu cụm MongoDB của bạn được triển khai trên Atlas, thì bạn có thể sử dụng giao diện người dùng Atlas để dễ dàng xem xét các số liệu có sẵn thông báo cho bạn biết rằng cụm của bạn có đủ dung lượng lưu trữ miễn phí cùng với khoảng không gian dành cho CPU và I/O để tiến hành thao tác phân chia lại phân đoạn.

Nếu không có đủ dung lượng lưu trữ hoặc khoảng trống I/O, bạn có thể mở rộng quy mô lưu trữ. Đối với trường hợp thiếu khoảng trống CPU, bạn có thể mở rộng cụm. Việc mở rộng cả lưu trữ và cụm được thực hiện dễ dàng thông qua giao diện người dùng Atlas.

Việc truy cập cấu hình cụm rất đơn giản và có thể được thực hiện từ màn hình tổng quan của nhóm, màn hình này hiển thị tất cả các cụm đã triển khai cho nhóm.

Với tất cả các điều kiện tiên quyết đã được đáp ứng, bạn có thể bắt đầu phần đầu tiên của quá trình chia lại phân đoạn - phân mảnh bộ sưu tập bằng khóa phân đoạn tạm thời.

Sau đó, bạn có thể sử dụng Mongo shell và lệnh sh.shardCollection() để phân đoạn bộ sưu tập:

 sh.shardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: 1} )

sh.shardCollection() sẽ trả về một tài liệu khi hoàn thành, trường ok sẽ có giá trị là 1 nếu thao tác thành công.

 { collectionsharded: 'main.flight_tracker', ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1684160896, i: 25 }), signature: { hash: Binary(Buffer.from("7cb424a56cacd56e47bf155bc036e4a4da4ad6b6", "hex"), 0), keyId: Long("7233411438331559942") } }, operationTime: Timestamp({ t: 1684160896, i: 21 }) }

Sau khi bộ sưu tập được phân đoạn, bạn có thể ngay lập tức chuyển sang phân đoạn lại bộ sưu tập!

Để phân chia lại bộ sưu tập của bạn thành khóa phân đoạn mong muốn, hãy sử dụng sh.reshardCollection() trong vỏ mongo:

 sh.reshardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: "hashed" })

Nếu bạn chạy lệnh sh.status() trong mongo shell, bạn sẽ thấy một bộ sưu tập mới ở đầu ra với định dạng tên cho bộ sưu tập mới là <db_name>.system.resharding.<UUID> . Đây là bộ sưu tập mà việc chia lại phân đoạn đang xây dựng và phân phối dữ liệu theo khóa phân đoạn mong muốn của bạn

Để theo dõi trạng thái của hoạt động chia lại phân đoạn cho bộ sưu tập Flight_tracker, bạn có thể sử dụng lệnh sau

 db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "main.flight_tracker" } } ])

Đầu ra của lệnh sẽ thông báo cho bạn biết hoạt động chia lại phân đoạn hiện đang thực hiện ở giai đoạn nào và thời gian ước tính để hoàn thành thông qua trường còn lạiOperationTimeEstimatedSecs. Xin lưu ý rằng thời gian ước tính để hoàn thành việc chia sẻ lại là không đáng kể và các hoạt động chia sẻ lại mất ít thời gian hơn đáng kể so với báo cáo!

Hoạt động chia lại phân đoạn sẽ gần hoàn tất khi kích thước dữ liệu của mỗi phân đoạn đã tăng lên bằng kích thước của bộ sưu tập được chia lại chia cho số lượng phân đoạn trong cụm. Ví dụ: bộ sưu tập 1TB được chia lại phân đoạn trên 4 phân đoạn, thao tác chia lại phân đoạn sẽ hoàn tất khi mỗi phân đoạn đã ghi 250 GB (không tính đến dữ liệu khác được chèn, cập nhật hoặc xóa trên phân đoạn).

Nếu cụm của bạn được triển khai trên Atlas, bạn cũng có thể theo dõi tiến trình của hoạt động phân chia lại kích thước thông qua Giao diện người dùng Atlas bằng cách sử dụng tab Số liệu của cụm.

• Đối với các cụm Atlas chạy MongoDB 6.0 trở lên - bạn có thể sử dụng tùy chọn hiển thị kích thước dữ liệu phân đoạn và sau đó chọn một bộ sưu tập có cú pháp <db_name>.system.resharding.<UUID> . Chế độ xem này cô lập bộ sưu tập tạm thời và sẽ chỉ hiển thị mức tăng kích thước dữ liệu của bộ sưu tập mới.

  
  

• Đối với các cụm Atlas chạy MongoDB 5.0 - bạn có thể sử dụng tùy chọn hiển thị kích thước dữ liệu logic db. Chế độ xem này không cho phép cách ly mức bộ sưu tập.

  
  

Trong khi quá trình chia lại phần đang diễn ra, ba chỉ số từ cụm mà bạn nên theo dõi chủ yếu là:

• Bộ nhớ khả dụng - tiêu thụ tất cả bộ nhớ khả dụng có thể dẫn đến sự mất ổn định của cụm
• Sử dụng CPU - sử dụng CPU cao có thể dẫn đến hiệu suất cụm bị suy giảm
• Sử dụng I/O - Sử dụng I/O vượt quá khả năng của bạn có thể dẫn đến hiệu suất cụm bị suy giảm

Nếu bạn lo ngại về việc chia lại phân đoạn ảnh hưởng tiêu cực đến cụm của mình, bạn có thể hủy ngay hoạt động chia lại phân đoạn trước khi nó đạt đến phần cam kết của quy trình thông qua lệnh sau:

 sh.abortReshardCollection("main.flight_tracker")

Nếu bạn đã tắt bộ cân bằng để đảm bảo rằng không có sự di chuyển nào xảy ra giữa quá trình phân đoạn và phân đoạn lại bộ sưu tập, hãy bật lại bộ cân bằng ngay bây giờ bằng cách sử dụng lệnh sau:

 sh.startBalancer()

Hoạt động chia lại kích thước khi kết thúc sẽ trả về nếu hoạt động thành công hay không đối với ứng dụng khách đang gọi.

Vì việc chia lại phân đoạn là một hoạt động kéo dài và bạn có thể đã đóng phiên trình bao Mongo đó, nên bạn có thể kiểm tra xem thao tác chia lại phân đoạn có còn đang thực thi hay không bằng cách sử dụng tổng hợp giám sát chia lại phân đoạn nếu bạn muốn biết thông tin chi tiết hoặc sh.status() để xem liệu bộ sưu tập tạm thời có còn xuất hiện trong đầu ra hay không. Nếu tập hợp chia lại kích thước không trả về bất kỳ thứ gì hoặc nếu bạn không thấy tập hợp tạm thời nào nữa trong đầu ra của sh.status(), thì hoạt động chia lại kích thước đã kết thúc.

Bạn có thể sử dụng db.collection.getShardDistribution để xác định xem thao tác có thành công hay không:

 db.flight_tracker.getShardDistribution()

Nếu quá trình chia lại phân đoạn hoàn tất thành công, bạn sẽ thấy kết quả đầu ra có phân bổ bằng nhau giữa các phân đoạn.

• Đối với MongoDB 6.0 và độ đồng đều cao hơn được xác định bởi kích thước dữ liệu trên mỗi phân đoạn, do đó bạn sẽ thấy lượng dữ liệu gần như bằng nhau trên mỗi phân đoạn trong đầu ra của db.collection.getShardDistribution.

  
  

• Đối với MongoDB 5.0, độ đồng đều được xác định bởi số khối trên mỗi phân đoạn, vì vậy bạn sẽ thấy số lượng khối bằng nhau trên mỗi phân đoạn trong đầu ra của db.collection.getShardDistribution.

Nếu cụm của bạn được triển khai trên Atlas, bạn có thể sử dụng Giao diện người dùng Atlas thông qua tab Số liệu để xác định xem hoạt động chia lại phân đoạn có thành công hay không.

• Đối với các cụm Atlas chạy MongoDB 6.0 trở lên - bạn có thể sử dụng tùy chọn hiển thị kích thước dữ liệu phân đoạn và sau đó chọn bộ sưu tập của bạn đã trải qua phân đoạn lại. Bạn sẽ thấy một lượng dữ liệu bằng nhau trên mỗi phân đoạn được hiển thị.

  
  

• Đối với các cụm Atlas chạy MongoDB 5.0 - bạn có thể sử dụng tùy chọn hiển thị khối và sau đó chọn bộ sưu tập của mình đã trải qua quá trình chia lại phân đoạn. Bạn sẽ thấy số lượng khối gần như bằng nhau được hiển thị trên tất cả các phân đoạn trong cụm của mình.

  
  

Đối với cả kích thước dữ liệu phân đoạn và số lượng khối, giao diện người dùng Atlas sẽ hiển thị mức tăng mạnh trong chỉ số có liên quan do việc chia lại phân đoạn bằng cách sử dụng định dạng tên bộ sưu tập là <db_name>.system.resharding.<UUID> tạm thời trước khi đổi tên và loại bỏ tên cũ bộ sưu tập bằng khóa phân đoạn cũ.

Nếu quá trình phân đoạn lại bị hủy bỏ, đầu ra của db.collection.getShardDistribution có thể sẽ hiển thị hầu hết dữ liệu trên phân đoạn mà bộ sưu tập được phân đoạn ban đầu. Việc hủy bỏ khi chia lại bộ sưu tập là rất hiếm và có khả năng là do việc chia lại bộ sưu tập không thể tiến hành chuyển đổi bộ sưu tập trong 2 giây hoặc ít hơn.

Nếu đúng như vậy, chúng tôi khuyên bạn nên đặt thời gian bắt đầu phân chia lại phân đoạn để nó cố gắng thực hiện trong khoảng thời gian lưu lượng truy cập thấp hơn cho cụm của bạn. Ngoài ra, nếu ứng dụng của bạn có thể chịu được tình trạng tắc nghẽn ghi trong hơn 2 giây, bạn có thể sửa đổi thời gian cam kết bằng cách tăng thời lượng với tham số chia lại phân đoạnCriticalSectionTimeoutMillis vượt quá 2000 mili giây mặc định.

Khi hoạt động chia lại phân đoạn hoàn tất, bạn có thể tiến hành các hoạt động dọn dẹp, chẳng hạn như loại bỏ chỉ mục khóa phân đoạn tạm thời và thu nhỏ cụm và/hoặc bộ nhớ của bạn để phù hợp với nhu cầu ở trạng thái ổn định của bạn.

Bây giờ bạn có thể bỏ chỉ mục tạm thời bằng lệnh db.collection.dropIndex() trong mongo shell!

 db.flight_tracker.dropIndex( {"airline": 1, "flight_number": 1, "date": 1} )

câu hỏi thường gặp

1. Quá trình chia lại thành phân đoạn mất bao lâu?

   
   

   • Nó phụ thuộc vào kích thước bộ sưu tập của bạn, số lượng và kích thước của các chỉ mục cho bộ sưu tập của bạn cũng như số lượng phân đoạn trong cụm của bạn, nhưng chúng tôi tin rằng bạn có thể chia lại phân đoạn bộ sưu tập 4TB với 10 chỉ mục trên 4 phân đoạn trong 48 giờ hoặc ít hơn. Để bộ cân bằng xử lý việc di chuyển sẽ mất 30 ngày trở lên.

     
     

2. Tại sao việc chia lại phần lại nhanh hơn so với việc để bộ cân bằng di chuyển dữ liệu?

   
   

   • Các nội dung bên trong về cách dữ liệu di chuyển của bộ cân bằng và chia lại kích thước là khác nhau. Việc chia lại phân đoạn đọc các tài liệu theo một thứ tự khác với di chuyển khối và vì việc chia lại phân đoạn kết thúc bằng việc loại bỏ bộ sưu tập cũ nên không cần chờ xóa phạm vi để giải phóng dung lượng ổ đĩa.

     
     

3. Tôi muốn sử dụng phân đoạn lại thành phân đoạn trên bộ sưu tập có ràng buộc về tính duy nhất và chỉ mục băm không hỗ trợ thực thi tính duy nhất.

   
   

   • Nếu bộ sưu tập của bạn có ràng buộc về tính duy nhất, bạn có thể sử dụng phân đoạn lại thành phân đoạn, nhưng sẽ phải thực hiện một cách tiếp cận khác. Bằng cách thêm một trường bổ sung vào khóa phân đoạn tạm thời thay vì thay đổi chiến lược phân vùng, bạn mở khóa khả năng phân chia lại thành khóa phân đoạn mong muốn. Ví dụ: nếu khóa phân đoạn mong muốn của bạn là:

     
     

      { launch_vehicle: 1, payload: 1}

     
     

   • Khóa phân đoạn tạm thời của bạn sẽ là:

      { launch_vehicle: 1, payload: 1, launch_pad: 1}

     
     

   • Vui lòng lưu ý các giới hạn đối với truy vấn (ví dụ: updateOne(), updateMany(), deleteOne()) yêu cầu truy vấn bao gồm khóa phân đoạn. Ứng dụng của bạn phải bao gồm khóa phân đoạn tạm thời trong tất cả các tình huống mà truy vấn yêu cầu khóa phân đoạn thực thi thành công cho đến khi hoàn tất thao tác phân đoạn lại.

   
   

4. Làm cách nào để giám sát hoạt động chia lại phân vùng đang diễn ra?

   
   

   • Chạy lệnh sau:

      db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "<database>.<collection>" } } ])

6. Làm cách nào để dừng hoạt động chia lại khối đang diễn ra?

   
   

   • Chạy lệnh sau, lệnh này sẽ ngay lập tức hủy bỏ thao tác chia lại phân vùng:

      sh.abortReshardCollection("<database>.<collection>")

7. Tôi lo ngại về việc phân chia lại ảnh hưởng đến hiệu suất cụm của tôi.

   
   

   • Nếu bạn đáp ứng các yêu cầu chia lại phân đoạn đã nêu trước đó, thao tác này sẽ không ảnh hưởng đến hiệu suất cụm của bạn. Tuy nhiên, nếu cụm của bạn được triển khai trên Atlas, bạn có thể tạm thời tăng quy mô cụm của mình trong khi thực hiện thao tác chia lại phân đoạn thành phân đoạn và thu nhỏ cụm trở lại sau khi thao tác này hoàn tất.

     
     

8. Tôi nên theo dõi những chỉ số nào của cụm trong khi hoạt động phân chia lại đang được thực thi?

   
   

   • Không gian lưu trữ khả dụng - nếu bất kỳ phân đoạn nào của bạn có ít hơn 100GB dung lượng lưu trữ, bạn nên hủy bỏ việc chia lại phân đoạn

   • Sử dụng CPU - nếu cụm của bạn đang sử dụng tất cả các tài nguyên điện toán có sẵn, bạn có thể gây ra tranh chấp tài nguyên và nên hủy bỏ việc chia lại phân đoạn

   • Mức tiêu thụ I/O - nếu cụm của bạn đang sử dụng tất cả IOPS có sẵn, bạn có thể gây ra tranh chấp tài nguyên và nên hủy bỏ việc chia lại phân đoạn.

     
     

9. Bộ sưu tập tạm thời dường như được phân bổ đồng đều trên tất cả các phân đoạn của tôi, tại sao việc chia lại phân đoạn không hoàn tất?

   
   

   • Trước khi chia lại phân đoạn có thể chuyển sang bộ sưu tập bằng khóa phân đoạn mong muốn của bạn, nó phải bắt kịp với tất cả các lần ghi xảy ra kể từ khi quá trình chia lại phân đoạn được bắt đầu. Nếu khối lượng công việc viết của bạn nhiều thì có thể mất một khoảng thời gian dài để giai đoạn bắt kịp kết thúc.

     
     

10. Ứng dụng của tôi không thể chịu được việc ghi bị chặn trong hơn 1 giây, tôi có thể sửa đổi thời lượng ghi sẽ bị chặn đối với bộ sưu tập đang được phân chia lại không?

    
    

    • Có, nhưng chúng tôi không mong muốn tùy chọn này được sử dụng thường xuyên vì hoạt động chia lại phân đoạn theo mặc định sẽ cố gắng chuyển sang bộ sưu tập mới khi nó ước tính rằng quá trình chuyển đổi có thể được thực hiện trong vòng chưa đầy 1 giây. Nếu ứng dụng của bạn không thể chịu được việc ghi bị chặn vào bộ sưu tập đang được chia lại phần cứng trong 2 giây, bạn có thể sửa đổi tham số chia lại phần cứngCriticalSectionTimeoutMillis để chặn ghi chỉ trong 1 giây.

      • Xin lưu ý rằng việc giảm giá trị này làm tăng khả năng thao tác chia lại kích thước bị hủy bỏ vì nó làm giảm thời gian chờ mà thao tác chia lại kích thước có thể đợi phần quan trọng hoàn tất quá trình cắt.

    • Chạy lệnh sau:

       db.adminCommand({ setParameter: 1, reshardingCriticalSectionTimeoutMillis: 1000 })