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

Lindorm:パーティションインデックス

最終更新日:Jan 14, 2025

パーティションインデックス機能は、大量のデータを格納するワイドテーブルを使用する場合のストレージの問題と、高並列アクセスによって発生する問題を解決するために使用されます。テーブルの検索インデックスを作成するときに、データパーティションポリシーを指定できます。サーバーは、テーブル内のデータを自動的にパーティション化して格納します。データをクエリすると、LindormTable は自動的にパーティションプルーニングを実行します。このトピックでは、データパーティションポリシーとポリシーの使用方法について説明します。

前提条件

シナリオ

  • ビジネスデータに時間属性があります。このようなビジネスデータの例としては、車載インターネット (IoV) のデータ、注文の詳細、メッセージログなどがあります。

  • ビジネスデータには、データを分類するために使用できる特性があります。たとえば、加盟店データテーブルのデータは加盟店 ID に基づいて分類され、加盟店 ID を持つ列をクエリ条件として指定します。IoT デバイスデータテーブルのデータはデバイス ID に基づいて分類され、デバイス ID を持つ列をクエリ条件として指定します。

データパーティションポリシー

準備

パーティションインデックス機能を使用する前に、次のステートメントを実行してテストテーブルを作成する必要があります。

CREATE TABLE IF NOT EXISTS search_table (user_id bigint, storeId varchar, goodsId varchar, goodsPrice smallint, orderTime bigint, info varchar, constraint primary key (user_id asc));

HASH パーティション

このポリシーを使用すると、対応するデータがハッシュ化されて格納されます。これにより、データ分布の不均衡を防ぎます。大量のデータが書き込まれるシナリオでこのポリシーを使用すると、データ分布のバランスをとることができます。デフォルトでは、検索インデックス機能は、Lindorm インスタンスのワイドテーブルのプライマリキーに基づいて HASH パーティションを実行します。カスタム HASH パーティションキーを指定することもできます。

次のサンプルコードは、HASH パーティションを実行する方法の例を示しています。

  • 検索インデックスを作成し、HASH パーティションを実行します。デフォルトでは、HASH パーティションはワイドテーブルのプライマリキーに基づいて実行され、パーティションの数は 検索ノード数の 2 倍 です。

    CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice);
  • 検索インデックスを作成し、パーティションの数を 64 に設定し、ワイドテーブルの storeId 列に基づいて HASH パーティションを実行します。この場合、第 1 レベルの HASH パーティションが実行されます。

    CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice) partition by hash(storeId) partitions 64;
    重要
    • ほとんどのクエリで列が条件として使用されている場合は、その列をカスタムパーティションキーとして指定できます。

    • カスタムパーティションキーを使用するシナリオでは、要件に基づいて partitions をより大きな値に設定できます。パーティション数の構成方法がわからない場合は、テストのために 64 に設定できます。

    • ワイドテーブルの 1 つの列に基づいて HASH パーティションを実行し、パーティションキーとして指定された列に頻繁にアクセスされるデータがある場合、大量のデータがパーティションに書き込まれる可能性があります。たとえば、テーブル内のデータの 10% を storeId 列に基づいてクエリできます。これにより、クエリパフォーマンスと書き込みパフォーマンスが低下します。この場合、第 1 レベルの HASH パーティションが実行されます。ワイドテーブルの 2 つまたは 3 つの列に基づいてマルチレベル HASH パーティションを実行することをお勧めします。この場合、第 2 レベルの HASH パーティションまたは第 3 レベルの HASH パーティションが実行されます。詳細については、「マルチレベルハッシュパーティション (高度な使用方法)」をご参照ください。

    • カスタムパーティションキーの制限:
      • パーティションキーの値は変更できません。
      • パーティションキーの値を空にすることはできません。

時間範囲パーティション

時系列データに対して時間範囲パーティションを実行できます。たとえば、週または月に基づいて時間範囲パーティションを実行できます。時系列データに対して時間範囲パーティションを実行すると、同じ時間範囲内のデータを同じパーティションに格納でき、パーティション内の期限切れのデータを自動的に削除できます。

次のサンプルコードは、時系列データに対して時間範囲パーティションを実行する方法の例を示しています。

  • インデックスを作成し、最初のパーティションがインデックスを作成した時点の 30 日前に基づいて作成されるように指定し、新しいパーティションが作成される間隔を 7 日に設定し、パーティション内のデータの保持期間を 90 日に設定し、orderTime 列で時間範囲パーティションを実行します。

    CREATE INDEX idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice, orderTime)
    partition by range time(orderTime) partitions 4
    with (indexState=ACTIVE, RANGE_TIME_PARTITION_START='30', RANGE_TIME_PARTITION_INTERVAL='7', RANGE_TIME_PARTITION_TTL='90');
  • インデックスを作成し、最初のパーティションがインデックスを作成した時点の 180 日前に基づいて作成されるように指定し、新しいパーティションが作成される間隔を 30 日に設定し、パーティション内のデータの保持期間を 180 日に設定し、パーティションキー列の値の単位を秒に設定し、orderTime 列で時間範囲パーティションを実行します。

    CREATE INDEX idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice, orderTime)
    partition by range time(orderTime) partitions 4 
    with (indexState=ACTIVE, RANGE_TIME_PARTITION_START='180', RANGE_TIME_PARTITION_INTERVAL='30', RANGE_TIME_PARTITION_TTL='180', RANGE_TIME_PARTITION_FIELD_TIMEUNIT='s');

