クエリシナリオに基づいてテーブルプロパティを設定する - Hologres

Hologresでは、さまざまなテーブルプロパティを設定できます。テーブルプロパティごとに特性が異なります。このトピックでは、クエリシナリオに基づいてテーブルプロパティを設定する方法について説明します。適切なテーブルプロパティを使用すると、クエリでスキャンされるデータ量、アクセスされるファイル数、および I/O 操作数を減らすことができます。このようにして、クエリが高速になり、1 秒あたりのクエリ数（QPS）が高くなります。

テーブルのストレージ形式を決定する

Hologresは、行指向ストレージ、列指向ストレージ、および行と列のハイブリッドストレージをサポートしています。これらのストレージ形式の詳細については、「テーブルのストレージモード：行指向ストレージ、列指向ストレージ、および行と列のハイブリッドストレージ」をご参照ください。

次の図は、テーブルのストレージ形式を決定する方法を示しています。ビジネスシナリオが完全には定義されていない場合は、より多くの可能性のあるシナリオを考慮して、行と列のハイブリッドストレージを使用することをお勧めします。 image..png

テーブルのクエリプロパティを設定する

テーブルのストレージ形式を決定したら、クエリシナリオに基づいてテーブルプロパティを設定する必要があります。

説明

このセクションでは、さまざまなシナリオでテーブルプロパティを設定する方法の例を示します。
例では、64 個のコンピュートユニット（CU）を持つ Hologres インスタンスを使用して、TPC-H 100 GB データセットの Lineitem テーブルと Orders テーブルに対するクエリの性能を検証します。
TPC-H データセットは、小売シナリオのデータをシミュレートします。データセットには、次のテーブルが含まれています。
- Orders テーブル：注文テーブルです。o_orderkey フィールドは注文を一意に識別します。
- Lineitem テーブル：注文詳細テーブルです。o_orderkey フィールドと l_linenumber フィールドは注文内の製品を一意に識別します。
このトピックで説明する TPC-H パフォーマンステストは、TPC-H ベンチマークテストに基づいて実装されていますが、TPC-H ベンチマークテストのすべての要件を満たしているわけではありません。したがって、このトピックで説明するテスト結果は、公開されている TPC-H ベンチマークテストの結果と比較することはできません。
テーブルが、異なるフィルター条件または JOIN フィールドを持つ複数のクエリシナリオで使用される場合は、クエリ頻度とパフォーマンス要件に基づいて最適なテーブルプロパティを設定する必要があります。

シナリオ 1：超高 QPS のポイントクエリ

シナリオの説明
TPC-H データセットの Orders テーブルに対して、1 秒あたり数万件のポイントクエリを実行します。o_orderkey フィールドを指定して、データの行を特定できます。SQL ステートメントの例：
```
SELECT * FROM orders WHERE o_orderkey = ?;
```
設定の推奨事項
フィルターフィールドをプライマリキーとして設定することをお勧めします。Hologres は、プライマリキーに基づいてクエリを高速化するための固定プランを提供します。これにより、実行効率が大幅に向上します。詳細については、「固定プランを使用して SQL ステートメントの実行を高速化する」をご参照ください。
パフォーマンス検証
Orders テーブルを行指向テーブルまたは行と列のハイブリッドテーブルとして定義します。o_orderkey フィールドがプライマリキーとして設定されている場合と、プライマリキーが設定されていない場合のクエリパフォーマンスを検証します。テーブル作成ステートメントの詳細については、「シナリオ 1 の DDL ステートメント」をご参照ください。
検証結果：
- プライマリキーが設定されている場合：一度に約 500 件のクエリがトリガーされ、平均 QPS は約 104,000 で、平均レイテンシは約 4 ms です。
- プライマリキーが設定されていない場合：一度に約 500 件のクエリがトリガーされ、平均 QPS は約 16,000 で、平均レイテンシは約 30 ms です。

シナリオ 2：少量のデータに対する高 QPS のプレフィックススキャン

