次の方法で共有

データの変更に対応した設計

  • [アーティクル]

この記事では、挿入、更新、削除の操作を最適化するための設計上の考慮事項を示します。 場合によっては、リレーショナル データベースの設計と同様に、クエリ向けの最適化とデータ変更向けの最適化のトレードオフを評価する必要があります (設計のトレードオフを管理する手法はリレーショナル データベースでは異なります)。 「テーブルの設計パターン」セクションでは、Table service の詳細な設計パターンをいくつか説明し、これらのトレードオフに注目します。 実際のところ、クエリ向けに最適化された設計の多くは、エンティティの変更にも適していることがおわかりになると思います。

挿入、更新、削除の操作のパフォーマンスを最適化する

エンティティを更新または削除するには、PartitionKey と RowKey 値を使用してエンティティを識別する必要があります。 この点で、エンティティの変更のために選択した PartitionKey と RowKey は、できるだけ効率的にエンティティを識別するため、ポイント クエリをサポートするために選択したものと同様の条件に従う必要があります。 PartitionKey と RowKey 値の検出のためにエンティティを特定する非効率的なパーティションまたはテーブル スキャンを使用したくない場合は、更新または削除する必要があります。

「テーブルの設計パターン」セクションの以下のパターンは、パフォーマンスの最適化または挿入、更新、削除操作に対応しています。

格納されたエンティティの一貫性を確保する

データの変更を最適化するためのキーの選択を左右する要因として、アトミックなトランザクションを使って一貫性を確保する方法も挙げられます。 同じパーティションに格納されたエンティティを操作する場合は、EGT しか使用できません。

記事「Table design patterns」(テーブル設計パターン) の以下のパターンは、一貫性の管理に対応しています。

エンティティ グループ トランザクションについて詳しくは、「Entity Group Transactions」(エンティティ グループ トランザクション) セクションをご覧ください。

効率的な変更に対応した設計によるクエリの効率化

効率的なクエリに適した設計は変更の効率も高いのが普通ですが、自分のシナリオにもそれが当てはまるかどうかは必ず評価する必要があります。 「Table Design Patterns」(テーブル設計パターン) のパターンの中には、エンティティをクエリして変更する間に明示的にトレードオフを評価するものがあります。常に各操作数を考慮しておく必要があります。

「Table Design Patterns」(テーブル設計パターン) の以下のパターンは、効率的なクエリの設計と効率的なデータ変更の設計の間のトレードオフに対応しています。

  • 複合キー パターン -複合 RowKey 値を使用して、1 つのポイント クエリに関連するデータを検索するクライアントを有効にします。
  • ログ テール パターン - 逆の日付と時間順で並べ替える RowKey 値を使用して、パーティションに最も新しく追加されたエンティティ n を取得します。