次の方法で共有

データ変更の設計

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

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

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

「テーブルデザインパターン」セクションの次のパターンは、パフォーマンスまたは挿入、更新、および削除操作の最適化に対応しています。

  • 大量の削除パターン - 同時削除のすべてのエンティティを独自の個別のテーブルに格納することで、大量のエンティティの削除を有効にします。テーブルを削除してエンティティを削除します。
  • データ系列パターン - 要求の数を最小限に抑えるために、完全なデータ系列を 1 つのエンティティに格納します。
  • ワイド エンティティ パターン - 複数の物理エンティティを使用して、252 を超えるプロパティを持つ論理エンティティを格納します。
  • 大きなエンティティ パターン - BLOB ストレージを使用して大きなプロパティ値を格納します。

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

データ変更を最適化するためのキーの選択に影響するもう 1 つの重要な要因は、アトミック トランザクションを使用して一貫性を確保する方法です。 EGT を使用して操作できるのは、同じパーティションに格納されているエンティティのみです。

記事「テーブル設計パターン」の次のパターンは、整合性管理を扱います。

エンティティ グループ トランザクションの詳細については、「 エンティティ グループ トランザクション」セクションを参照してください。

効率的な変更のための設計が効率的なクエリを容易にすることを確認する

多くの場合、効率的なクエリを行う設計では効率的な変更が行われますが、これが特定のシナリオに当てはまるかどうかを常に評価する必要があります。 テーブル デザイン パターンに関する記事の一部のパターンでは、エンティティのクエリと変更の間のトレードオフを明示的に評価します。各種類の操作の数は常に考慮する必要があります。

Table の設計パターンに関する記事の次のパターンでは、効率的なクエリの設計と効率的なデータ変更のための設計の間のトレードオフに対処します。

  • 複合キー パターン - 複合 RowKey 値を使用して、クライアントが 1 つのポイント クエリで関連データを参照できるようにします。
  • ログ 末尾のパターン - 最後にパーティションに追加された n 個のエンティティを取得します。このエンティティは、逆の日付と時刻の順序で並べ替えられる RowKey 値を使用します。
  • Last updated on