シナリオの説明
次の要件を持つシナリオでクエリを実行します。
- クエリ対象のテーブルの複数のフィールドがプライマリキーを構成しています。
- 数万件の QPS を処理する必要があります。プライマリキーのフィールドに基づいてポイントクエリが実行され、返されるデータセットには数個または数十個のデータエントリが含まれます。
たとえば、Lineitem テーブルから、l_orderkey フィールドで指定された注文のすべての製品を高 QPS でクエリします。Lineitem テーブルは、TPC-H データセットの注文詳細テーブルです。このテーブルでは、l_orderkey フィールドと l_linenumber フィールドを指定して、注文内の製品を識別できます。ステートメントの例：
```
SELECT * FROM lineitem WHERE l_orderkey = ?;
```
設定の推奨事項
1. 等価フィルタリングに使用するフィールドをプライマリキーの左端のフィールドとして設定します。この例では、Lineitem テーブルのプライマリキーを (l_orderkey, l_linenumber) に設定しますが、(l_linenumber, l_orderkey) には設定しません。
2. 等価フィルタリングに使用するフィールドを分散キーとして設定して、スキャンする必要があるすべてのデータが同じシャードに格納されるようにします。これにより、アクセスするシャードの数を減らし、QPS を向上させることができます。この例では、Lineitem テーブルの distribution key を l_orderkey に設定します。
3. テーブルで列指向ストレージまたは行と列のハイブリッドストレージ形式を使用する場合は、等価フィルタリングに使用するフィールドをクラスタリングキーとして設定します。これにより、スキャンされるデータエントリがファイル内でフィールドに基づいてソートされ、I/O 操作の数を減らすことができます。この例では、Lineitem テーブルの clustering key を l_orderkey に設定します。
上記の構成では、データをクエリするために単一シャードのプレフィックススキャンのみが必要です。Hologres は、プレフィックススキャンを高速化するための固定プランを提供します。この機能を有効にするには、Grand Unified Configuration（GUC）パラメーター hg_experimental_enable_fixed_dispatcher_for_scan を on に設定します。詳細については、「固定プランを使用して SQL ステートメントの実行を高速化する」をご参照ください。
パフォーマンス検証
Lineitem テーブルを行指向テーブルまたは行と列のハイブリッドテーブルとして定義します。上記の構成を使用する場合と使用しない場合のクエリパフォーマンスを検証します。テーブル作成ステートメントの詳細については、「シナリオ 2 の DDL ステートメント」をご参照ください。
検証結果：
- 上記の構成を使用する場合：一度に約 500 件のクエリがトリガーされ、平均 QPS は約 37,000 で、平均レイテンシは約 13 ms です。
- 上記の構成を使用しない場合：一度に 1 件のクエリのみがトリガーされ、平均 QPS は約 60 で、平均レイテンシは約 16 ms です。

シナリオ 3：時間関連のフィルター条件を持つクエリ

シナリオの説明

時間関連のフィルター条件を持つクエリを実行します。この例では、TPC-H データセットの Lineitem テーブルのデータを、l_shipdate フィールドで指定されたフィルター条件に基づいてクエリします。クエリステートメントの詳細については、「Q1」をご参照ください。SQL ステートメントの例：