次の表は、上記のコードで使用されているパラメーターについて説明しています。

パラメーター

必須

説明

RANGE_TIME_PARTITION_START

はい

インデックスを作成する前の日数。最初のパーティションは、インデックスを作成した時点の n 日前の時点に基づいて作成されます。日数は n の値です。このパラメーターは、テーブルに履歴データがあるシナリオで指定できます。履歴データの行のタイムスタンプが、最初のパーティションが作成された時点よりも前の場合、エラーメッセージが返されます。

RANGE_TIME_PARTITION_INTERVAL

はい

新しいパーティションが作成される間隔。たとえば、RANGE_TIME_PARTITION_INTERVAL を '7' に設定すると、7 日間隔でパーティションが作成されます。

RANGE_TIME_PARTITION_TTL

いいえ

パーティション内のデータの保持期間。たとえば、RANGE_TIME_PARTITION_TTL を '180' に設定すると、保持期間は 180 日になり、パーティションに 180 日以上保持されているデータは自動的に削除されます。

RANGE_TIME_PARTITION_FIELD_TIMEUNIT

いいえ

パーティションキー列の値の単位。デフォルト値:ms。値 ms はミリ秒を意味します。

  • このパラメーターの値を s に設定すると、パーティションキー列の各値の長さは 10 桁になります。値 s は秒を意味します。

  • このパラメーターの値を ms に設定すると、パーティションキー列の各値の長さは 13 桁になります。

マルチレベルハッシュパーティション (高度な使用方法)

salt_factor を 4 に設定し、パーティションの数を 64 に設定し、Lindorm インスタンスのワイドテーブルの storeId 列と goodsId 列に基づいて HASH パーティションを実行します。この場合、第 2 レベルの HASH パーティションが実行されます。

// storeId 列の値が同じで goodsId 列の値が異なるデータは、4 つのパーティションに個別に格納されます。
CREATE SEARCH INDEX idx ON search_table (storeId, goodsId, goodsPrice) partition by hash(storeId(salt_factor=4),goodsId) partitions 64;
重要
  • salt_factor パラメーターは、storeId フィールドの値が同じデータ行をパーティション化するために使用されます。salt_factor パラメーターを小さい値に設定することをお勧めします。サブパーティションの数は、salt_factor パラメーターの値の 2 の累乗の結果によって決まります。パーティションの数が 16 で、salt_factor パラメーターの値が 4 より大きい場合、HASH パーティション戦略を使用してデータパーティションをサブパーティションに分割することはできません。salt_factor パラメーターの値に基づいてパーティションを再ハッシュする方法の例:
    • salt_factor=1: storeId フィールドの値が同じで goodsId フィールドの値が異なるデータ行が、パーティションの総数の 1/2 に等しい数のサブパーティションにパーティション化されることを指定します。
    • salt_factor=2: storeId フィールドの値が同じで goodsId フィールドの値が異なるデータ行が、パーティションの総数の 1/4 に等しい数のサブパーティションにパーティション化されることを指定します。
    • salt_factor=3: storeId フィールドの値が同じで goodsId フィールドの値が異なるデータ行が、パーティションの総数の 1/8 に等しい数のサブパーティションにパーティション化されることを指定します。
  • レベル 2 HASH パーティションとレベル 3 HASH パーティションを含むマルチレベル HASH パーティションを使用して、データパーティションを分割し、クエリ効率を大幅に向上させることができます。たとえば、storeId 列の値と goodsId 列の値に基づいてデータをパーティション化する場合、storeId 列と goodsId 列の両方基づいてクエリ条件が指定されている場合、LindormSearch は 1 つのパーティションのみをスキャンします。これにより、システムがスキャンするデータスコープが削減され、クエリ効率が向上します。
  • 2 レベル HASH パーティション方式を使用する場合は、レベル 1 パーティションキーのソルトファクターを指定する必要があります。上記の例では、レベル 1 パーティションキーは storeId 列です。3 レベル HASH パーティション方式を使用する場合は、レベル 1 パーティションキーのソルトファクターとレベル 2 パーティションキーのソルトファクターを指定する必要があります。
  • カスタムパーティションキーの制限:
    • パーティションキーの値は変更できません。
    • パーティションキーの値を空にすることはできません。