Lindorm:ワイドテーブル設計のベストプラクティス

プライマリキー列

行の列は、プライマリキー列とプライマリキー以外の列に分類できます。 テーブルのプライマリキーには複数の列を含めることができ、次の特性があります。

• プライマリキースキーマは変更できません：Lindorm ワイドテーブルのプライマリキーは、テーブルの作成時に決定されます。 テーブルの作成後、プライマリキー列のデータ型と順序を追加、削除、または変更することはできません。 したがって、テーブルを作成する前に、テーブルのプライマリキーを慎重に設計してください。 ワイドテーブルのプライマリキーは、リクエスト処理のテーブルのパフォーマンスに大きく影響します。

• プライマリキーはテーブル内で一意です：テーブルのすべてのプライマリキー列は、テーブル内で一意の行キーを形成します。 したがって、完全なプライマリキーに基づいて、テーブル内の一意の行を識別できます。

• プライマリキーはクラスタ化インデックスとして使用されます：Lindorm ワイドテーブルでは、データはプライマリキー列の順序に基づいてクラスタ化されます。 たとえば、サンプルテーブル orders では、channel 列の値が同じ行はクラスタ化されます。 これらの行は、id 列の値に基づいてさらにクラスタ化されます。 次に、id 列の値が同じ行は、ts 列の値に基づいてクラスタ化されます。

  このように、プライマリキーは、クエリ効率を高めるためのクラスタ化インデックスとして使用されます。 Lindorm は、MySQL と同様に、クエリを左端のプライマリキー列のデータに優先的に一致させます。 クエリにプライマリキーと一致する同等の条件を多く指定することで、クエリ対象のデータ量を減らすことができます。 クエリ条件に最も一致するプライマリキー列を左端のプライマリキー列として指定できます。 クエリでプライマリキー列に範囲条件が指定されている場合、他のプライマリキー列に他の同等の条件が指定されていても、左端のプライマリキーは優先的に一致しません。 この場合、LindormTable は大量のデータをスキャンしてフィルタリングし、クエリ対象のデータを見つける必要があります。

  たとえば、次のステートメントを実行して、サンプルテーブル orders のデータをクエリできます。

  -- LindormTable は、channel 列の値が alipay で、id 列の値が a0089 より大きいすべての行をスキャンして、ts 列の値が 1705786502068 に等しい行を見つけます。
  SELECT * FROM orders WHERE channel=="alipay" AND id > 'a0089' AND ts = 1705786502068;  

  クエリ条件で左端のプライマリキー列が指定されていない場合、条件で他のプライマリキー列が指定されていても、LindormTable はテーブル内のすべての行をスキャンします。 次のステートメントは例を示しています。

  -- LindormTable はテーブル内のすべての行をスキャンします。
  SELECT * FROM orders WHERE id = 'a0089';

  前のステートメントでは、左端のプライマリキー列ではないプライマリキー列 id にクエリ条件が指定されています。 したがって、LindormTable はすべての行をスキャンして、id 列の値が a0089 に等しい行を見つけますが、これは効率的ではありません。 ビジネスにおけるクエリのほとんどに id 列の条件が含まれている場合は、id 列を左端のプライマリキー列として指定するか、id 列の個別のインデックステーブルを作成してクエリを高速化することをお勧めします。

プライマリキー以外の列

Lindorm では、テーブルスキーマで定義するのではなく、テーブルのプライマリキー以外の列を動的に定義できます。 HBase のプライマリキー以外の列の使用法と同様に、テーブルに存在するかどうかに関係なく、プライマリキー以外の列にデータを直接書き込むことができます。 詳細については、「動的カラム」をご参照ください。 また、ワイルドカードを使用してプライマリキー以外の列を定義することもできます。 たとえば、データ型が STRING の *_str 列にデータを書き込むステートメントを実行すると、名前が _str で終わるすべての STRING 列にデータを書き込むことができます。 詳細については、「ワイルドカードカラム」をご参照ください。

Lindorm では、プライマリキー以外の列のデータを更新できます。 テーブルにデータを書き込む場合、プライマリキー以外のすべての列の値を指定する必要はありません。 ただし、プライマリキーのみを含むデータ行を書き込むことはできないため、プライマリキー以外の少なくとも 1 つの列の値を指定する必要があります。 Lindorm ワイドテーブルのデータは、プライマリキーの順序に基づいて格納されます。 インデックスが作成されていないプライマリキー以外の列にクエリ条件を指定すると、テーブル内のすべてのデータがスキャンされ、クエリ対象のデータが特定されます。 デフォルトでは、この種のクエリは Lindorm によって拒否されます。 したがって、プライマリキー以外の列のデータをより効率的にクエリするには、プライマリキーに範囲条件を指定するか、プライマリキー以外の列にインデックスを作成します。

