Cập nhật: Tháng 4 năm 2018
Câu trả lời này là chính xác tại thời điểm của câu hỏi, nhưng mọi thứ đã chuyển từ đó. Vì phiên bản 3.4 song song đã được giới thiệu và vé tôi tham chiếu ban đầu đã bị đóng. Để biết thêm thông tin tôi bao gồm một số chi tiết trong câu trả lời gần đây hơn này . Tôi sẽ để phần còn lại của câu trả lời vì nó vẫn là một tài liệu tham khảo tốt cho các vấn đề / ràng buộc chung cũng như hợp lệ cho bất kỳ ai trên phiên bản cũ hơn.
Câu trả lời gốc
Tôi đưa ra một lời giải thích đầy đủ về những gì xảy ra với việc di chuyển chunk trong khóa học M202 Advanced nếu bạn quan tâm. Nói chung, chúng ta chỉ nói rằng việc di chuyển không nhanh lắm, ngay cả đối với các khối trống, vì việc dọn phòng được thực hiện để đảm bảo việc di chuyển hoạt động trong một hệ thống đang hoạt động (những điều này vẫn xảy ra ngay cả khi không có gì ngoài việc cân bằng đang xảy ra).
Ngoài ra, chỉ có một lần di chuyển xảy ra tại một thời điểm trên toàn bộ cụm - không có sự song song. Vì vậy, mặc dù thực tế là bạn có hai nút "đầy đủ" và hai nút "trống", tại bất kỳ thời điểm nào cũng có ít nhất một lần di chuyển xảy ra (giữa phân đoạn có nhiều khối nhất và phân đoạn ít nhất). Do đó, việc thêm 2 mảnh sẽ giúp bạn không phải mất gì về tốc độ cân bằng và chỉ cần tăng số lượng khối phải di chuyển.
Đối với bản thân việc di chuyển, các khối có kích thước ~ 30MiB (tùy thuộc vào cách bạn nhập dữ liệu, nhưng nhìn chung đây sẽ là mức trung bình của bạn với kích thước khối tối đa mặc định). Bạn có thể chạy db.collection.getShardDistribution()cho một số thông tin đó, và xem câu trả lời của tôi ở đây để biết cách lấy thêm thông tin về khối của bạn.
Vì không có hoạt động nào khác diễn ra, để di chuyển xảy ra phân đoạn đích (một trong những phân đoạn mới được thêm vào) sẽ cần đọc ~ 30MiB dữ liệu từ các phân đoạn nguồn (một trong 2 bản gốc) và cập nhật các máy chủ cấu hình thành phản ánh vị trí chunk mới sau khi nó được thực hiện. Di chuyển 30MiB dữ liệu không phải là một nút cổ chai cho một hệ thống bình thường mà không tải.
Nếu nó chậm, có một số lý do có thể xảy ra tại sao lại như vậy, nhưng phổ biến nhất cho một hệ thống không bận rộn là:
- I / O nguồn đĩa - nếu dữ liệu không có trong bộ nhớ hoạt động khi nó được đọc, nó phải được phân trang từ đĩa
- Mạng - nếu có độ trễ, giới hạn tốc độ, mất gói, v.v. thì việc đọc có thể mất nhiều thời gian
- I / O đĩa đích - dữ liệu và chỉ mục phải được ghi vào đĩa, rất nhiều chỉ mục có thể làm cho điều này tồi tệ hơn, nhưng thường thì đây không phải là vấn đề trên hệ thống tải nhẹ
- Các vấn đề với việc di chuyển gây ra hủy bỏ và di chuyển không thành công (sự cố với máy chủ cấu hình, sự cố với việc xóa trên bản gốc)
- Độ trễ sao chép - đối với việc di chuyển sang các bộ bản sao, viết quan tâm
w:2hoặc w:majorityđược sử dụng theo mặc định và yêu cầu cập nhật phụ để đáp ứng nó.
Nếu hệ thống bận thì tranh chấp bộ nhớ, tranh chấp khóa thường cũng sẽ là nghi phạm ở đây.
Để có thêm thông tin về thời gian di chuyển mất bao lâu, nếu chúng thất bại, v.v., hãy xem các mục trong config.changelog:
// connect to mongos
use config
db.changelog.find()
Như bạn đã thấy, và như tôi thường nói với mọi người khi tôi đào tạo / giáo dục, nếu bạn biết bạn sẽ cần 4 phân đoạn, thì tốt hơn là bắt đầu với 4 thay vì tăng tốc. Nếu bạn làm như vậy, thì bạn cần lưu ý rằng việc thêm phân đoạn có thể mất nhiều thời gian và ban đầu là một tiêu cực ròng đối với tài nguyên chứ không phải là lợi ích (xem phần II của loạt bài về cạm bẫy của tôi để thảo luận chi tiết hơn về điều đó).
Cuối cùng, để theo dõi / upvote / nhận xét về yêu cầu tính năng để cải thiện tính song song của di chuyển khối, hãy xem SERVER-4355