次の方法で共有


テーブル設計のガイドライン

Azure Storage Table service で使用するテーブルの設計は、リレーショナル データベースの設計に関する考慮事項とは大きく異なります。 この記事では、読み取りと書き込みが効率的になるように Table service ソリューションを設計するためのガイドラインについて説明します。

Table service ソリューションの読み込みが効率的になるように設計する

  • 読み込みが多いアプリケーションでクエリを実行するための設計。 テーブルを設計するときは、エンティティの更新方法について考える前に、実行するクエリ (特に、待機時間に影響を受けやすいもの) を検討してください。 これは通常、効率的でパフォーマンスの高いソリューションになります。
  • クエリでは、PartitionKey と RowKey の両方を指定します。ポイント クエリ、これらは、最も効率的なテーブル サービスのクエリなどです。
  • エンティティの重複コピーを格納するか検討します。 テーブル ストレージは安価であるため、クエリの効率を上げるために、(異なるキーを持つ) 同じエンティティを複数回格納することをご検討ください。
  • データの非正規化を検討します。 テーブル ストレージは安価であるため、データの非正規化を検討してください。 たとえば、概要エンティティを格納すると、統計データ用クエリは単一のエンティティにアクセスするだけで済みます。
  • 複合キーの値を使用します。 持っているキーは PartitionKeyRowKey だけです。 たとえば、複合キーの値を使用してエンティティへの代替キー付きアクセス パスを有効にします。
  • クエリ プロジェクションを使用します。 必要なフィールドだけを選択するクエリを使用して、ネットワーク経由で転送するデータ量を削減できます。

Table service ソリューションの書き込みが効率的になるように設計する

  • ホット パーティションを作成しないでください。 任意の時点で、複数のパーティションで要求を分散できるキーを選択します。
  • トラフィックの急増を回避します。 適切な期間でトラフィックの流れをスムーズにし、トラフィックの急増を回避します。
  • 必ずしもエンティティの種類ごとに個別のテーブルを作成する必要はありません。 複数のエンティティ種類でアトミック トランザクションが必要なときに、同じテーブル内の同じパーティションにこれら複数のエンティティ種類を格納できます。
  • 実現する必要のある最大スループットを検討します。 Table service のスケーラビリティ ターゲットを確認し、それを超えない設計にする必要があります。

このガイドでは、これらの原則を実装した例を紹介します。

次のステップ