Lindorm:AP モードの列指向テーブルへのアクセス

テーブルは、データストレージメソッドに基づいて、明細テーブルとプライマリキーテーブルの 2 種類に分類されます。

• 明細テーブル：インポートされたすべてのレコードを保持し、プライマリキーの重複を許可します。データの完全な履歴をクエリできます。各レコードは、生データの 1 つのエントリに対応します。

• プライマリキーテーブル：プライマリキーの一意性制約を適用します。プライマリキーの重複は禁止されます。新しいデータは、同じプライマリキーを持つ既存のレコードを上書きします。これにより、各レコードの最新バージョンのみが保持されることが保証されます。

明細テーブルの作成

テーブルを作成するには、CREATE TABLE 文で列とそのデータ型を定義します。

CREATE TABLE user_access (
    uid int,
    name varchar(64),
    age int, 
    phone varchar(16),
    last_access datetime,
    credits double
)
ORDER BY (uid, name);

上記の例では、明細テーブルを作成しています。このテーブルには制約がなく、プライマリキーの重複が許可されるため、同じデータ行が複数回出現する可能性があります。最初の 2 つの列はソート列として指定され、ソートキーを形成します。データは、このキーに基づいてソートおよび格納されます。この構成により、インデックス効率が大幅に向上し、クエリ時の高速なデータ検索が可能になります。

プライマリキーテーブルの作成

プライマリキーテーブルの主な利点は、リアルタイムデータ更新と、効率的で複雑なアドホッククエリをサポートしている点です。リアルタイム分析では、プライマリキーテーブルを使用して最新のデータを処理して意思決定を行い、T+1 のデータ遅延をなくすことができます。プライマリキーテーブルを作成するには、CREATE TABLE 文の PRIMARY KEY 句を使用してプライマリキーを定義します。

CREATE TABLE orders1 (
    order_id bigint NOT NULL,
    dt date NOT NULL,
    user_id INT NOT NULL,
    good_id INT NOT NULL,
    cnt int NOT NULL,
    revenue int NOT NULL
)
PRIMARY KEY (order_id)
DISTRIBUTED BY HASH (order_id)
;

プライマリキーテーブルは、ハッシュバケットポリシーのみをサポートします。テーブルを作成する際には、DISTRIBUTED BY HASH() を使用してハッシュバケットキーを指定する必要があります。

実際のアプリケーションでは、データ分布やソートキーなどの特徴を組み合わせて、クエリ効率とデータ管理を向上させることができます。プライマリキーテーブルでは、プライマリキーとソートキーが分離されているため、頻繁に使用するクエリ条件に基づいてソートキーを柔軟に設計できます。たとえば、注文日 (dt) とマーチャント ID (merchant_id) で販売データを頻繁にクエリする場合、ソートキーを ORDER BY (dt,merchant_id) に設定できます。これにより、範囲クエリの効率が大幅に向上します。

データ分布

テーブルを作成する際に、適切なパーティションとバケットを設定することで、均等なデータ分布を実現し、クエリパフォーマンスを向上させることができます。均等なデータ分布とは、データが特定のルールに基づいてサブセットに分割され、異なるノード間でバランスが取れている状態を指します。クエリ時には、これによりスキャンされるデータ量が効果的に削減され、クラスターの同時実行パフォーマンスが最大化されるため、クエリ速度が向上します。

CREATE TABLE t_recharge_detail1 (
    id bigint,
    user_id bigint,
    recharge_money decimal(32,2), 
    city varchar(20) not null,
    dt varchar(20) not null
)
DUPLICATE KEY(id)
PARTITION BY dt,city
DISTRIBUTED BY HASH(`id`);