-- プライマリキー以外の列の条件のみを指定します。 この場合、テーブル内のすべてのデータがスキャンされます。
SELECT * FROM table WHERE location = 'shanghai'; 

-- プライマリキー列の条件を指定します。 この場合、channel 列の値が alipay である行のみがスキャンされ、location 列の値が shanghai である行が特定されます。
SELECT * FROM table WHERE location = 'shanghai' and channel='alipay'; 

事前分割リージョン

Lindorm はリージョンの自動分割をサポートしています。 したがって、Lindorm ワイドテーブルを作成するときにリージョンの範囲を指定する必要はありません。 LindormTable は、テーブルにデータが書き込まれると、テーブルのリージョンを自動的に分割します。 テーブルの特定のリージョンにデータを分散する必要がある場合は、テーブルを作成するときに事前分割リージョンの数を指定できます。 LindormTable は、読み取りリクエストと書き込みリクエストを分散するために、指定されたリージョンを複数のノードに格納します。 テーブルを作成するときに指定するリージョンの数は、初期リージョンの数のみであることに注意してください。 LindormTable は、テーブルにデータが書き込まれると、初期リージョンをさらに分割します。 テーブルを作成するときに事前分割リージョンを指定する方法の詳細については、「CREATE TABLE」をご参照ください。

テーブルの作成直後に大量のデータを書き込むか、Bulkload を使用してデータをテーブルにインポートする場合は、単一のノードが過負荷にならないように、必要なデータ分散に基づいて事前分割リージョンを指定することをお勧めします。

• SQL または HBase API を使用してデータを書き込む予定の場合は、テーブルを作成するときに事前分割リージョンの数を ノード数 x 4 に設定できます。 最適な初期リージョンの数は、シナリオによって異なります。 ビジネス要件に基づいて事前分割リージョンの数を設定することをお勧めします。

• Bulkload を使用してデータをテーブルにインポートする場合は、事前分割リージョンの数を インポートするデータのサイズ / 8 に設定することをお勧めします。 このように、インポートされたデータは各リージョンに分散でき、これらのリージョンの分割はトリガーされません。

また、事前分割リージョンの範囲がデータ書き込みパターンに準拠していることを確認してください。 そうしないと、書き込まれたデータが特定のリージョンにのみクラスタ化される可能性があります。 この場合、多数の事前分割リージョンを指定しても、テーブルのパフォーマンスが低下する可能性があります。

ホットスポットデータ

分散システムは、リクエストを各リージョンに均等に分散するように設計されています。 このように、システムを水平方向にスケーリングして、より多くのデータでより多くのリクエストを処理できます。 システム内のデータの一部にのみ頻繁にアクセスすると、データはホットスポットデータになります。 この場合、ホットスポットデータが格納されているノードのパフォーマンスが、分散システム全体のパフォーマンスのボトルネックになります。

• 単一行ホットスポットデータ：単一行のデータが頻繁に読み書きされると、このデータ行は単一行ホットスポットデータになります。 同じ行のリクエストは常に同じノードに分散されます。 したがって、このノードのパフォーマンスがシステム全体のボトルネックになります。 この場合、ノードの仕様をスケールアップすることによってのみこの問題を解決できますが、システム内のノードの数をスケールアウトすることはできません。 ワイドテーブルで単一行ホットスポットデータを回避するには、テーブルを作成するときに適切なスキーマまたはプライマリキーを設計する必要があります。

• 範囲ホットスポットデータ：狭い範囲内のデータが頻繁に読み書きされると、データは範囲ホットスポットデータになります。 Lindorm ワイドテーブルは、プライマリキーの範囲に基づいてパーティション分割されます。 したがって、狭い範囲内のデータは同じリージョンに格納される場合があります。 したがって、範囲内のデータのリクエストは同じノードに分散され、システムのパフォーマンスのボトルネックになります。 Lindorm は狭い範囲内のホットスポットデータを識別し、リージョンを分割することでホットスポットデータを異なるノードに自動的に分散できます。 ただし、範囲ホットスポットデータを回避するために、テーブルにより分散されたプライマリキーを設計することをお勧めします。 たとえば、サンプルテーブル orders では、HASH 関数を使用して id 列の値をハッシュに変換し、この列をプライマリキーとして使用して、範囲ホットスポットデータを回避できます。

