データパーティショニングポリシーとその使用方法 - Lindorm

パーティションインデックスは、大規模なワイドテーブルのストレージと高同時実行アクセスに関する課題に対処するために設計された機能です。検索インデックスを作成する際に、データパーティショニングポリシーを指定できます。その後、サーバーはデータを自動的に分割して保存します。クエリ中に、システムは自動的にパーティションプルーニングを実行します。このトピックでは、データパーティショニングポリシーとその使用方法について説明します。

前提条件

シナリオ

Lindorm 検索インデックスは、ハッシュパーティションと時系列パーティションの 2 つのパーティショニングポリシーを提供します。以下で説明するビジネスシナリオに基づいてポリシーを選択できます。

ハッシュパーティション
- クエリパーティションプルーニング: クエリ条件に常に特定の列に対する等価クエリが含まれる場合は、その列でハッシュパーティションを使用することを検討してください。このメソッドにより、同一の値が常に同じパーティショングループにルーティングされるようになります。クエリ中に、パーティションプルーニングを使用して、クエリ値を含む特定のパーティションからのみデータを取得できます。たとえば、デバイスのテーブルの場合、クエリ条件に常にデバイス ID が含まれる場合は、デバイス ID 列をハッシュパーティションキーとして設定できます。
- パーティションストレージの分散: ハッシュパーティションキーを選択する際には、データ分布も考慮する必要があります。選択したパーティションキーがデータのホットスポットを引き起こす場合は、多階層ハッシュパーティション機能を使用して、データを複数のパーティションにさらに均等に分散させることができます。
時系列パーティション
- クエリパーティションプルーニング: ビジネスデータに、IoV (Internet of Vehicles)、注文詳細、メッセージログなどの時間属性があり、クエリで時間範囲を頻繁に使用する場合は、時系列パーティションを使用できます。たとえば、過去 7 日間または過去 1 か月間の注文データをクエリする場合があります。この機能は、指定された時間範囲に基づいてクエリの範囲を特定のシャードに絞り込みます。
- 単一シャードのストレージ制限の制御: 単一のインデックスまたはシャードが大量のデータを保存している場合、その書き込みおよびクエリのパフォーマンスに影響が及ぶ可能性があります。インデックスデータが急速に増加する場合は、時系列パーティションポリシーを使用して、単一シャード内のデータ量を制御できます。

準備

パーティションインデックスを使用する前に、次の文を使用してテストテーブルを作成します。

CREATE TABLE IF NOT EXISTS search_table (user_id BIGINT, storeId VARCHAR, goodsId VARCHAR, goodsPrice SMALLINT, orderTime BIGINT, info VARCHAR, PRIMARY KEY (user_id asc));

ハッシュパーティション

Lindorm 検索インデックスは、最大 3 レベルのパーティショニングをサポートします。ハッシュパーティションの構成は、作成後に変更することはできません。以下の例は、ハッシュパーティションの構文を示しています。

プライマリパーティション

検索インデックスを作成します。デフォルトでは、ハッシュパーティションはワイドテーブルのプライマリキーに基づいています。デフォルトのパーティション数は、検索ノード数の 2 倍です。
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice);
```
storeId 列でハッシュパーティション分割され、64 個のパーティションを持つ検索インデックスを作成します。PARTITION BY hash(storeId) 句は storeId をパーティションキーとして指定し、partitions 64 句はパーティション数を 64 に設定します。
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice) PARTITION BY hash(storeId) PARTITIONS 64;
```
説明
ハッシュパーティションを使用する場合は、データ量に基づいて必要なパーティション数を見積もる必要があります。単一のパーティションには 5,000 万から 1 億のレコードを含め、ストレージサイズは 30 GB から 50 GB にする必要があります。

多階層パーティション

インデックスの総データ量が大きい (数百億レコード以上) 場合で、プライマリパーティションキーによってデータ分布が不均一になる場合は、多階層パーティションを使用してデータ分布を最適化できます。

重要

ワイドテーブルエンジンはバージョン 2.8.1 以降である必要があります。検索エンジンはバージョン 3.9.22 以降である必要があります。
多階層パーティションは、時系列パーティションと併用できません。

