削除Azureテーブルストレージからのエンティティの数百

Question

私の同僚と私はcurrenty製品のアンドゥ/リドゥ機能を実装しています。私たちは、コマンドパターンを使用して、すべてのコマンドを保存している（例えば、コンポーネントを作成する「myFancyComponent」）TableStorageEntryとして表に「ProductHistory」。この表のPartitionKeyはRowKeyは一意の識別子であり、ユニークな製品名です。

問題は、製品が削除される場合、それはまた、テーブルのストレージに歴史全体を削除する必要があります。バッチ削除を使用すると、いくつかの制限があるため、かなり複雑になる可能性があります。 100エンティティまたは最大4 MB（これより小さいものであれ）。この問題のベストプラクティスはありますか？または、すべてのエントリを照会し、エントリのサイズを確認し、エントリの正しい量をバッチ削除する唯一のソリューションですか？

また、私はこの似questionを発見し、各製品用のテーブルを作成するために検討しました。このアプローチのいくつかの利点があるようです：一つだけのテーブルが

の削除は簡単ですが照会されますので、

• の選択は、より高速である必要があり、ちょうどのみ全体テーブルに

をドロップする必要があります欠点私は（「WINDOWSアズール表」に - ホワイトペーパー）実測値：テーブルが削除されるときにテーブルがあるが、同一のテーブル名が、少なくとも30秒間、再作成することができない、ということ

• 注ガベージコレクション。私は数百のテーブルを作成する場合

は、他の（パフォーマンス）の問題がありますか？

Answer 1

私は、削除のためにトランザクションをバッチアップする必要がなくなり、30秒の制限を削除する必要があることを指摘したので、製品ごとに1つのテーブルを使用することを強くお勧めします。インデックステーブルとその製品間の関係を格納するテーブル。次に、製品を削除済みとしてフラグを立て、再追加したときにそのテーブルを再割り当てすることができます。したがって、30秒の制限の単純なバイパスを可能にする。もう1つのアプローチ（私もお勧めします）は、非同期的に起こるように製品の追加を切り離すことで、名前が再び利用可能になったときにテーブルを作成するのを待つことができます。

Azureストレージアカウントの現在の5kトランザクション/秒の制限を超えないことを条件として、何千ものテーブルを持っていてもパフォーマンスの問題はありません。 :)