すべてのプロダクト
Search
ドキュメントセンター

:テーブル作成時の注意点

最終更新日:Mar 23, 2020

テーブルの作成に属性列が必要ですか?

いいえ。Table Store は、半構造化テーブルをサポートしています。表の作成時には、主キー列(列 1〜4)のみが必要です。

表の属性列の数は、Table Store 限定されません。データの各行は、異なる量と種類の属性列を持つことができます。アプリケーションがデータを書き込んでいるときは、Table Store にすべてのデータ列(主キー列と属性列)の名前と値を指定するアプリケーションが必要です。

テーブル作成時のプライマリキーの最初の列にあるパーティションキーは何ですか?

表のデータ・サイズが設定値に達すると、Table Store はパーティション・キー列の値の範囲に基づいて表をパーティション化し、ロード・バランシングを実現します。

表の作成時には、表にはデフォルトで 1 つの区画があり、すべての表データはこの区画に入っています。表に複数の区画がある場合、各区画に保管されるデータは、すべて区画キー列の特定の値の範囲内のデータです。パーティションキー列の値のすべての範囲は、主キー列のデータ型 Integer または String に基づく列値の自然順序によってセグメント化されます。

データ問合せのパフォーマンスに加えて、データの区分化も予約済みの読取り/書込みスループットの使用に影響します。 表に複数の区画がある場合、表の予約済みの読み取り/書き込みスループットは各区画に比例します。

適切なパーティションキーを設定するには?

パーティションキーの選択は、大量のデータが存在する場合にテーブルのクエリパフォーマンスに影響するため、テーブル作成時に重要です。アプリケーションのパーティションキーを設定するときは、次の基本原則を守ってください。

  • ユーザーの性別(男性/女性)など、固定値または小さな値の範囲の属性は使用しないでください。

  • 自然順序でソートした後、明示的なクエリホットスポットを持つ属性を避ける。たとえば、TimeStamp を最新のデータを照会するためのパーティションキーとして使用します。

  • UserID などの自然順序でソートした後、散在したクエリホットスポットでアトリビュートを使用します。

質問ホットスポットを予測できない場合、何ができますか?

パーティションキーを書き込む前に、アプリケーションの機能に従ってデータをハッシュすることをお勧めします。たとえば、データ行を書き込むときは、単純なハッシュアルゴリズムを使用して UserID のハッシュ値を生成し、ハッシュ値と UserID をスプライスし、パーティションキー値として Table Store テーブルに保存します。この軽量な操作は、クエリのホットスポットの問題を効果的に解決できます。パーティションキー値はスプライスされたハッシュ値と実際の値の結果であるため、アプリケーションはパーティションキーを使用して範囲(getRange)を読み取ることができません。

アカウントのテーブル数の制限はいくらですか?制限を増やすことはできますか?

各 Table Store ユーザーは最大10個のインスタンスを作成でき、各インスタンスは 1 つのアカウントで最大 64 個のテーブルを持つことができます。

次のシナリオでは、テーブル数の制限を増やすことができます。

  • 膨大なデータ量と高いクエリパフォーマンス要件

    Table Store、データベースのシャーディングとテーブルの分割によって大量のデータアクセスリクエストに対処する従来の SQL データベース(たとえば、MySQL)とは異なり、分散型設計を採用し、膨大なデータボリュームとアクセス待ち時間のボトルネックを解消します。

    巨大なデータ量に起因する妥協したクエリのパフォーマンスを気にすることなく、構造化されたデータまたは半構造化されたデータをスパーステーブルに保存できます。

  • アプリケーションの急速な成長

    データとアクセス量の増加に加えて、Table Store を使用して、顧客(サードパーティのパートナーやベンダーなど)にサービスを提供することができます。ベンダーにサービスを提供し、Table Store に基づくソリューションを提供する場合は、ベンダーごとに Table Store テーブルのセットを展開する必要があります。この場合、テーブルの数はすぐに上限に達します。テーブルの数量の上限を絶えず増やすと、操作やメンテナンスのコストが制御不能になり、グローバルデータ分析の複雑さが増します。

    Table Store を新しい方法で使用し、同じ型の大規模な構造化/半構造化データを大きなテーブルに保存することをお勧めします。

  • Table Store 考慮事項

    テーブルの数は、テーブル Table Store 分散アーキテクチャのリソース属性です。Table Store クラスタの固定スケールを仮定すると、テーブルの数は最大値を有することが理解できます。Table Store のスケーラビリティは、テーブルの数量の限界に効果的に対処できますが、リソースの制御性のために、Table Store は 1 つのアカウントのテーブルの最大数に制限を設定します。

アカウントのテーブルの最大数を増やすには、テクニカルサポートまでお問い合わせください。