ここに問題があります。Azure テーブルで約 4,000 万のエンティティを更新する必要があります。単一のインスタンスでこれを行う (選択 -> オリジナルを削除 -> 新しいパーティションキーで挿入) には、クリスマス頃までかかります。
私の考えは、多くのインスタンスが実行されている azure ワーカー ロールを使用することです。ここでの問題は、クエリが上位 1000 レコードを取得することです。1 つのインスタンスでは問題ありませんが、20 のインスタンスを実行すると、それらの選択が明らかにオーバーラップします。これにより、別のインスタンスによって既に削除されたレコードを削除しようとしたり、既に更新されたレコードを更新したりするために、多くの無駄なコンピューティングが発生します。
私はいくつかのアイデアを実行しましたが、私が持っている最良のオプションは、役割がパーティションと行キーでキューを埋めてから、ワーカーがデキューして実際の処理を行うことですか?
より良いアイデアはありますか？
PartitionKeys および/または RowKeys が既知の範囲に収まる場合、処理する各ワーカーがほぼ同じサイズの互いに素なセットに分割することを試みることができます。たとえば、Worker1 は「A」から「C」までのキーを処理し、Worker2 は「D」から「F」までのキーを処理します。
それが不可能な場合は、キューイング ソリューションがおそらく機能します。ただし、可能であれば、各キュー メッセージが一連のキーを表すことをお勧めします。たとえば、単一のキュー メッセージは、'A' から 'C' までの範囲内のすべてを削除するように指定します。
いずれにせよ、同じ PartitionKey に複数のエンティティがある場合は、挿入と削除の両方に有利にバッチ トランザクションを使用してください。これにより、最良の場合でもトランザクション数をほぼ 10 分の 1 に削減できます。各ワーカー ロール内でも並列処理を使用する必要があります。非同期メソッド (Begin/End または *Async) を使用して書き込みを行い、複数のトランザクション (おそらく 12 が適切な数) を並行して実行するのが理想的です。複数のスレッドを実行することもできますが、効率はやや劣ります。いずれの場合も、1 つのワーカーがテーブル ストレージを使用して大量のトランザクションをプッシュできます。
補足として、プロセスは「選択->新規挿入->古い削除」に進む必要があります。「選択 -> 古いものを削除 -> 新しいものを挿入」に進むと、手順 2 と 3 の間で障害が発生した場合、データが永久に失われる可能性があります。
質問を回答としてマークする必要があると思います;)パーティションと行キーがどのように見えるかわからないため、より良い解決策は思いつきません。ただし、ソリューションを強化するために、トランザクション コストを節約するために、複数のパーティション/行キーを各キュー メッセージに送り込むことを選択できます。また、キューから消費する場合は、32 個のバッチで取得します。非同期で処理します。1 億 7000 万件のレコードを SQL サーバー (Azure) からテーブル ストレージに 1 日足らずで転送することができました。