-- 元のクエリステートメント
SELECT
    l_returnflag,
    l_linestatus,
    sum(l_quantity) AS sum_qty,
    sum(l_extendedprice) AS sum_base_price,
    sum(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
    sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
    avg(l_quantity) AS avg_qty,
    avg(l_extendedprice) AS avg_price,
    avg(l_discount) AS avg_disc,
    count(*) AS count_order
FROM
    lineitem
WHERE
    l_shipdate <= date '1998-12-01' - interval '120' day
GROUP BY
    l_returnflag,
    l_linestatus
ORDER BY
    l_returnflag,
    l_linestatus;

-- 変更されたクエリステートメント
SELECT ... FROM lineitem
WHERE
    l_year='1992' AND -- 時間関連のフィルター条件は、目的のパーティションテーブルにのみ追加する必要があります。
    l_shipdate <= date '1992-12-01' -- 時間範囲を絞り込んで、効果をわかりやすくしています。
...;

設定の推奨事項
1. Lineitem テーブルを時間に基づいてパーティション分割します。この例では、l_year 列を Lineitem テーブルに追加し、l_year フィールドをパーティションキーとして設定して、Lineitem テーブルを年ごとにパーティション分割します。データ量とビジネス要件に基づいて、テーブルをパーティション分割するか、event_time_column プロパティのみを設定するかを決定します。パーティションテーブルの制限と使用上の注意の詳細については、「CREATE PARTITION TABLE」をご参照ください。
2. 時間フィルターフィールドを event_time_column プロパティとして設定して、シャード内のファイルのデータエントリが event_time_column プロパティに基づいて順番にソートされるようにします。これにより、スキャンされるファイルの数が減ります。この例では、Lineitem テーブルの l_shipdate フィールドを event_time_column プロパティとして設定します。event_time_column プロパティの原則と使用方法の詳細については、「イベントタイム列（セグメントキー）」をご参照ください。
パフォーマンス検証
Lineitem テーブルを列指向テーブルとして定義します。パーティションと event_time_column プロパティが推奨どおりに設定されている場合と、パーティションが設定されておらず、別のフィールドが event_time_column プロパティとして設定されている場合のクエリパフォーマンスを検証します。テーブル作成ステートメントの詳細については、「シナリオ 3 の DDL ステートメント」をご参照ください。
検証結果：
- パーティションと event_time_column が推奨どおりに設定されている場合：1 つのパーティションの 80 個のファイルがスキャンされます。
- パーティションが設定されておらず、event_time_column が別のフィールドに設定されている場合：データはパーティションによってフィルタリングされず、320 個のファイルがスキャンされます。
説明
EXPLAIN ANALYZE ステートメントを実行して、Partitions selected パラメーターで指定されたスキャンされたパーティションの数と、dop パラメーターで指定されたスキャンされたファイルの数を表示できます。

シナリオ 4：時間関連でない単一値のフィルター条件を持つクエリ

シナリオの説明
時間関連でない単一値のフィルター条件を持つクエリを実行します。この例では、TPC-H データセットの Lineitem テーブルのデータを、l_shipmode フィールドで指定された時間関連でない単一値のフィルター条件に基づいてデータ集計用にクエリします。クエリステートメントの詳細については、「Q1」をご参照ください。SQL ステートメントの例：
```
SELECT
    ...
FROM
    lineitem
WHERE
    l_shipmode IN ('FOB', 'AIR');
```
設定の推奨事項
1. 単一値フィールドをクラスタリングキーとして設定して、同じ値を持つデータエントリがファイル内で連続してソートされるようにします。これにより、I/O 操作が削減されます。この例では、Lineitem テーブルの l_shipmode フィールドをクラスタリングキーとして設定します。
2. 目的のデータを特定するプロセスを高速化するために、単一値フィールドのビットマップインデックスを作成します。この例では、Lineitem テーブルの l_shipmode フィールドをビットマップ列プロパティとして設定します。
パフォーマンス検証
Lineitem テーブルを列指向テーブルとして定義します。テーブルプロパティが推奨どおりに設定されている場合と、l_shipmode フィールドがクラスタリングキーまたはビットマップ列プロパティとして設定されていない場合のクエリパフォーマンスを検証します。テーブル作成ステートメントの詳細については、「シナリオ 4 の DDL ステートメント」をご参照ください。
検証結果：
- テーブルプロパティが推奨どおりに設定されている場合：1 億 7,000 万行のデータが読み取られ、クエリ時間は 0.71s です。
- l_shipmode がクラスタリングキーまたはビットマップ列プロパティとして設定されていない場合：6 億行のデータを含むテーブル全体が読み取られ、クエリ時間は 2.41s です。
  説明
  低速クエリログの read_rows パラメーターに基づいて、読み取られたデータの行数を確認できます。詳細については、「低速クエリログのクエリと分析」をご参照ください。
  実行プランを使用して、ビットマップインデックスに基づいてデータがフィルタリングされているかどうかを確認できます。実行プランに Bitmap Filter キーワードが含まれている場合、データはビットマップインデックスに基づいてフィルタリングされます。

シナリオ 5：フィールドに基づく集計クエリ

シナリオの説明
フィールドに基づいて集計クエリを実行します。この例では、TPC-H データセットの Lineitem テーブルに対して、l_suppkey フィールドに基づいて集計クエリを実行します。SQL ステートメントの例：
```
SELECT
    l_suppkey,
    sum(l_extendedprice * (1 - l_discount))
FROM
    lineitem
GROUP BY
    l_suppkey;
```
設定の推奨事項
集計フィールドを分散キーとして設定して、大量のデータがシャード間でシャッフルされないようにします。
パフォーマンス検証
Lineitem テーブルを列指向テーブルとして定義します。集計フィールド l_suppkey が分散キーとして設定されている場合と、別のフィールドが分散キーとして設定されている場合のクエリパフォーマンスを検証します。テーブル作成ステートメントの詳細については、「シナリオ 5 の DDL ステートメント」をご参照ください。
検証結果：
- 集計フィールドが分散キーとして設定されている場合：約 0.21 GB のデータがシャッフルされ、実行時間は 2.30s です。
- 別のフィールドが分散キーとして設定されている場合：約 8.16 GB のデータがシャッフルされ、実行時間は 3.68s です。
説明
低速クエリログの shuffle_bytes パラメーターに基づいて、シャッフルされたデータ量を確認できます。詳細については、「低速クエリログのクエリと分析」をご参照ください。

シナリオ 6：複数テーブルの結合クエリ

シナリオの説明

複数テーブルの結合クエリを実行します。この例では、TPC-H データセットの Lineitem テーブルと Orders テーブルの結合クエリを実行します。クエリステートメントの詳細については、「Q4」をご参照ください。SQL ステートメントの例：

SELECT
    o_orderpriority,
    count(*) AS order_count
FROM
    orders
WHERE
    o_orderdate >= date '1996-07-01'
    AND o_orderdate < date '1996-07-01' + interval '3' month
    AND EXISTS (
        SELECT
            *
        FROM
            lineitem
        WHERE
            l_orderkey=o_orderkey -- 結合クエリ
            AND l_commitdate < l_receiptdate)
GROUP BY
    o_orderpriority
ORDER BY
    o_orderpriority;

設定の推奨事項
結合操作が実行されるフィールドを分散キーとして設定して、大量のデータがシャード間でシャッフルされないようにします。
パフォーマンス検証
Lineitem テーブルと Orders テーブルを列指向テーブルとして定義します。結合操作に使用される l_orderkey フィールドと o_orderkey フィールドが分散キーとして設定されている場合と、他のフィールドが分散キーとして設定されている場合のクエリパフォーマンスを検証します。たとえば、l_linenumber フィールドが Lineitem テーブルの分散キーとして設定され、Orders テーブルには分散キーが設定されていません。テーブル作成ステートメントの詳細については、「シナリオ 6 の DDL ステートメント」をご参照ください。
検証結果：
- テーブルに推奨される分散キーが設定されている場合：約 0.45 GB のデータがシャッフルされ、実行時間は 2.19s です。
- テーブルに推奨される分散キーが設定されていない場合：約 6.31 GB のデータがシャッフルされ、実行時間は 5.55s です。
説明
低速クエリログの shuffle_bytes パラメーターに基づいて、シャッフルされたデータ量を確認できます。詳細については、「低速クエリログのクエリと分析」をご参照ください。

（オプション）テーブルが属するテーブルグループを指定する

Hologres インスタンスに 256 個を超えるコアが含まれており、インスタンスがさまざまなビジネスシナリオで使用されている場合は、複数のテーブルグループを設定し、テーブルを作成するときにテーブルが属するテーブルグループを指定することをお勧めします。詳細については、「テーブルグループを指定するためのベストプラクティス」をご参照ください。

付録：テーブル作成ステートメント

シナリオ 1 の DDL ステートメント：

-- プライマリキーを持つテーブルを作成するためのデータ定義言語（DDL）ステートメント。プライマリキーを設定せずにテーブルを作成する場合は、O_ORDERKEY フィールドに指定されている PRIMARY KEY を削除します。
DROP TABLE IF EXISTS orders;
BEGIN;
CREATE TABLE orders(
    O_ORDERKEY       BIGINT         NOT NULL PRIMARY KEY
    ,O_CUSTKEY       INT            NOT NULL
    ,O_ORDERSTATUS   TEXT           NOT NULL
    ,O_TOTALPRICE    DECIMAL(15,2)  NOT NULL
    ,O_ORDERDATE     TIMESTAMPTZ    NOT NULL
    ,O_ORDERPRIORITY TEXT           NOT NULL
    ,O_CLERK         TEXT           NOT NULL
    ,O_SHIPPRIORITY  INT            NOT NULL
    ,O_COMMENT       TEXT           NOT NULL
);
CALL SET_TABLE_PROPERTY('orders', 'orientation', 'row');
CALL SET_TABLE_PROPERTY('orders', 'clustering_key', 'o_orderkey');
CALL SET_TABLE_PROPERTY('orders', 'distribution_key', 'o_orderkey');
COMMIT;

シナリオ 2 の DDL ステートメント：

-- Lineitem という名前のテーブルを作成し、テーブルに必要なプロパティを設定します。
DROP TABLE IF EXISTS lineitem;
BEGIN;
CREATE TABLE lineitem
(
    L_ORDERKEY      BIGINT      NOT NULL,
    L_PARTKEY       INT         NOT NULL,
    L_SUPPKEY       INT         NOT NULL,
    L_LINENUMBER    INT         NOT NULL,
    L_QUANTITY      DECIMAL(15,2) NOT NULL,
    L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL,
    L_DISCOUNT      DECIMAL(15,2) NOT NULL,
    L_TAX           DECIMAL(15,2) NOT NULL,
    L_RETURNFLAG    TEXT        NOT NULL,
    L_LINESTATUS    TEXT        NOT NULL,
    L_SHIPDATE      TIMESTAMPTZ NOT NULL,
    L_COMMITDATE    TIMESTAMPTZ NOT NULL,
    L_RECEIPTDATE   TIMESTAMPTZ NOT NULL,
    L_SHIPINSTRUCT  TEXT        NOT NULL,
    L_SHIPMODE      TEXT        NOT NULL,
    L_COMMENT       TEXT        NOT NULL,
    PRIMARY KEY (L_ORDERKEY,L_LINENUMBER)
);
CALL set_table_property('lineitem', 'orientation', 'row');
-- CALL set_table_property('lineitem', 'clustering_key', 'L_ORDERKEY,L_SHIPDATE');
CALL set_table_property('lineitem', 'distribution_key', 'L_ORDERKEY');
COMMIT;

シナリオ 3 の DDL ステートメント：

-- Lineitem という名前のパーティションテーブルを作成します。パーティション化されていないテーブルを作成するために使用されるステートメントは、シナリオ 2 で使用されるステートメントと同じです。
DROP TABLE IF EXISTS lineitem;
BEGIN;
CREATE TABLE lineitem
(
    L_ORDERKEY      BIGINT      NOT NULL,
    L_PARTKEY       INT         NOT NULL,
    L_SUPPKEY       INT         NOT NULL,
    L_LINENUMBER    INT         NOT NULL,
    L_QUANTITY      DECIMAL(15,2) NOT NULL,
    L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL,
    L_DISCOUNT      DECIMAL(15,2) NOT NULL,
    L_TAX           DECIMAL(15,2) NOT NULL,
    L_RETURNFLAG    TEXT        NOT NULL,
    L_LINESTATUS    TEXT        NOT NULL,
    L_SHIPDATE      TIMESTAMPTZ NOT NULL,
    L_COMMITDATE    TIMESTAMPTZ NOT NULL,
    L_RECEIPTDATE   TIMESTAMPTZ NOT NULL,
    L_SHIPINSTRUCT  TEXT        NOT NULL,
    L_SHIPMODE      TEXT        NOT NULL,
    L_COMMENT       TEXT        NOT NULL,
    L_YEAR          TEXT        NOT NULL,
    PRIMARY KEY (L_ORDERKEY,L_LINENUMBER,L_YEAR)
)
PARTITION BY LIST (L_YEAR);
CALL set_table_property('lineitem', 'clustering_key', 'L_ORDERKEY,L_SHIPDATE');
CALL set_table_property('lineitem', 'segment_key', 'L_SHIPDATE');
CALL set_table_property('lineitem', 'distribution_key', 'L_ORDERKEY');
COMMIT;

シナリオ 4 の DDL ステートメント：

-- Lineitem という名前のテーブルを作成し、推奨されないテーブルプロパティを設定します。比較シナリオでは、クラスタリングキーとビットマップ列プロパティを推奨どおりに設定します。
DROP TABLE IF EXISTS lineitem;
BEGIN;
CREATE TABLE lineitem
(
    L_ORDERKEY      BIGINT      NOT NULL,
    L_PARTKEY       INT         NOT NULL,
    L_SUPPKEY       INT         NOT NULL,
    L_LINENUMBER    INT         NOT NULL,
    L_QUANTITY      DECIMAL(15,2) NOT NULL,
    L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL,
    L_DISCOUNT      DECIMAL(15,2) NOT NULL,
    L_TAX           DECIMAL(15,2) NOT NULL,
    L_RETURNFLAG    TEXT        NOT NULL,
    L_LINESTATUS    TEXT        NOT NULL,
    L_SHIPDATE      TIMESTAMPTZ NOT NULL,
    L_COMMITDATE    TIMESTAMPTZ NOT NULL,
    L_RECEIPTDATE   TIMESTAMPTZ NOT NULL,
    L_SHIPINSTRUCT  TEXT        NOT NULL,
    L_SHIPMODE      TEXT        NOT NULL,
    L_COMMENT       TEXT        NOT NULL,
    PRIMARY KEY (L_ORDERKEY,L_LINENUMBER)
);
CALL set_table_property('lineitem', 'segment_key', 'L_SHIPDATE');
CALL set_table_property('lineitem', 'distribution_key', 'L_ORDERKEY');
CALL set_table_property('lineitem', 'bitmap_columns', 'l_orderkey,l_partkey,l_suppkey,l_linenumber,l_returnflag,l_linestatus,l_shipinstruct,l_comment');
COMMIT;

シナリオ 5 の DDL ステートメント：

-- Lineitem という名前のテーブルを作成し、Group By 句で指定するフィールドを分散キーとして設定します。
DROP TABLE IF EXISTS lineitem;
BEGIN;
CREATE TABLE lineitem
(
    L_ORDERKEY      BIGINT      NOT NULL,
    L_PARTKEY       INT         NOT NULL,
    L_SUPPKEY       INT         NOT NULL,
    L_LINENUMBER    INT         NOT NULL,
    L_QUANTITY      DECIMAL(15,2) NOT NULL,
    L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL,
    L_DISCOUNT      DECIMAL(15,2) NOT NULL,
    L_TAX           DECIMAL(15,2) NOT NULL,
    L_RETURNFLAG    TEXT        NOT NULL,
    L_LINESTATUS    TEXT        NOT NULL,
    L_SHIPDATE      TIMESTAMPTZ NOT NULL,
    L_COMMITDATE    TIMESTAMPTZ NOT NULL,
    L_RECEIPTDATE   TIMESTAMPTZ NOT NULL,
    L_SHIPINSTRUCT  TEXT        NOT NULL,
    L_SHIPMODE      TEXT        NOT NULL,
    L_COMMENT       TEXT        NOT NULL,
    PRIMARY KEY (L_ORDERKEY,L_LINENUMBER,L_SUPPKEY)
);
CALL set_table_property('lineitem', 'segment_key', 'L_COMMITDATE');
CALL set_table_property('lineitem', 'clustering_key', 'L_ORDERKEY,L_SHIPDATE');
CALL set_table_property('lineitem', 'distribution_key', 'L_SUPPKEY');
COMMIT;

シナリオ 6 の DDL ステートメント：

DROP TABLE IF EXISTS LINEITEM;

BEGIN;
CREATE TABLE LINEITEM
(
    L_ORDERKEY      BIGINT      NOT NULL,
    L_PARTKEY       INT         NOT NULL,
    L_SUPPKEY       INT         NOT NULL,
    L_LINENUMBER    INT         NOT NULL,
    L_QUANTITY      DECIMAL(15,2) NOT NULL,
    L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL,
    L_DISCOUNT      DECIMAL(15,2) NOT NULL,
    L_TAX           DECIMAL(15,2) NOT NULL,
    L_RETURNFLAG    TEXT        NOT NULL,
    L_LINESTATUS    TEXT        NOT NULL,
    L_SHIPDATE      TIMESTAMPTZ NOT NULL,
    L_COMMITDATE    TIMESTAMPTZ NOT NULL,
    L_RECEIPTDATE   TIMESTAMPTZ NOT NULL,
    L_SHIPINSTRUCT  TEXT        NOT NULL,
    L_SHIPMODE      TEXT        NOT NULL,
    L_COMMENT       TEXT        NOT NULL,
    PRIMARY KEY (L_ORDERKEY,L_LINENUMBER)
);
CALL set_table_property('LINEITEM', 'clustering_key', 'L_SHIPDATE,L_ORDERKEY');
CALL set_table_property('LINEITEM', 'segment_key', 'L_SHIPDATE');
CALL set_table_property('LINEITEM', 'distribution_key', 'L_ORDERKEY');
CALL set_table_property('LINEITEM', 'bitmap_columns', 'L_ORDERKEY,L_PARTKEY,L_SUPPKEY,L_LINENUMBER,L_RETURNFLAG,L_LINESTATUS,L_SHIPINSTRUCT,L_SHIPMODE,L_COMMENT');
CALL set_table_property('LINEITEM', 'dictionary_encoding_columns', 'L_RETURNFLAG,L_LINESTATUS,L_SHIPINSTRUCT,L_SHIPMODE,L_COMMENT');
COMMIT;

DROP TABLE IF EXISTS ORDERS;

BEGIN;
CREATE TABLE ORDERS
(
    O_ORDERKEY      BIGINT      NOT NULL PRIMARY KEY,
    O_CUSTKEY       INT         NOT NULL,
    O_ORDERSTATUS   TEXT        NOT NULL,
    O_TOTALPRICE    DECIMAL(15,2) NOT NULL,
    O_ORDERDATE     timestamptz NOT NULL,
    O_ORDERPRIORITY TEXT        NOT NULL,
    O_CLERK         TEXT        NOT NULL,
    O_SHIPPRIORITY  INT         NOT NULL,
    O_COMMENT       TEXT        NOT NULL
);
CALL set_table_property('ORDERS', 'segment_key', 'O_ORDERDATE');
CALL set_table_property('ORDERS', 'distribution_key', 'O_ORDERKEY');
CALL set_table_property('ORDERS', 'bitmap_columns', 'O_ORDERKEY,O_CUSTKEY,O_ORDERSTATUS,O_ORDERPRIORITY,O_CLERK,O_SHIPPRIORITY,O_COMMENT');
CALL set_table_property('ORDERS', 'dictionary_encoding_columns', 'O_ORDERSTATUS,O_ORDERPRIORITY,O_CLERK,O_COMMENT');
COMMIT;

参考文献

Hologres 内部テーブルの DDL ステートメントの詳細については、以下のトピックをご参照ください。