cập nhật 40+ triệu thực thể trong bảng màu xanh với nhiều trường hợp cách xử lý các vấn đề tương tranh

Question

Vì vậy, đây là vấn đề. Tôi cần cập nhật khoảng 40 triệu thực thể trong một bảng xanh. Làm điều này với một cá thể duy nhất (chọn -> xóa bản gốc -> chèn bằng khóa phân vùng mới) sẽ mất cho đến khoảng Giáng sinh.

Suy nghĩ của tôi là sử dụng vai trò công nhân xanh với nhiều trường hợp đang chạy. Vấn đề ở đây là truy vấn lấy 1000 hồ sơ hàng đầu. Đó là tốt với một ví dụ nhưng với 20 chạy lựa chọn của họ rõ ràng sẽ chồng lên nhau .. rất nhiều. điều này sẽ dẫn đến rất nhiều tính toán lãng phí cố gắng xóa các bản ghi đã bị xóa bởi một thể hiện khác và cập nhật một bản ghi đã được cập nhật.

Tôi đã thực hiện một vài ý tưởng, nhưng tùy chọn tốt nhất mà tôi có là để các vai trò lấp đầy hàng đợi bằng các phím phân vùng và hàng sau đó có công nhân dequeue và xử lý thực tế?

Bất kỳ ý tưởng nào tốt hơn?

Answer 1

Nếu PartitionKeys và/hoặc RowKey của bạn rơi vào một phạm vi đã biết, bạn có thể cố gắng chia chúng thành các bộ phân tách có kích thước bằng nhau để mỗi nhân viên xử lý. ví dụ, Worker1 xử lý các khóa bắt đầu bằng 'A' đến 'C', Worker2 xử lý các khóa bắt đầu bằng 'D' đến 'F', v.v.

Nếu không khả thi thì giải pháp xếp hàng của bạn có thể hoạt động. Nhưng một lần nữa, tôi sẽ đề nghị rằng mỗi tin nhắn hàng đợi đại diện cho một loạt các phím nếu có thể. ví dụ: một thông báo xếp hàng đơn chỉ định xóa mọi thứ trong phạm vi 'A' đến 'C' hoặc tương tự như vậy.

Trong mọi trường hợp, nếu bạn có nhiều thực thể trong cùng một PartitionKey thì sử dụng các giao dịch hàng loạt cho lợi thế của bạn cho cả việc chèn và xóa. Điều đó có thể cắt giảm số lượng giao dịch bằng gần như một yếu tố của mười trong trường hợp tốt nhất. Bạn cũng nên sử dụng song song trong mỗi vai trò của nhân viên. Lý tưởng nhất là sử dụng các phương thức async (hoặc Begin/End hoặc * Async) để thực hiện việc viết và chạy một số giao dịch (12 có thể là một số tốt) song song. Bạn cũng có thể chạy nhiều luồng, nhưng điều đó có phần kém hiệu quả hơn. Trong cả hai trường hợp, một công nhân đơn lẻ có thể đẩy lô giao dịch bằng bộ nhớ bảng.

Như một lưu ý phụ, quá trình của bạn sẽ chuyển thành "Chọn -> Chèn mới -> Xóa cũ". Đi "Chọn -> Xóa Cũ -> Chèn Mới" có thể dẫn đến mất dữ liệu vĩnh viễn nếu xảy ra lỗi giữa các bước 2 & 3.

Answer 2

Tôi nghĩ bạn nên đánh dấu câu hỏi của mình là câu trả lời;) Tôi không thể nghĩ ra giải pháp nào tốt hơn vì tôi không biết phân vùng và khóa hàng của bạn trông như thế nào. Nhưng để nâng cao giải pháp của bạn, bạn có thể chọn để bơm nhiều phân vùng/hàng phím vào mỗi tin nhắn hàng đợi để tiết kiệm chi phí giao dịch. Ngoài ra khi tiêu thụ từ hàng đợi, hãy nhận chúng theo lô 32. Xử lý không đồng bộ. Tôi đã có thể chuyển 170 triệu bản ghi từ máy chủ SQL (Azure) sang bảng lưu trữ trong vòng chưa đầy một ngày.

Answer 3

Câu hỏi rất thú vị !!! Mở rộng câu trả lời @ Brian Reischl (và rất nhiều của nó đang nghĩ out loud, vì vậy hãy chịu với tôi :))

Giả định:

• tổ chức của bạn là serializable trong một số hình thức nào. Tôi cho rằng bạn sẽ nhận được dữ liệu thô ở định dạng XML.
• Bạn có một vai trò công nhân riêng biệt đang thực hiện tất cả việc đọc các thực thể.
• Bạn biết cần bao nhiêu vai trò công nhân để viết các thực thể được sửa đổi.Vì lợi ích của lập luận, hãy giả sử nó là 20 như bạn đã đề cập.

Giải pháp:

Trước tiên, bạn sẽ tạo ra 20 container blob. Hãy đặt tên chúng là container-00, container-01, ... container-19.

Sau đó, bạn bắt đầu đọc các thực thể - 1000 tại một thời điểm. Vì bạn đang nhận dữ liệu thô ở định dạng XML ngoài bộ nhớ bảng, bạn tạo một tệp XML và lưu trữ 1000 thực thể đó trong vùng chứa-00. Bạn tìm nạp các bộ thực thể tiếp theo và lưu chúng ở định dạng XML trong vùng chứa-01 và cứ tiếp tục như vậy cho đến khi bạn nhấn vào thùng chứa-19. Sau đó, tập hợp các thực thể tiếp theo đi vào vùng chứa-00. Bằng cách này, bạn phân phối đồng đều các thực thể của mình trên tất cả 20 vùng chứa.

Khi tất cả các thực thể được viết, vai trò công nhân của bạn để xử lý các thực thể này sẽ được đưa vào ảnh. Vì chúng ta biết rằng các cá thể trong Windows Azure được sắp xếp theo thứ tự, bạn nhận được các tên dụ như WorkerRole_IN_0, WorkerRole_IN_1, ... và cứ thế.

Những gì bạn sẽ làm là lấy tên dụ, lấy số "0", "1" vv Dựa trên điều này, bạn sẽ xác định trường hợp vai trò công nhân nào sẽ đọc từ vùng chứa blob nào ... WorkerRole_IN_0 sẽ đọc tệp từ container-00, WorkerRole_IN_1 sẽ đọc tệp từ vùng chứa-01 và cứ tiếp tục như vậy.

Bây giờ cá thể vai trò công nhân cá nhân của bạn sẽ đọc tệp XML, tạo các thực thể từ tệp XML đó, cập nhật các thực thể đó và lưu nó trở lại bộ nhớ bảng. Khi quá trình này được thực hiện, sau đó bạn sẽ xóa tệp XML và bạn chuyển sang tệp tiếp theo trong vùng chứa đó. Khi tất cả các tệp được đọc và xử lý, bạn chỉ có thể xóa vùng chứa. Như tôi đã nói trước đây, đây là một loại giải pháp "suy nghĩ to" và một số thứ phải được xem xét như những gì xảy ra khi vai trò công nhân "người đọc" đi xuống và những thứ khác.