• 増分プライマリキーによって引き起こされるホットスポット書き込みデータ：テーブルのプライマリキーが増分の場合、ホットスポット書き込みデータが存在する可能性があります。 Lindorm ワイドテーブルは、プライマリキーの範囲に基づいてパーティション分割されます。 したがって、リージョンがサブリージョンに分割されても、リージョンに後続で書き込まれるデータは、サブリージョンの下部にのみ格納されます。 たとえば、サンプルテーブル orders では、プライマリキー列 id は増分で、channel=alipay 条件を満たす多数のデータレコードがテーブルに書き込まれます。 この場合、Region_3 が Region_3_a と Region_3_b に分割されても、データは Region_3_b にのみ書き込まれます。 増分プライマリキーによって引き起こされるホットスポット書き込みデータは、システムアーキテクチャのため、Lindorm では完全に解決できません。 したがって、増分列を最初のプライマリキー列として指定せず、プライマリキーに増分列を含めないことをお勧めします。

  重要

  Cassandra などの一部のデータベースまたはシステムでは、増分プライマリキー列のハッシュ値を含む列をパーティションキーとして使用します。 このように、テーブルの値を異なるパーティションに均等に分散できます。 ただし、データベースまたはシステムのいずれかから Lindorm にデータを移行する場合、増分プライマリキー列によってホットスポット書き込みデータが発生します。

単一値クエリと範囲クエリ

Lindorm ワイドテーブルでは、一般的に 2 種類のクエリが実行されます。単一値クエリと範囲クエリです。

SELECT * FROM orders WHERE channel='alipay' AND id='a0001' AND ts=1705786502000;
SELECT * FROM orders WHERE channel='alipay' AND id='a0001' AND ts IN (1705786502000, 1705786502222, 1705786502333);
SELECT * FROM orders WHERE channel='alipay' AND id IN ('a0001', 'a0002', 'a0003') AND ts IN (1705786502000, 1705786502222, 1705786502333);
SELECT * FROM orders WHERE channel IN ('alipay', 'wechat', 'unionpay') AND id IN ('a0001', 'a0002', 'a0003') AND ts IN (1705786502000, 1705786502222, 1705786502333);

SELECT * FROM orders;
SELECT * FROM orders WHERE channel='alipay';
SELECT * FROM orders WHERE channel='alipay' AND id='1705786502001';
SELECT * FROM orders WHERE channel='alipay' AND id IN ('a0001', 'a0002', 'a0003');
SELECT * FROM orders WHERE channel IN ('alipay', 'wechat', 'unionpay') AND id IN ('a0001', 'a0002', 'a0003');

ORDER BY クエリ

Lindorm ワイドテーブルのデータはプライマリキーでソートされます。 したがって、SELECT ステートメントで ORDER BY 句を指定しなくても、クエリ結果はプライマリキーの順序で返されます。 ただし、クエリの条件がインデックステーブルにヒットした場合、結果はインデックステーブルの順序で返されます。これは、インデックステーブルが作成された列の順序です。

ORDER BY 句に複数の列を指定すると、結果は列によって左から右の順序でソートされます。 インデックスを効率的に使用するには、ORDER BY 句に左端のプライマリキー列を含める必要があります。 左端以外のプライマリキー列またはプライマリキー以外の列のみを ORDER BY 句に指定すると、返された結果をソートするための大量の計算操作が実行されます。 したがって、左端のプライマリキー列を使用して結果をソートするか、結果のソートに使用するプライマリキー以外の列のセカンダリインデックスを作成することをお勧めします。 また、クエリ結果を降順（ORDER BY DESC）でソートする場合は、テーブルの作成に使用されるステートメントに DESC キーワードを追加することをお勧めします。 このように、データは降順に格納され、最適化されたクエリパフォーマンスが提供されます。 ORDER BY 句の使用方法の詳細については、「大きな結果セットで ORDER BY を使用する」をご参照ください。

COUNT クエリ

Lindorm は、LSM ツリーストレージ構造に基づいて構築された NoSQL データベースサービスです。 この構造では、データは複数回変更または削除される可能性があるため、複数のバージョンのデータと削除マーカーが格納されます。 したがって、Lindorm の基盤となるストレージは、各テーブルの行数をテーブルメタデータに格納しません。 テーブルの行数を正確にクエリするには、テーブル内のすべてのデータをスキャンする必要があります。 したがって、大量のデータを含むテーブルの行数をクエリするには、長い時間がかかります。 テーブルの推定行数のみを取得する必要がある場合は、「テーブルの行数をカウントする」をご参照ください。

COUNT クエリで条件が指定されている場合、クエリの期間は、指定された条件下でスキャンする必要があるデータ量によって異なります。 たとえば、SELECT count(*) FROM table WHERE channel = 'alipay'; ステートメントを実行すると、channel 列の値が alipay である行数がカウントされます。