ワイドテーブルの storeId 列と goodsId 列に基づいてハッシュパーティション分割された検索インデックスを作成します。これらの列の salt 係数 (salt_factor) をそれぞれ 2 と 4 に設定します。partitions 64 句は、パーティションの総数を 64 に設定します。
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice) PARTITION BY hash(storeId(salt_factor=2), goodsId(salt_factor=4)) partitions 64;
```
説明
パーティションの salt 係数 (salt_factor) は、異なるパーティションキー値のハッシュ化の度合いを制御する小さな整数です。次の手順に従って、パーティションの総数と各パーティションキーの salt 係数を決定します。
1. 総データ量に基づいて必要なパーティション数を見積もります。次に、見積もりに近い 2 のべき乗 ( $2^{N}$ ) をパーティションの総数として選択します。たとえば、総データ量が 20 億エントリで、各パーティションに約 5,000 万エントリが含まれる場合、約 40 個のパーティションが必要です。この場合、パーティションの総数として $64 = 2^{6}$ を選択できます。
2. パーティションの総数が $2^{6}$ の場合、すべてのパーティションキーの salt 係数の合計は 6 である必要があります。salt 係数を割り当てて、異なるパーティションキーのハッシュ範囲を制御できます。
  たとえば、storeId の salt 係数が 2 で、goodsId の salt 係数が 4 の場合、storeId の値が同じで goodsId の値が異なるデータは、総パーティションの $1/ 2^{2} = 1/4$ に分散されます。storeId の salt 係数が 3 で、goodsId の salt 係数が 3 の場合、storeId の値が同じで goodsId の値が異なるデータは、総パーティションの $1/ 2^{3} = 1/8$ に分散されます。
_id をセカンダリパーティションキーとして使用してパーティションインデックスを作成します。
説明
プライマリパーティションキーによってデータ分布が不均一になり、ビジネスに適したセカンダリパーティションキーがない場合は、セカンダリパーティションキーとして _id を指定します。`_id` は、ワイドテーブルの複合プライマリキーに対応します。
```
CREATE INDEX IF NOT EXISTS idx USING SEARCH ON search_table (storeId, goodsId, goodsPrice) PARTITION BY hash(storeId(salt_factor=2), _id(salt_factor=4)) partitions 64;
```

時系列パーティション

注文データやメッセージログなどの時系列データの場合、時間列を指定して、時間範囲でデータをパーティション分割できます。たとえば、週または月ごとにデータをパーティション分割できます。同じ時間範囲内のデータは同じパーティションに保存され、古いパーティションのデータは TTL ポリシーに基づいて自動的に削除できます。

インデックスを作成し、ビジネス時間列 orderTime でパーティション分割します。RANGE_TIME_PARTITION_START='30' は、30 日前からパーティションが作成されることを指定します。RANGE_TIME_PARTITION_INTERVAL='7' は、7 日ごとに新しいパーティションを自動的に作成します。RANGE_TIME_PARTITION_TTL='90' は、パーティションデータのデフォルトの Time to Live (TTL) を 90 日に設定します。90 日より古いデータは自動的に削除されます。
```
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'
);
```
重要
RANGE_TIME_PARTITION_START パラメーターは、パーティション分割の開始時刻を制御します。パーティションの作成を開始する現在の日付の何日前かを指定します。
たとえば、`orderTime` 列の最も古い日付が 2021 年 3 月 16 日であるとします。すべての既存データを保持するには、2021 年 3 月 16 日とインデックスを作成する日の間の日数を計算する必要があります。次に、この数値を RANGE_TIME_PARTITION_START パラメーターの値として設定します。開始時刻が設定されると、開始時刻より前の `orderTime` 値を持つレコードはインデックス付けされません。
ビジネス時間列 orderTime でパーティション分割されたインデックスを作成し、6 か月前から毎月新しいパーティションが自動的に作成されるようにします。デフォルトでは、データは 6 か月間保持され、パーティションフィールドの単位は秒 (s) に設定されます。
```
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	はい	インデックス作成の何日前にパーティションの作成を開始するかを指定します。これは、既存データがあるシナリオに適用されます。既存データのタイムスタンプがパーティションの開始時刻より前の場合、エラーが報告されます。
RANGE_TIME_PARTITION_INTERVAL	はい	新しいパーティションを作成する間隔を日数で指定します。たとえば、`RANGE_TIME_PARTITION_INTERVAL='7'` は、毎週新しいパーティションが作成されることを意味します。
RANGE_TIME_PARTITION_TTL	いいえ	パーティションデータを保持する日数を指定します。たとえば、`RANGE_TIME_PARTITION_TTL='180'` は、パーティションデータが 6 か月間保持されることを意味します。既存のパーティションデータは自動的にクリアされます。
RANGE_TIME_PARTITION_FIELD_TIMEUNIT	いいえ	ビジネスの時系列パーティションフィールドの単位を指定します。デフォルトの単位はミリ秒 (ms) です。単位が秒 (s) に設定されている場合、数値は 10 桁の長さになります。単位がミリ秒 (ms) に設定されている場合、数値は 13 桁の長さになります。
RANGE_TIME_PARTITION_MAX_OVERLAP	いいえ	書き込まれるデータに未来のタイムスタンプがある場合、このパラメーターは未来のタイムスタンプと現在の時刻との間の最大許容間隔を日数で指定します。指定しない場合、制限はありません。
RANGE_TIME_PARTITION_FORMAT	いいえ	ビジネスの時系列パーティションフィールドの書き込みフォーマットを指定します。デフォルト値は `date_optional_time\|\|epoch_millis` です。このパラメーターは、プライマリテーブルの時系列パーティションフィールドが VARCHAR 型の場合に有効になります。