メインコンテンツまでスキップ

Unique Key table

ユニークキーテーブル

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

シナリオ

Unique Key テーブルは、データをリアルタイムに頻繁に更新する必要があるビジネスシナリオに適しています。 たとえば、電子商取引のシナリオでは、1日に数億件の注文がある可能性があり、注文の状態は頻繁に変更されることがあります。

原則

Unique Key テーブルは、同じプライマリキーを持つレコードの中で最新のレコードを返すためにメトリックカラムに REPLACE 集計関数が指定された特殊な Aggregate Key テーブルと考えることができます。

Unique Key テーブルを使用するテーブルにデータをロードする場合、データは複数のバッチに分割されます。各バッチにはバージョン番号が割り当てられます。したがって、同じプライマリキーを持つレコードは複数のバージョンで入力される可能性がありますが、最新のバージョン(すなわち、最大のバージョン番号を持つレコード)がクエリに取得されます。

以下のテーブルに示すように、ID はプライマリキーカラム、value はメトリックカラム、 _version は StarRocks 内で生成されたデータのバージョン番号を保持しています。この例では、ID1 のレコードは、バージョン番号が 12 の2つのバッチでロードされ、ID2 のレコードは、バージョン番号が 345 の3つのバッチでロードされています。

ID

value

_version

1

100

1

1

101

2

2

100

3

2

101

4

2

102

5

ID1 のレコードをクエリする場合、最新のレコードであるバージョン番号が 2 のレコードが返されます。ID2 のレコードをクエリする場合、最新のレコードであるバージョン番号が 5 のレコードが返されます。以下のテーブルには、これらのクエリによって返されるレコードが示されています。

ID

value

1

101

2

102

テーブルの作成

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

テーブルを作成するためのステートメントは次のようになります:

CREATE TABLE IF NOT EXISTS orders (
create_time DATE NOT NULL COMMENT "注文の作成日時",
order_id BIGINT NOT NULL COMMENT "注文のID",
order_state INT COMMENT "注文の状態",
total_price BIGINT COMMENT "注文の価格"
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id);

NOTICE

  • テーブルを作成する際には、DISTRIBUTED BY HASH 句を使用してバケット化カラムを指定する必要があります。詳細については、bucketing を参照してください。
  • v2.5.7以降、StarRocksはテーブルの作成またはパーティションの追加時に自動的にバケットの数(BUCKETS)を設定することができます。バケットの数を手動で設定する必要はもうありません。詳細については、バケットの数を決める を参照してください。

使用上の注意点

  • テーブルのプライマリキーに関しては、以下のポイントに注意してください:
    • プライマリキーは UNIQUE KEY キーワードを使用して定義されます。
    • プライマリキーは一意制約が適用され、その名前を変更できないカラムに作成する必要があります。
    • プライマリキーは適切に設計する必要があります:
      • クエリが実行される際、プライマリキーカラムは複数のデータバージョンの集計の前にフィルタリングされ、メトリックカラムは複数のデータバージョンの集計の後にフィルタリングされます。したがって、フィルタ条件として頻繁に使用されるカラムを特定し、これらのカラムをプライマリキーカラムとして定義することをお勧めします。これにより、データのフィルタリングが複数のデータバージョンの集計よりも前に開始され、クエリのパフォーマンスが向上します。
      • 集計プロセスでは、StarRocksはすべてのプライマリキーカラムを比較します。これは時間がかかり、クエリのパフォーマンスが低下する可能性があります。したがって、多数のプライマリキーカラムを定義しないでください。クエリのフィルタ条件としてあまり使用されないカラムの場合は、プライマリキーカラムとして定義しないことをお勧めします。
  • テーブルを作成する際、メトリックカラムには BITMAP インデックスや Bloom Filter インデックスを作成することはできません。
  • Unique Key テーブルは、マテリアライズドビューをサポートしていません。

次の手順

テーブルが作成されたら、さまざまなデータインジェクション方法を使用してデータを StarRocks にロードすることができます。StarRocks でサポートされているデータインジェクション方法については、データのインポートを参照してください。

  • Unique Key テーブルを使用するテーブルにデータをロードする場合、テーブルのすべてのカラムを更新することしかできません。たとえば、前述の orders テーブルを更新する場合、create_timeorder_idorder_statetotal_price のすべてのカラムを更新する必要があります。
  • Unique Key テーブルを使用するテーブルからデータをクエリする場合、StarRocks は複数のデータバージョンのレコードを集計する必要があります。この状況では、大量のデータバージョンはクエリのパフォーマンスを低下させます。そのため、リアルタイムデータ分析の要件を満たしつつ、大量のデータバージョンを防ぐために適切な頻度でデータをテーブルにロードするように指定することをお勧めします。分単位のデータを必要とする場合は、秒単位ではなく分単位の頻度でデータをロードすることができます。