Giải pháp cho tìm kiếm hàng loạt và sửa đổi trong MongoDB

Question

Trường hợp sử dụng của tôi như sau - Tôi có một bộ sưu tập tài liệu trong mongoDB mà tôi phải gửi để phân tích. Định dạng của các văn bản như sau -

{_id: ObjectId ("517e769164702dacea7c40d8"), date: "1359911127494", status: "có sẵn", other_fields ...}

Tôi có quy trình đọc chọn 100 tài liệu đầu tiên có trạng thái : có sẵn được sắp xếp theo ngày và sửa đổi chúng với trạng thái : xử lý. ReaderProcess gửi tài liệu để phân tích. Khi phân tích hoàn tất, trạng thái được đổi thành được xử lý.

Hiện nay quá trình đọc đầu tiên lấy 100 tài liệu được sắp xếp theo ngày và sau đó cập nhật tình trạng -chế biến cho mỗi tài liệu trong một vòng lặp. Có giải pháp nào tốt hơn/hiệu quả hơn cho trường hợp này không?

Ngoài ra, trong tương lai cho khả năng mở rộng, chúng tôi có thể thực hiện nhiều quy trình đọc. Trong trường hợp này, tôi muốn 100 tài liệu được chọn bởi một quy trình đọc không nên được chọn bởi một quy trình đọc khác. Nhưng tìm nạp và cập nhật là các truy vấn riêng biệt ngay bây giờ, vì vậy rất có thể là nhiều quy trình đọc sẽ chọn cùng một tài liệu.

Số lượng lớn findAndModify (có giới hạn) sẽ giải quyết được tất cả các sự cố này. Nhưng tiếc là nó không được cung cấp trong MongoDB. Có giải pháp nào cho vấn đề này?

Answer 1

Như bạn đã đề cập, hiện tại không có cách nào sạch sẽ để thực hiện những gì bạn muốn. Cách tiếp cận tốt nhất vào thời điểm này cho các hoạt động như cái bạn cần là thế này:

1. đọc lựa chọn các văn bản X với giới hạn thích hợp và sắp xếp
2. đọc đánh dấu các tài liệu trả về bởi 1) với nó của riêng ID đọc duy nhất (e.g. update({_id:{$in:[<result set ids>]}, state:"available", $isolated:1}, {$set:{readerId:<your reader's ID>, state:"processing"}}, false, true))
3. Trình đọc chọn tất cả các tài liệu được đánh dấu là đang xử lý và có ID trình đọc riêng. Tại thời điểm này, nó được đảm bảo rằng bạn có quyền truy cập độc quyền vào tập hợp các tài liệu kết quả.
4. Cung cấp kết quả từ 3) cho quá trình xử lý của bạn.

Lưu ý rằng điều này thậm chí hoạt động trong các tình huống đồng thời cao vì người đọc không bao giờ có thể đặt trước các tài liệu chưa được người đọc khác đặt trước (lưu ý rằng bước 2 chỉ có thể đặt trước tài liệu hiện có và viết là nguyên tử). Tôi sẽ thêm một dấu thời gian với thời gian đặt phòng là tốt nếu bạn muốn để có thể thời gian ra đặt phòng (ví dụ cho các kịch bản mà người đọc có thể sụp đổ/thất bại).

EDIT: Thông tin chi tiết:

Tất cả các ghi các hoạt động thỉnh thoảng có thể mang lại cho cấp phát hoạt động nếu ghi mất một thời gian tương đối dài.Điều này có nghĩa là bước 2) có thể không thấy tất cả các tài liệu được đánh dấu bằng bước 1) trừ khi bạn thực hiện các bước sau:

• Sử dụng giá trị "w" (viết quan tâm) thích hợp, nghĩa là 1 hoặc cao hơn. Điều này sẽ đảm bảo rằng kết nối mà trên đó thao tác ghi được gọi sẽ đợi cho nó hoàn thành bất kể nó sinh ra.
• Đảm bảo bạn thực hiện việc đọc ở bước 2 trên cùng một kết nối (chỉ liên quan đến các bản sao với các lần đọc đã bật slave) hoặc chuỗi sao cho chúng được đảm bảo tuần tự. Cái trước có thể được thực hiện trong hầu hết các trình điều khiển với các phương thức "requestStart" và "requestDone" hoặc tương tự (tài liệu Java here).
  • Thêm cờ bị cô lập vào các bản cập nhật đa để đảm bảo không thể xen kẽ với các hoạt động viết khác.

Xem thêm chú thích để thảo luận về nguyên tử/cách ly. Tôi đã giả định không chính xác nhiều bản cập nhật đã bị cô lập. Họ không phải là, hoặc ít nhất là không theo mặc định.