メインコンテンツまでスキップ
バージョン: 3.2

ユニークキーテーブル

テーブルを作成する際に、プライマリキー列とメトリック列を定義できます。これにより、同じプライマリキーを持つレコード群の中で最も新しいレコードをクエリで返すことができます。重複キーテーブルと比較して、ユニークキーテーブルはデータロードプロセスを簡素化し、リアルタイムかつ頻繁なデータ更新をより良くサポートします。

シナリオ​

ユニークキーテーブルは、データがリアルタイムで頻繁に更新される必要があるビジネスシナリオに適しています。例えば、eコマースのシナリオでは、1日に数億件の注文が行われ、注文のステータスが頻繁に変わります。

原理​

ユニークキーテーブルは、同じプライマリキーを持つレコード群の中で最も新しいレコードを返すために、メトリック列に REPLACE 集計関数が指定された特別な集計テーブルと考えることができます。

ユニークキーテーブルを使用するテーブルにデータをロードする際、データは複数のバッチに分割されます。各バッチにはバージョン番号が割り当てられます。そのため、同じプライマリキーを持つレコードは複数のバージョンで存在する可能性があり、その中で最も新しいバージョン（つまり、最大のバージョン番号を持つレコード）がクエリで取得されます。

次の表に示すように、ID はプライマリキー列、value はメトリック列、_version は StarRocks 内で生成されたデータバージョン番号を保持します。この例では、ID が 1 のレコードはバージョン番号が 1 と 2 の2つのバッチでロードされ、ID が 2 のレコードはバージョン番号が 3、4、5 の3つのバッチでロードされます。

IDvalue_version
11001
11012
21003
21014
21025

ID が 1 のレコードをクエリすると、最も新しいバージョン番号 2 を持つレコードが返されます。ID が 2 のレコードをクエリすると、最も新しいバージョン番号 5 を持つレコードが返されます。次の表は、2つのクエリで返されるレコードを示しています。

IDvalue
1101
2102

テーブルの作成​

eコマースのシナリオでは、日付ごとに注文のステータスを収集し分析する必要があります。この例では、orders という名前のテーブルを作成し、注文を保持します。create_time と order_id をプライマリキー列として定義し、注文をフィルタリングする条件として頻繁に使用されるようにします。他の2つの列、order_state と total_price をメトリック列として定義します。これにより、注文のステータスが変わるたびにリアルタイムで更新され、クエリを高速化するために迅速にフィルタリングできます。

テーブルを作成するためのステートメントは次のとおりです。

CREATE TABLE IF NOT EXISTS orders (
    create_time DATE NOT NULL COMMENT "create time of an order",
    order_id BIGINT NOT NULL COMMENT "id of an order",
    order_state INT COMMENT "state of an order",
    total_price BIGINT COMMENT "price of an order"
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id);

注意

  • テーブルを作成する際には、DISTRIBUTED BY HASH 句を使用してバケット列を指定する必要があります。詳細については、バケット化 を参照してください。
  • バージョン 2.5.7 以降、StarRocks はテーブルを作成する際やパーティションを追加する際に、バケット数（BUCKETS）を自動的に設定できます。バケット数を手動で設定する必要はありません。詳細については、バケット数の設定 を参照してください。

使用上の注意​

  • テーブルのプライマリキーについて、以下の点に注意してください。

    • プライマリキーは UNIQUE KEY キーワードを使用して定義されます。
    • プライマリキーは、ユニーク制約が適用され、名前を変更できない列に作成する必要があります。
    • プライマリキーは適切に設計する必要があります：
      • クエリが実行される際、プライマリキー列は複数のデータバージョンの集約前にフィルタリングされ、メトリック列は複数のデータバージョンの集約後にフィルタリングされます。したがって、フィルタ条件として頻繁に使用される列を特定し、これらの列をプライマリキー列として定義することをお勧めします。これにより、複数のデータバージョンの集約前にデータフィルタリングを開始でき、クエリパフォーマンスを向上させることができます。
      • 集約プロセス中に、StarRocks はすべてのプライマリキー列を比較します。これは時間がかかり、クエリパフォーマンスを低下させる可能性があります。したがって、多数のプライマリキー列を定義しないでください。クエリのフィルタ条件としてほとんど使用されない列は、プライマリキー列として定義しないことをお勧めします。

  • テーブルを作成する際、テーブルのメトリック列に BITMAP インデックスやブルームフィルターインデックスを作成することはできません。

  • ユニークキーテーブルはマテリアライズドビューをサポートしていません。

次のステップ​

テーブルが作成された後、さまざまなデータ取り込み方法を使用して StarRocks にデータをロードできます。StarRocks がサポートするデータ取り込み方法については、ロードオプション を参照してください。

注記
  • ユニークキーテーブルを使用するテーブルにデータをロードする際、テーブルのすべての列を更新する必要があります。例えば、前述の orders テーブルを更新する際には、create_time、order_id、order_state、total_price のすべての列を更新する必要があります。
  • ユニークキーテーブルを使用するテーブルからデータをクエリする際、StarRocks は複数のデータバージョンのレコードを集約する必要があります。この状況では、多数のデータバージョンがクエリパフォーマンスを低下させます。したがって、リアルタイムデータ分析の要件を満たしつつ、多数のデータバージョンを防ぐために、テーブルにデータをロードする適切な頻度を指定することをお勧めします。分単位のデータが必要な場合は、1秒のロード頻度ではなく、1分のロード頻度を指定できます。