すべてのプロダクト
Search

このプロダクト

    Hologres:CREATE DYNAMIC TABLE

    ドキュメントセンター

    Hologres:CREATE DYNAMIC TABLE

    最終更新日:Jan 05, 2026

    本トピックでは、動的テーブルの作成方法について説明します。

    注意事項

    • 動的テーブルの制限事項については、「動的テーブルのサポートと制限」をご参照ください。

    • Hologres V3.1 以降、新しい動的テーブルはデフォルトで新しい構文を使用して作成されます。V3.0 の構文を使用してテーブルを作成することはできなくなりました。V3.0 で作成された既存の動的テーブルに対しては、ALTER 操作のみを実行できます。パーティション化されていないテーブルの場合、「構文変換コマンド」を使用して V3.0 の構文を新しい V3.1 の構文に変換できます。パーティションテーブルの場合は、手動で再作成する必要があります。

    • Hologres V3.1 以降、増分更新される動的テーブルは再作成する必要があります。「構文変換コマンド」を使用して再構築できます。

    • Hologres V3.1 以降、エンジンは動的テーブルの更新実行プロセスを自動的に最適化し、更新プロセスをより安定させます。そのため、更新操作に関連する負のクエリ ID が表示されるのは正常です。

    構文

    V3.1 以降 (新しい構文)

    説明

    Hologres V3.1 以降、テーブルの作成には新しい構文のみを使用できます。

    テーブル作成構文

    Hologres V3.1 以降では、次の構文を使用して動的テーブルを作成できます。

    CREATE DYNAMIC TABLE [ IF NOT EXISTS ] [<schema_name>.]<table_name>
[ (<col_name> [, ...] ) ]
[LOGICAL PARTITION BY LIST(<partition_key>)]
WITH (
  -- Dynamic table properties
  freshness = '<num> {minutes | hours}', -- Required
  [auto_refresh_enable = {true | false},] -- Optional
  [auto_refresh_mode = {'full' | 'incremental' | 'auto'},] -- Optional
  
  [base_table_cdc_format = {'stream' | 'binlog'},] -- Optional

  [auto_refresh_partition_active_time = '<num> {minutes | hours | days}',] -- Optional
  [partition_key_time_format = {'YYYYMMDDHH24' | 'YYYY-MM-DD-HH24' | 'YYYY-MM-DD_HH24' | 'YYYYMMDD' | 'YYYY-MM-DD' | 'YYYYMM' | 'YYYY-MM' | 'YYYY'},] -- Optional
  
  [computing_resource = {'local' | 'serverless' | '<warehouse_name>'},] -- Optional. warehouse_name is supported only in Hologres V4.0.7 and later.
  [refresh_guc_hg_experimental_serverless_computing_required_cores=xxx,]-- Optional. Compute resource specification.
  
  [refresh_guc_<guc_name> = '<guc_value>',] -- Optional

  -- General properties
  [orientation = {'column' | 'row' | 'row,column'},]
  [table_group = '<tableGroupName>',]
  [distribution_key = '<columnName>[,...]]',]
  [clustering_key = '<columnName>[:asc] [,...]',]
  [event_time_column = '<columnName> [,...]',]
  [bitmap_columns = '<columnName> [,...]',]
  [dictionary_encoding_columns = '<columnName> [,...]',]
  [time_to_live_in_seconds = '<non_negative_literal>',]
  [storage_mode = {'hot' | 'cold'},]
)
AS
<query>; -- Definition of the query

    パラメーターの説明

    リフレッシュモードとリソース

    パラメーター

    説明

    必須

    デフォルト値

    freshness

    データ鮮度。単位は分または時間です。最小値は 1 分です。エンジンは、最後の更新時刻と設定された鮮度値に基づいて、次の更新を自動的にスケジュールします。固定の更新間隔を設定するのに比べて、鮮度はより自動化され、最適なデータ鮮度を提供します。

    はい

    なし

    auto_refresh_mode

    更新モード。有効値：

    • auto：自動モード。クエリが増分更新をサポートしている場合、増分で実行されます。そうでない場合は、完全更新にフォールバックします。

    • incremental：増分更新。増分データのみを更新します。詳細については、「増分更新」をご参照ください。

    • full：完全更新。毎回すべてのテーブルデータを更新します。詳細については、「完全更新」をご参照ください。

    いいえ

    auto

    auto_refresh_enable

    自動更新を有効または無効にします。有効値：

    • true：自動更新を有効にします。

    • false：自動更新を無効にします。無効にすると、以降のすべての更新が停止します。

    いいえ

    true

    base_table_cdc_format

    増分更新中にベーステーブルの変更を消費する方法。

    • stream (デフォルト)：ファイルレベルでデータ変更レコードを読み取り、増分データを計算します。binlog と比較して、この方法には追加のストレージオーバーヘッドがなく、パフォーマンスが向上します。詳細については、「動的テーブル」をご参照ください。

    • binlog：binlog を使用してベーステーブルのデータを消費します。このパラメーターを設定した後、ベーステーブルの binlog を手動で有効にします。詳細については、「Hologres Binlog のサブスクライブ」をご参照ください。

      begin;
call set_table_property('<table_name>', 'binlog.level', 'replica');
call set_table_property('<table_name>', 'binlog.ttl', '2592000');
commit;
    説明

    • V3.1 以降、すべてのテーブルはデフォルトで stream を使用してベーステーブルの変更を消費します。以前に binlog を有効にしていた場合は、不要なストレージコストを避けるために速やかに無効にしてください。

    • ベーステーブルが行指向の場合、binlog のみがサポートされます。stream はサポートされません。

    • このパラメーターはテーブル作成後に変更できません。変更するには、テーブルを再作成してください。

    いいえ

    stream

    computing_resource

    詳細については、「動的テーブル更新のための計算リソースの設定」の「パラメーターの説明」をご参照ください。

    いいえ

    serverless

    refresh_guc_<guc_name>

    更新用の GUC パラメーターを設定できます。サポートされている GUC については、「GUC パラメーター」をご参照ください。

    いいえ

    なし

    パーティションプロパティ

    論理パーティションパラメーター

    パラメーター名

    説明

    必須

    デフォルト値

    LOGICAL PARTITION BY LIST(<partition_key>)

    論理パーティション化された動的テーブルを作成します。この機能を使用するには、auto_refresh_partition_active_time および partition_key_time_format パラメーターも設定する必要があります。

    いいえ

    なし

    auto_refresh_partition_active_time

    パーティションの更新範囲。単位には分、時間、日が含まれます。システムは、現在時刻から設定値に基づいて遡り、範囲内のパーティションデータを自動的に更新します。

    アクティブなパーティション： 現在時刻 - パーティション開始時刻 (パーティション名から導出) < auto_refresh_partition_active_time。

    説明

    • auto_refresh_partition_active_time の単位は、1 つのパーティション単位よりも大きくする必要があります。たとえば、日次パーティションの場合、auto_refresh_partition_active_time は 24 時間より大きくする必要があります。

    • このパラメーターは変更できます。変更は将来のパーティションにのみ適用されます。

    はい

    パーティション時間単位 + 1 時間、

    これにより、ベーステーブルに 1 時間のデータ遅延が許容されます。たとえば、日次パーティションの場合、デフォルトは 25 時間 (1 日 + 1 時間) です。

    partition_key_time_format

    パーティションフォーマット。動的テーブルが論理パーティションテーブルである場合、システムは指定されたフォーマットに基づいてパーティションを生成します。サポートされているパーティションキーの型と対応するフォーマット：

    • TEXT/VARCHAR パーティションキー：

      YYYYMMDDHH24, YYYY-MM-DD-HH24, YYYY-MM-DD_HH24, YYYYMMDD, YYYY-MM-DD, YYYYMM, YYYY-MM, YYYY。

    • INT パーティションキー：

      YYYYMMDDHH24, YYYYMMDD, YYYYMM, YYYY。

    • DATE パーティションキー：

      YYYY-MM-DD

    はい

    なし

    物理パーティションパラメーター

    パラメーター

    説明

    必須

    デフォルト値

    PARTITION BY LIST(<partition_key>)

    標準のパーティション化された動的テーブルを作成します。

    論理パーティション化された動的テーブルと比較して、標準のパーティション化された動的テーブルには動的パーティショニング機能がなく、使用上の制限があります。論理パーティションの使用を推奨します。違いについては、「CREATE LOGICAL PARTITION TABLE」をご参照ください。

    重要

    Hologres V3.1 以降、新しい構文では物理パーティション化された動的テーブルの作成はサポートされていません。

    いいえ

    なし

    テーブルプロパティパラメーター

    パラメーター

    説明

    必須

    デフォルト値

    full

    incremental

    col_name

    動的テーブルの列名。

    列名を明示的に指定できますが、列の属性やデータ型は指定できません。エンジンが自動的に推測します。

    説明

    列の属性やデータ型を指定すると、エンジンの推測が不正確になります。

    いいえ

    クエリ列名

    クエリ列名

    orientation

    動的テーブルのストレージモードを指定します。column は列ストアを示します。

    いいえ

    column

    column

    table_group

    動的テーブルのテーブルグループを指定します。デフォルトでは、現在のデータベースのデフォルトテーブルグループになります。詳細については、「テーブルグループとシャード数のユーザーガイド」をご参照ください。

    いいえ

    デフォルトのテーブルグループ名

    デフォルトのテーブルグループ名

    distribution_key

    動的テーブルの Distribution Key を指定します。詳細については、「Distribution Key」をご参照ください。

    いいえ

    なし

    なし

    clustering_key

    動的テーブルの Clustering Key を指定します。詳細については、「Clustering Key」をご参照ください。

    いいえ

    設定可能で、デフォルトの推測値があります。

    設定可能で、デフォルトの推測値があります。

    event_time_column

    動的テーブルの event_time_column を指定します。詳細については、「Event Time Column (Segment Key)」をご参照ください。

    いいえ

    なし

    なし

    bitmap_columns

    動的テーブルの bitmap_columns を指定します。詳細については、「ビットマップインデックス」をご参照ください。

    いいえ

    TEXT 型の列

    TEXT 型の列

    dictionary_encoding_columns

    動的テーブルの dictionary_encoding_columns を指定します。詳細については、「辞書エンコーディング」をご参照ください。

    いいえ

    TEXT 型の列

    TEXT 型の列

    time_to_live_in_seconds

    動的テーブルのデータライフサイクルを指定します。

    いいえ

    永続的

    永続的

    storage_mode

    動的テーブルのストレージモード。有効値：

    • hot：ホットストレージ。

    • cold：コールドストレージ。

    説明

    ストレージモードの詳細については、「データ階層化ストレージ」をご参照ください。

    いいえ

    hot

    hot

    binlog_level

    動的テーブルで binlog を有効にするかどうかを指定します。binlog の使用法については、「Hologres Binlog のサブスクライブ」をご参照ください。

    説明

    • このパラメーターは V3.1.18 以降でサポートされています。

    • 完全更新の動的テーブルで binlog を有効にすることは推奨しません。

    いいえ

    none

    none

    binlog_ttl

    動的テーブルで binlog を有効にした後の binlog のライフサイクル。

    いいえ

    2592000

    2592000

    クエリ

    動的テーブルのデータを生成するクエリを指定します。サポートされるクエリのタイプとベーステーブルのタイプは、更新モードによって異なります。詳細については、「動的テーブルのサポートと制限」をご参照ください。

    V3.0

    テーブル作成構文

    Hologres V3.0 では、次の構文を使用して動的テーブルを作成できます。

    CREATE DYNAMIC TABLE [IF NOT EXISTS] <schema.tablename>(
[col_name],
[col_name]
  ) [PARTITION BY LIST (col_name)]
WITH (
    [refresh_mode='[full|incremental]',]
    [auto_refresh_enable='[true|false',]

  -- Parameters for incremental refresh:
    [incremental_auto_refresh_schd_start_time='[immediate|<timestamptz>]',]
    [incremental_auto_refresh_interval='[<num> {minute|minutes|hour|hours]',]  
    [incremental_guc_hg_computing_resource='[ local | serverless]',]
    [incremental_guc_hg_experimental_serverless_computing_required_cores='<num>',]

   -- Parameters for full refresh:
    [full_auto_refresh_schd_start_time='[immediate|<timestamptz>]',]
    [full_auto_refresh_interval='[<num> {minute|minutes|hour|hours]',] 
    [full_guc_hg_computing_resource='[ local | serverless]',]-- hg_full_refresh_computing_resource defaults to serverless and can be set at the DB level. Users can omit this setting.
    [full_guc_hg_experimental_serverless_computing_required_cores='<num>',]
    
   -- Shared parameters. GUC settings allowed:
   [refresh_guc_<guc>='xxx]',] 
   
  -- General Dynamic Table properties:
    [orientation = '[column]',]
    [table_group = '[tableGroupName]',]
    [distribution_key = 'columnName[,...]]',]
    [clustering_key = '[columnName{:asc]} [,...]]',]
    [event_time_column = '[columnName [,...]]',]
    [bitmap_columns = '[columnName [,...]]',]
    [dictionary_encoding_columns = '[columnName [,...]]',]
    [time_to_live_in_seconds = '<non_negative_literal>',]
    [storage_mode = '[hot | cold]']
    ) 
AS
<query> -- Definition of the query

    パラメーターの説明

    リフレッシュモードとリソース

    パラメーターカテゴリ

    パラメーター名

    説明

    必須

    デフォルト値

    共有更新パラメーター

    refresh_mode

    データ更新モードを指定します。完全更新モードと増分更新モードをサポートします。

    設定しない場合、更新は行われません。

    いいえ

    なし

    auto_refresh_enable

    自動更新を有効または無効にします。有効値：

    • true：自動更新を有効にします。

    • false：自動更新を無効にします。

    いいえ

    false

    refresh_guc_<guc>

    更新用の GUC パラメーターを設定できます。サポートされている GUC については、「GUC パラメーター」をご参照ください。

    説明

    たとえば、timezone GUC パラメーターを設定するには、refresh_guc_timezone = 'GMT-8:00' を使用します。

    いいえ

    なし

    増分更新

    incremental_auto_refresh_schd_start_time

    増分更新の開始時刻。有効値：

    • immediate：デフォルト。テーブル作成後すぐに増分更新を開始します。

    • <timestamptz>：カスタム開始時刻。たとえば、2024-08-24 1:00 はその時刻に更新タスクを開始します。

    いいえ

    immediate

    incremental_auto_refresh_interval

    増分更新の時間間隔。単位：minute, minutes, hour, hours。

    • 有効範囲：[1 分, 48 時間]。

    • 設定しない場合、更新は開始時刻に一度だけ実行されます。

    いいえ

    なし

    incremental_guc_hg_computing_resource

    増分更新の計算リソースを指定します。有効値：

    説明

    DB レベルで増分更新の計算リソースを設定するには、ALTER DATABASE xxx SET incremental_guc_hg_computing_resource=xx を使用します。

    いいえ

    local

    incremental_guc_hg_experimental_serverless_computing_required_cores

    更新にサーバーレスリソースを使用する場合、必要な計算リソースを設定します。

    説明

    インスタンスの仕様によってサーバーレスリソースの制限が異なります。詳細については、「サーバーレスコンピューティングユーザーガイド」をご参照ください。

    いいえ

    なし

    完全更新

    full_auto_refresh_schd_start_time

    完全更新の開始時刻。有効値：

    • immediate：デフォルト。テーブル作成後すぐに完全更新を開始します。

    • <timestamptz>：カスタム開始時刻。たとえば、2024-08-24 1:00 はその時刻に更新タスクを開始します。

    いいえ

    immediate

    full_auto_refresh_interval

    完全更新の時間間隔。単位：minute, minutes, hour, hours。

    • 有効範囲：[1 分, 48 時間]。

    • 設定しない場合、更新は開始時刻に一度だけ実行されます。

    いいえ

    なし

    full_guc_hg_computing_resource

    完全更新の計算リソースを指定します。有効値：

    説明

    DB レベルで完全更新の計算リソースを設定するには、ALTER DATABASE xxx SET full_guc_hg_computing_resource=xx を使用します。

    いいえ

    local

    full_guc_hg_experimental_serverless_computing_required_cores

    更新にサーバーレスを使用する場合、必要な計算リソースを設定します。

    説明

    インスタンスの仕様によってサーバーレスリソースの制限が異なります。詳細については、「サーバーレスコンピューティングユーザーガイド」をご参照ください。

    いいえ

    なし

    テーブルプロパティパラメーター

    パラメーター

    説明

    必須

    デフォルト値

    full

    incremental

    col_name

    動的テーブルの列名。

    列名を明示的に指定できますが、列の属性やデータ型は指定できません。エンジンが自動的に推測します。

    説明

    列の属性やデータ型を指定すると、エンジンの推測が不正確になります。

    いいえ

    クエリ列名

    クエリ列名

    orientation

    動的テーブルのストレージモードを指定します。column は列ストアを示します。

    いいえ

    column

    column

    table_group

    動的テーブルのテーブルグループを指定します。デフォルトでは、現在のデータベースのデフォルトテーブルグループになります。詳細については、「テーブルグループとシャード数のユーザーガイド」をご参照ください。

    いいえ

    デフォルトのテーブルグループ名

    デフォルトのテーブルグループ名

    distribution_key

    動的テーブルの Distribution Key を指定します。詳細については、「Distribution Key」をご参照ください。

    いいえ

    なし

    なし

    clustering_key

    動的テーブルの Clustering Key を指定します。詳細については、「Clustering Key」をご参照ください。

    いいえ

    設定可能で、デフォルトの推測値があります。

    設定可能で、デフォルトの推測値があります。

    event_time_column

    動的テーブルの event_time_column を指定します。詳細については、「Event Time Column (Segment Key)」をご参照ください。

    いいえ

    なし

    なし

    bitmap_columns

    動的テーブルの bitmap_columns を指定します。詳細については、「ビットマップインデックス」をご参照ください。

    いいえ

    TEXT 型の列

    TEXT 型の列

    dictionary_encoding_columns

    動的テーブルの dictionary_encoding_columns を指定します。詳細については、「辞書エンコーディング」をご参照ください。

    いいえ

    TEXT 型の列

    TEXT 型の列

    time_to_live_in_seconds

    動的テーブルのデータライフサイクルを指定します。

    いいえ

    永続的

    永続的

    storage_mode

    動的テーブルのストレージモード。有効値：

    • hot：ホットストレージ。

    • cold：コールドストレージ。

    説明

    ストレージモードの詳細については、「データ階層化ストレージ」をご参照ください。

    いいえ

    hot

    hot

    PARTITION BY LIST

    テーブルがパーティション化されているかどうかを指定します。パーティション化された動的テーブルの作成をサポートします。使用方法は標準のパーティションテーブルと同じです。異なる子パーティションは、異なるビジネスのタイムライン要件を満たすために、異なる更新モードを使用できます。

    いいえ

    パーティション化されていないテーブル

    パーティション化されていないテーブル

    クエリ

    動的テーブルのデータを生成するクエリを指定します。サポートされるクエリのタイプとベーステーブルのタイプは、更新モードによって異なります。詳細については、「動的テーブルのサポートと制限」をご参照ください。

    増分更新

    増分更新は、ベーステーブルの変更を自動的に検出し、クエリデータを動的テーブルに増分的に書き込みます。完全更新と比較して、増分更新は処理するデータが少なく、より高いタイムラインを提供します。分単位のデータを必要とするほぼリアルタイムのクエリには、増分更新を使用することを推奨します。増分更新される動的テーブルを使用する際は、次の点に注意してください。

    • ベーステーブルの制限事項：

      • Hologres V3.1 は、デフォルトで stream モードを使用して増分データを消費します。V3.0 でベーステーブルに binlog を有効にしていた場合は、ストレージコストの増加を防ぐために無効にする必要があります。

      • V3.0 では、ベーステーブルで binlog を有効にする必要があります。JOIN 操作のディメンションテーブルには binlog は不要です。binlog を有効にすると、ストレージオーバーヘッドが増加します。binlog のストレージ使用量を確認するには、「テーブルストレージの詳細」をご参照ください。

    • 増分更新を有効にすると、システムはバックグラウンドで状態表を作成し、中間集約結果を記録します。状態表の技術的な詳細については、「動的テーブル」をご参照ください。状態表は中間集約データを保存し、ストレージリソースを消費します。ストレージ使用量を確認するには、「動的テーブルのスキーマとリネージの表示」をご参照ください。

    • 増分更新でサポートされているクエリとオペレーターの詳細については、「動的テーブルのサポートと制限」をご参照ください。

    複数テーブルの JOIN (デュアルストリーム JOIN)

    デュアルストリーム JOIN は、複数テーブル JOIN の一種です。オンライン分析処理 (OLAP) クエリと同じセマンティクスを使用し、HASH JOIN を使用して実装されます。INNER JOIN、LEFT OUTER JOIN、RIGHT OUTER JOIN、FULL OUTER JOIN の 4 種類の JOIN 操作をサポートします。

    V3.1

    説明

    Hologres V3.1 以降、デュアルストリーム JOIN の Grand Unified Configuration (GUC) パラメーターはデフォルトで有効になっています。手動で設定する必要はありません。

    サンプル SQL：

    CREATE TABLE users (
  user_id INT,
  user_name TEXT,
  PRIMARY KEY (user_id)
);
INSERT INTO users VALUES(1, 'hologres');

CREATE TABLE orders (
  order_id INT,
  user_id INT,
  PRIMARY KEY (order_id)
);
INSERT INTO orders VALUES(1, 1);

CREATE DYNAMIC TABLE dt WITH (
  auto_refresh_mode = 'incremental',
  freshness='10 minutes'
) 
AS 
SELECT order_id, orders.user_id, user_name 
FROM orders LEFT JOIN users ON orders.user_id = users.user_id;

-- After refresh, one joined row appears
REFRESH TABLE dt;
SELECT * FROM dt;
 order_id | user_id | user_name 
----------+---------+-----------
        1 |       1 | hologres
(1 row)


UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);

-- After refresh, two joined rows appear. Dimension table updates apply to all data, correcting previously joined data
REFRESH TABLE dt;
SELECT * FROM dt;

    結果：

     order_id | user_id |   user_name   
----------+---------+---------------
        1 |       1 | dynamic table
        4 |       1 | dynamic table
(2 rows)

    V3.0

    Hologres V3.0.26 以降のバージョンは、複数テーブル JOIN (デュアルストリーム JOIN) をサポートします。まず、インスタンスをこれらのバージョンのいずれかにアップグレードする必要があります。次に、以下の GUC パラメーターを実行してデュアルストリーム JOIN を有効にします。

    -- Enable at session level
SET hg_experimental_incremental_dynamic_table_enable_hash_join TO ON;

-- Enable at DB level (takes effect for new connections)
ALTER database <db_name> SET hg_experimental_incremental_dynamic_table_enable_hash_join TO ON;

    サンプル SQL：

    CREATE TABLE users (
  user_id INT,
  user_name TEXT,
  PRIMARY KEY (user_id)
) WITH (binlog_level = 'replica');
INSERT INTO users VALUES(1, 'hologres');

CREATE TABLE orders (
  order_id INT,
  user_id INT,
  PRIMARY KEY (order_id)
)  WITH (binlog_level = 'replica');
INSERT INTO orders VALUES(1, 1);

CREATE DYNAMIC TABLE dt WITH (refresh_mode = 'incremental') 
AS 
SELECT order_id, orders.user_id, user_name 
FROM orders LEFT JOIN users ON orders.user_id = users.user_id;

-- After refresh, one joined row appears
REFRESH TABLE dt;
SELECT * FROM dt;
 order_id | user_id | user_name 
----------+---------+-----------
        1 |       1 | hologres
(1 row)


UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);

-- After refresh, two joined rows appear. Dimension table updates apply to all data, correcting previously joined data
REFRESH TABLE dt;
SELECT * FROM dt;

    結果：

     order_id | user_id |   user_name   
----------+---------+---------------
        1 |       1 | dynamic table
        4 |       1 | dynamic table
(2 rows)

    ディメンションテーブル JOIN

    次のセクションでは、ディメンションテーブル JOIN のセマンティクスについて説明します。各データレコードは、処理時にディメンションテーブルの最新バージョンとのみ結合されます。JOIN 操作が実行された後にディメンションテーブルのデータが挿入、更新、または削除操作によって変更された場合、以前に結合されたデータは更新されません。次のサンプル SQL はその例です。

    説明

    ディメンションテーブル JOIN は、テーブルのデータ量ではなく、SQL セマンティクスにのみ依存します。

    バージョン 3.1

    CREATE TABLE users (
  user_id INT,
  user_name TEXT,
  PRIMARY KEY (user_id)
);
INSERT INTO users VALUES(1, 'hologres');

CREATE TABLE orders (
  order_id INT,
  user_id INT,
  PRIMARY KEY (order_id)
)  WITH (binlog_level = 'replica');

INSERT INTO orders VALUES(1, 1);
CREATE DYNAMIC TABLE dt_join_2 WITH (
    auto_refresh_mode = 'incremental',
    freshness='10 minutes') 
AS 
SELECT order_id, orders.user_id, user_name 
-- FOR SYSTEM_TIME AS OF PROCTIME() marks users as a dimension table
FROM orders LEFT JOIN users FOR SYSTEM_TIME AS OF PROCTIME()
ON orders.user_id = users.user_id;

-- After refresh, one joined row appears
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;
 order_id | user_id | user_name 
----------+---------+-----------
        1 |       1 | hologres
(1 row)


UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);

-- After refresh, two joined rows appear. Dimension table updates apply only to new data, not correcting previously joined data
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;

    結果：

     order_id | user_id |   user_name   
----------+---------+---------------
        1 |       1 | hologres
        4 |       1 | dynamic table
(2 rows)

    V3.0

    CREATE TABLE users (
  user_id INT,
  user_name TEXT,
  PRIMARY KEY (user_id)
);
INSERT INTO users VALUES(1, 'hologres');

CREATE TABLE orders (
  order_id INT,
  user_id INT,
  PRIMARY KEY (order_id)
)  WITH (binlog_level = 'replica');
INSERT INTO orders VALUES(1, 1);

CREATE DYNAMIC TABLE dt_join_2 WITH (refresh_mode = 'incremental') 
AS 
SELECT order_id, orders.user_id, user_name 
-- FOR SYSTEM_TIME AS OF PROCTIME() marks users as a dimension table
FROM orders LEFT JOIN users FOR SYSTEM_TIME AS OF PROCTIME()
ON orders.user_id = users.user_id;

-- After refresh, one joined row appears
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;

order_id | user_id | user_name 
----------+---------+-----------
        1 |       1 | hologres
(1 row)
 
UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);

-- After refresh, two joined rows appear. Dimension table updates apply only to new data, not correcting previously joined data
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;

    結果：

     order_id | user_id |   user_name   
----------+---------+---------------
        1 |       1 | hologres
        4 |       1 | dynamic table
(2 rows)

    レイクテーブル (Paimon) の増分消費

    • 増分更新は、レイクハウス統合のために Paimon レイクテーブルの消費をサポートします。

    • 外部動的テーブルを使用して、レイクハウスデータの増分読み取りおよび書き込み操作、およびレイク (Paimon) への自動増分書き戻しを行うことができます。この機能により、レイクデータの高速なデータ処理とクエリの高速化、および自動書き戻しが可能になります。これにより、レイクデータの処理が簡素化され、コストが削減されます。詳細については、「外部動的テーブルの概要」をご参照ください。

    ハイブリッド完全・増分更新

    増分動的テーブルは、ハイブリッド完全・増分消費もサポートします。このプロセスは、まずクエリに一致するすべてのベーステーブルデータを消費し、次に新しいベーステーブルデータを消費します。

    V3.1

    V3.1 では、ハイブリッド完全・増分更新がデフォルトで有効になっています。次のコードは例です。

    -- Prepare base table and enable binlog, then insert data
CREATE TABLE base_sales(
  day TEXT NOT NULL,
  hour INT,
  user_id BIGINT,
  ts TIMESTAMPTZ,
  amount FLOAT,
  pk text NOT NULL PRIMARY KEY
);

-- Insert data into base table
INSERT INTO base_sales values ('2024-08-29',1,222222,'2024-08-29 16:41:19.141528+08',5,'ddd');


-- Insert incremental data into base table
INSERT INTO base_sales VALUES ('2024-08-29',2,3333,'2024-08-29 17:44:19.141528+08',100,'aaaaa');


-- Create incrementally refreshed Dynamic Table with hybrid full-incremental consumption enabled
CREATE DYNAMIC TABLE sales_incremental
  WITH (
    auto_refresh_mode='incremental',
    freshness='10 minutes'
  ) 
AS 
  SELECT day, hour, SUM(amount), COUNT(1) 
    FROM base_sales 
  GROUP BY day, hour;

    データ整合性を比較します。

    • ベーステーブルのクエリ

      SELECT day, hour, SUM(amount), COUNT(1) 
    FROM base_sales 
  GROUP BY day, hour;

      結果：

      day	    hour	sum	count
2024-08-29	2	100	1
2024-08-29	1	5	1

    • 動的テーブルのクエリ

      SELECT * FROM sales_incremental;

      結果：

      day	    hour	sum	count
2024-08-29	1	5	1
2024-08-29	2	100	1

    バージョン 3.0

    V3.0 では、ハイブリッド完全・増分更新のために GUC パラメーターを有効にする必要があります。次のコードは例です。

    -- Prepare base table and enable binlog, then insert data
CREATE TABLE base_sales(
  day TEXT NOT NULL,
  hour INT,
  user_id BIGINT,
  ts TIMESTAMPTZ,
  amount FLOAT,
  pk text NOT NULL PRIMARY KEY
);

-- Insert data into base table
INSERT INTO base_sales values ('2024-08-29',1,222222,'2024-08-29 16:41:19.141528+08',5,'ddd');

-- Enable binlog for base table
ALTER TABLE base_sales SET (binlog_level = replica);

-- Insert incremental data into base table
INSERT INTO base_sales VALUES ('2024-08-29',2,3333,'2024-08-29 17:44:19.141528+08',100,'aaaaa');


-- Create incrementally refreshed Dynamic Table with hybrid full-incremental consumption enabled
CREATE DYNAMIC TABLE sales_incremental
  WITH (
    refresh_mode='incremental',
    incremental_auto_refresh_schd_start_time = 'immediate',
    incremental_auto_refresh_interval = '3 minutes',
    incremental_guc_hg_experimental_enable_hybrid_incremental_mode= 'true'
  ) 
AS 
  SELECT day, hour, SUM(amount), COUNT(1) 
    FROM base_sales 
  GROUP BY day, hour;

    データ整合性を比較します。

    • ベーステーブルのクエリ

      SELECT day, hour, SUM(amount), COUNT(1) 
    FROM base_sales 
  GROUP BY day, hour;

      結果：

      day	    hour	sum	count
2024-08-29	2	100	1
2024-08-29	1	5	1

    • 動的テーブルのクエリ

      SELECT * FROM sales_incremental;

      結果：

      day	    hour	sum	count
2024-08-29	1	5	1
2024-08-29	2	100	1

    完全更新

    完全更新は、すべてのクエリデータを動的テーブルに書き込みます。増分更新と比較して、完全更新には次の利点があります。

    • より多くの種類のベーステーブルをサポートします。

    • より多様なクエリタイプとオペレーターをサポートします。

    完全更新は、より多くのデータを処理し、より多くのリソースを消費します。定期的なレポートの表示や、スケジュールされたデータバックフィルなどのシナリオに推奨されます。

    説明

    詳細については、「完全更新」をご参照ください。

    使用例

    V3.1

    例 1：増分更新される動的テーブルの作成

    次の手順を実行する前に、tpch_10g パブリックデータセットを Hologres にインポートしてください。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    説明

    増分動的テーブルを作成する前に、ベーステーブルで binlog を有効にする必要があります。ディメンションテーブルには binlog は不要です。

    -- Create a single-table incrementally refreshed Dynamic Table with refresh starting immediately and running every 3 minutes
CREATE DYNAMIC TABLE public.tpch_q1_incremental 
WITH (
auto_refresh_mode='incremental',
freshness='3 minutes'
) AS SELECT
        l_returnflag,
        l_linestatus,
        COUNT(*) AS count_order
FROM
        hologres_dataset_tpch_10g.lineitem
WHERE
        l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
        l_returnflag,
        l_linestatus;

    例 2：複数テーブル JOIN の増分更新される動的テーブルの作成

    次の手順を実行する前に、tpch_10g パブリックデータセットを Hologres にインポートしてください。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    説明

    増分動的テーブルを作成する前に、ベーステーブルで binlog を有効にする必要があります。ディメンションテーブルには binlog は不要です。

    -- Create a multi-table JOIN incrementally refreshed Dynamic Table
CREATE DYNAMIC TABLE dt_join
  WITH (
    auto_refresh_mode='incremental',
    freshness='30 minutes'
  ) 
AS 
SELECT
        l_shipmode,
        SUM(CASE
                WHEN o_orderpriority = '1-URGENT'
                        OR o_orderpriority = '2-HIGH'
                        THEN 1
                ELSE 0
        END) AS high_line_count,
        SUM(CASE
                WHEN o_orderpriority <> '1-URGENT'
                        AND o_orderpriority <> '2-HIGH'
                        THEN 1
                ELSE 0
        END) AS low_line_count
FROM
        hologres_dataset_tpch_10g.orders,
        hologres_dataset_tpch_10g.lineitem
WHERE
        o_orderkey = l_orderkey
        AND l_shipmode IN ('FOB', 'AIR')
        AND l_commitdate < l_receiptdate
        AND l_shipdate < l_commitdate
        AND l_receiptdate >= DATE '1997-01-01'
        AND l_receiptdate < DATE '1997-01-01' + INTERVAL '1' YEAR
GROUP BY
        l_shipmode;

    例 3：自動更新される動的テーブルの作成

    動的テーブルを自動更新に設定できます。エンジンは自動的に更新モードを選択します。増分更新を優先し、増分更新がサポートされていない場合は完全更新にフォールバックします。

    次の手順を実行する前に、tpch_10g パブリックデータセットを Hologres にインポートしてください。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    -- Create an auto-refresh Dynamic Table. The engine automatically selects the refresh mode (incremental in this case)
CREATE DYNAMIC TABLE thch_q6_auto
  WITH (
    auto_refresh_mode='auto',
    freshness='1 hours'
       ) 
AS
SELECT
        SUM(l_extendedprice * l_discount) AS revenue
FROM
        hologres_dataset_tpch_100g.lineitem
WHERE
        l_shipdate >= DATE '1996-01-01'
        AND l_shipdate < DATE '1996-01-01' + INTERVAL '1' YEAR
        AND l_discount BETWEEN 0.02 - 0.01 AND 0.02 + 0.01
        AND l_quantity < 24;

    例 4：論理パーティション化された動的テーブルの作成

    リアルタイムのトランザクションダッシュボードなどのシナリオでは、現在のデータのほぼリアルタイムのビューと、既存データを修正する機能が必要になる場合があります。これは、リアルタイムとオフラインのハイブリッド分析シナリオです。詳細については、「ビジネスとデータの理解」をご参照ください。この目的のために、論理パーティション化された動的テーブルを使用できます。

    • ベーステーブルは日次でパーティション化されます。最新のパーティションは Flink からリアルタイムまたはほぼリアルタイムで書き込みを受け取ります。既存のパーティションは MaxCompute からデータを受け取ります。

    • 動的テーブルは論理パーティションを使用します。最新の 2 つのパーティションはアクティブで、ほぼリアルタイムの分析のために増分更新を使用します。

    • 既存のパーティションは非アクティブで、完全更新を使用します。既存のソースデータが修正またはバックフィルされた場合、既存のパーティションに対して完全更新を使用できます。

    この例では、GitHub パブリックデータセットを使用します。

    1. ベーステーブルを準備します。

      最新のデータは Flink によってリアルタイムで書き込まれます。詳細については、「GitHub パブリックイベントデータセットを使用した統合オフラインおよびリアルタイムの実践」をご参照ください。

      DROP TABLE IF EXISTS gh_realtime_data;

BEGIN;
CREATE TABLE gh_realtime_data (
    id BIGINT,
    actor_id BIGINT,
    actor_login TEXT,
    repo_id BIGINT,
    repo_name TEXT,
    org_id BIGINT,
    org_login TEXT,
    type TEXT,
    created_at timestamp with time zone NOT NULL,
    action TEXT,
    iss_or_pr_id BIGINT,
    number BIGINT,
    comment_id BIGINT,
    commit_id TEXT,
    member_id BIGINT,
    rev_or_push_or_rel_id BIGINT,
    ref TEXT,
    ref_type TEXT,
    state TEXT,
    author_association TEXT,
    language TEXT,
    merged BOOLEAN,
    merged_at TIMESTAMP WITH TIME ZONE,
    additions BIGINT,
    deletions BIGINT,
    changed_files BIGINT,
    push_size BIGINT,
    push_distinct_size BIGINT,
    hr TEXT,
    month TEXT,
    year TEXT,
    ds TEXT,
    PRIMARY KEY (id,ds)
)
PARTITION BY LIST (ds);
CALL set_table_property('public.gh_realtime_data', 'distribution_key', 'id');
CALL set_table_property('public.gh_realtime_data', 'event_time_column', 'created_at');
CALL set_table_property('public.gh_realtime_data', 'clustering_key', 'created_at');

COMMENT ON COLUMN public.gh_realtime_data.id IS 'Event ID';
COMMENT ON COLUMN public.gh_realtime_data.actor_id IS 'Actor ID';
COMMENT ON COLUMN public.gh_realtime_data.actor_login IS 'Actor login name';
COMMENT ON COLUMN public.gh_realtime_data.repo_id IS 'Repo ID';
COMMENT ON COLUMN public.gh_realtime_data.repo_name IS 'Repo name';
COMMENT ON COLUMN public.gh_realtime_data.org_id IS 'Organization ID';
COMMENT ON COLUMN public.gh_realtime_data.org_login IS 'Organization name';
COMMENT ON COLUMN public.gh_realtime_data.type IS 'Event type';
COMMENT ON COLUMN public.gh_realtime_data.created_at IS 'Event occurrence time';
COMMENT ON COLUMN public.gh_realtime_data.action IS 'Event behavior';
COMMENT ON COLUMN public.gh_realtime_data.iss_or_pr_id IS 'Issue/pull request ID';
COMMENT ON COLUMN public.gh_realtime_data.number IS 'Issue/pull request number';
COMMENT ON COLUMN public.gh_realtime_data.comment_id IS 'Comment ID';
COMMENT ON COLUMN public.gh_realtime_data.commit_id IS 'Commit ID';
COMMENT ON COLUMN public.gh_realtime_data.member_id IS 'Member ID';
COMMENT ON COLUMN public.gh_realtime_data.rev_or_push_or_rel_id IS 'Review/push/release ID';
COMMENT ON COLUMN public.gh_realtime_data.ref IS 'Resource name created/deleted';
COMMENT ON COLUMN public.gh_realtime_data.ref_type IS 'Resource type created/deleted';
COMMENT ON COLUMN public.gh_realtime_data.state IS 'State of issue/pull request/review';
COMMENT ON COLUMN public.gh_realtime_data.author_association IS 'Relationship between actor and repo';
COMMENT ON COLUMN public.gh_realtime_data.language IS 'Programming language';
COMMENT ON COLUMN public.gh_realtime_data.merged IS 'Whether merged';
COMMENT ON COLUMN public.gh_realtime_data.merged_at IS 'Merge time';
COMMENT ON COLUMN public.gh_realtime_data.additions IS 'Lines added';
COMMENT ON COLUMN public.gh_realtime_data.deletions IS 'Lines deleted';
COMMENT ON COLUMN public.gh_realtime_data.changed_files IS 'Files changed in pull request';
COMMENT ON COLUMN public.gh_realtime_data.push_size IS 'Number of pushes';
COMMENT ON COLUMN public.gh_realtime_data.push_distinct_size IS 'Number of distinct pushes';
COMMENT ON COLUMN public.gh_realtime_data.hr IS 'Hour of event occurrence (e.g., 00 for 00:23)';
COMMENT ON COLUMN public.gh_realtime_data.month IS 'Month of event occurrence (e.g., 2015-10 for October 2015)';
COMMENT ON COLUMN public.gh_realtime_data.year IS 'Year of event occurrence (e.g., 2015)';
COMMENT ON COLUMN public.gh_realtime_data.ds IS 'Date of event occurrence (yyyy-mm-dd)';

COMMIT;

    2. 論理パーティション化された動的テーブルの作成。

      CREATE  DYNAMIC TABLE ads_dt_github_event
LOGICAL PARTITION BY LIST(ds)
WITH (
  -- Dynamic table properties
  freshness = '5 minutes', 
  auto_refresh_mode = 'auto', 
  auto_refresh_partition_active_time = '2 days' ,
  partition_key_time_format = 'YYYY-MM-DD'
)
AS
SELECT
    repo_name,
    COUNT(*) AS events,
    ds
FROM
    gh_realtime_data
GROUP BY repo_name,ds

    3. 動的テーブルのクエリ

      SELECT * FROM ads_dt_github_event ;

    4. 既存パーティションのバックフィル。

      ベーステーブルの既存データが変更された場合、たとえば 2025-04-01 のデータが更新された場合、動的テーブルを同期できます。これを行うには、既存パーティションを完全更新モードに設定し、サーバーレスを使用して更新を実行します。

      REFRESH OVERWRITE DYNAMIC TABLE ads_dt_github_event
PARTITION (ds = '2025-04-01') 
WITH (
  refresh_mode = 'full'
);

    例 5：増分更新を使用して任意の長期間の UV を計算

    Hologres V3.1 以降、増分更新される動的テーブルは、長期間にわたるユニークビジター (UV) を計算するための RB_BUILD_AGG 関数をサポートします。事前集約と比較して、増分更新には次の利点があります。

    • パフォーマンスの向上：各更新中に増分データのみが計算されます。

    • コストの削減：処理されるデータが少ないため、計算リソースの使用量が削減され、より長期間の計算が可能になります。

    例：

    1. ユーザー詳細テーブルを準備します。

      BEGIN;
CREATE TABLE IF NOT EXISTS ods_app_detail (
     uid INT,
     country TEXT,
     prov TEXT,
     city TEXT,
     channel TEXT,
     operator TEXT,
     brand TEXT,
     ip TEXT,
     click_time TEXT,
     year TEXT,
     month TEXT,
     day TEXT,
     ymd TEXT NOT NULL
);
CALL set_table_property('ods_app_detail', 'orientation', 'column');
CALL set_table_property('ods_app_detail', 'bitmap_columns', 'country,prov,city,channel,operator,brand,ip,click_time, year, month, day, ymd');
-- Set distribution_key based on real-time query needs
CALL set_table_property('ods_app_detail', 'distribution_key', 'uid');
-- Set clustering_key and event_time_column for WHERE filters with full date-time fields
CALL set_table_property('ods_app_detail', 'clustering_key', 'ymd');
CALL set_table_property('ods_app_detail', 'event_time_column', 'ymd');
COMMIT;

    2. 増分更新を使用して UV を計算。

      CREATE DYNAMIC TABLE ads_uv_dt
  WITH (
    freshness = '5 minutes', 
    auto_refresh_mode = 'incremental') 
  AS 
SELECT  
 RB_BUILD_AGG(uid),
 country,
 prov,
 city,
 ymd,
COUNT(1)
FROM    ods_app_detail
WHERE ymd >= '20231201' AND ymd <='20240502'
GROUP BY country,prov,city,ymd;

    3. 任意の期間の UV をクエリ。

      SELECT  
RB_CARDINALITY(RB_OR_AGG(rb_uid)) AS uv,
  country,
  prov,
  city,
  SUM(pv) AS pv
FROM    ads_uv_dt
WHERE   ymd = '20240329'
GROUP BY country,prov,city;

    V3.0

    例 1：完全更新される動的テーブルを作成し、すぐに更新を開始する

    次の手順を実行する前に、tpch_10g パブリックデータセットを Hologres にインポートしてください。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    -- Create "test" schema
CREATE SCHEMA test;

-- Create a single-table fully refreshed Dynamic Table, start refreshing immediately, and refresh every hour
CREATE DYNAMIC TABLE test.thch_q1_full
  WITH (
    refresh_mode='full',
    auto_refresh_enable='true',
    full_auto_refresh_interval='1 hours',
    full_guc_hg_computing_resource='serverless',
    full_guc_hg_experimental_serverless_computing_required_cores='32'
       ) 
AS
  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
        hologres_dataset_tpch_10g.lineitem
WHERE
        l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
        l_returnflag,
        l_linestatus;

    例 2：カスタム開始時刻で増分更新される動的テーブルの作成

    次の手順を実行する前に、tpch_10g パブリックデータセットを Hologres にインポートしてください。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    次の例は、増分更新される動的テーブルの作成方法を示しています。

    説明

    増分動的テーブルを作成する前に、ベーステーブルで binlog を有効にする必要があります。ディメンションテーブルには binlog は不要です。

    -- Enable binlog for base table:
BEGIN;
CALL set_table_property('hologres_dataset_tpch_10g.lineitem', 'binlog.level', 'replica');
COMMIT;

-- Create a single-table incrementally refreshed Dynamic Table, start refreshing at a custom time, and refresh every 3 minutes
CREATE DYNAMIC TABLE public.tpch_q1_incremental 
WITH (
refresh_mode='incremental',
auto_refresh_enable='true',
incremental_auto_refresh_schd_start_time='2024-09-15 23:50:0',
incremental_auto_refresh_interval='3 minutes',
incremental_guc_hg_computing_resource='serverless',
incremental_guc_hg_experimental_serverless_computing_required_cores='30'
) AS SELECT
        l_returnflag,
        l_linestatus,
        COUNT(*) AS count_order
FROM
        hologres_dataset_tpch_10g.lineitem
WHERE
        l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
        l_returnflag,
        l_linestatus
;

    例 3：複数テーブル JOIN の完全更新される動的テーブルの作成

    -- Create a multi-table JOIN Dynamic Table with full refresh mode, refreshing every 3 hours
CREATE DYNAMIC TABLE dt_q_full
  WITH (
    refresh_mode='full',
    auto_refresh_enable='true',
    full_auto_refresh_schd_start_time='immediate',
    full_auto_refresh_interval='3 hours',
    full_guc_hg_computing_resource='serverless',
    full_guc_hg_experimental_serverless_computing_required_cores='64'
  ) 
AS 
SELECT
        o_orderpriority,
        COUNT(*) AS order_count
FROM
        hologres_dataset_tpch_10g.orders
WHERE
        o_orderdate >= DATE '1996-07-01'
        AND o_orderdate < DATE '1996-07-01' + INTERVAL '3' MONTH
        AND EXISTS (
                SELECT
                        *
                FROM
                        hologres_dataset_tpch_10g.lineitem
                WHERE
                        l_orderkey = o_orderkey
                        AND l_commitdate < l_receiptdate
        )
GROUP BY
        o_orderpriority;

    例 4：ディメンションテーブル JOIN の増分更新される動的テーブルの作成

    例：ディメンションテーブルを増分更新される動的テーブルと結合する。

    説明

    増分動的テーブルを作成する前に、ベーステーブルで binlog を有効にする必要があります。ディメンションテーブルには binlog は不要です。

    ディメンションテーブル JOIN のセマンティクス：各データレコードは、処理時にディメンションテーブルの最新バージョンとのみ結合されます。JOIN 操作後にディメンションテーブルのデータが変更された場合、以前に結合されたデータは更新されません。以下はサンプル SQL 文です。

    -- Detail table
BEGIN;
CREATE TABLE public.sale_detail(
        app_id TEXT,
        uid TEXT,
        product TEXT,
        gmv BIGINT,
        order_time TIMESTAMPTZ
);
-- Enable binlog for base table (dimension tables do not require it)
CALL set_table_property('public.sale_detail', 'binlog.level', 'replica');
COMMIT;

-- Attribute table
CREATE TABLE public.user_info(
        uid TEXT,
        province TEXT,
        city TEXT
);

CREATE DYNAMIC TABLE public.dt_sales_incremental
  WITH (
    refresh_mode='incremental',
    auto_refresh_enable='true',
    incremental_auto_refresh_schd_start_time='2024-09-15 00:00:00',
    incremental_auto_refresh_interval='5 minutes',
    incremental_guc_hg_computing_resource='serverless',
    incremental_guc_hg_experimental_serverless_computing_required_cores='128') 
AS 
SELECT 
    sale_detail.app_id,
    sale_detail.uid,
    product,
    SUM(sale_detail.gmv) AS sum_gmv,
    sale_detail.order_time,
    user_info.province,
    user_info.city 
FROM public.sale_detail 
INNER JOIN public.user_info  FOR SYSTEM_TIME AS OF PROCTIME()
ON sale_detail.uid =user_info.uid
GROUP BY sale_detail.app_id,sale_detail.uid,sale_detail.product,sale_detail.order_time,user_info.province,user_info.city;

    例 5：パーティション動的テーブルの作成

    リアルタイムのトランザクションダッシュボードなどのシナリオでは、現在のデータのほぼリアルタイムのビューと、既存データの修正のサポートが必要になる場合があります。この場合、動的テーブルに増分更新と完全更新の両方を使用できます。

    1. パーティション化されたベーステーブルを作成します。データは最新のパーティションにリアルタイムまたはほぼリアルタイムで書き込まれます。既存のパーティションでは、データ修正が時々実行されます。

    2. 親パーティションテーブルとして動的テーブルを作成します。最新のパーティションには増分更新を使用して、ほぼリアルタイムの分析のニーズを満たします。

    3. 既存のパーティションを完全更新モードに切り替えます。既存のソースパーティションのデータが修正またはバックフィルされた場合、対応する既存の動的テーブルパーティションを完全更新を使用して更新できます。バックフィルプロセスを高速化するためにサーバーレスを使用できます。

    例：

    1. ベーステーブルとデータの準備。

      ベーステーブルはパーティション化されています。データは最新のパーティションにリアルタイムで書き込まれます。

      -- Create partitioned source table
CREATE TABLE base_sales(
  uid INT,
  opreate_time TIMESTAMPTZ,
  amount FLOAT,
  tt TEXT NOT NULL,
  ds TEXT,
  PRIMARY KEY(ds)
) PARTITION BY LIST (ds) ;

-- Historical partition
CREATE TABLE base_sales_20240615 PARTITION OF base_sales FOR VALUES IN ('20240615');
INSERT INTO base_sales_20240615 VALUES (2,'2024-06-15 16:18:25.387466+08','111','2','20240615');

-- Latest partition (typically real-time writes)
CREATE TABLE base_sales_20240616 PARTITION OF base_sales FOR VALUES IN ('20240616');
INSERT INTO base_sales_20240616 VALUES (1,'2024-06-16 16:08:25.387466+08','2','1','20240616');

    2. 動的テーブルの親パーティションテーブルを作成します。このステップでは、クエリを定義するだけで、更新モードを設定する必要はありません。

      -- Create extension
CREATE EXTENSION roaringbitmap;

CREATE DYNAMIC TABLE partition_dt_base_sales
PARTITION BY LIST (ds)
as
SELECT  
 public.RB_BUILD_AGG(uid),
 opreate_time,
 amount,
 tt,
 ds,
COUNT(1)
FROM    base_sales
GROUP BY opreate_time ,amount,tt,ds;

    3. 子テーブルを作成し、その更新モードを設定します。

      動的テーブルパーティションの子テーブルを手動で作成するか、DataWorks を使用して動的に作成できます。最新のパーティションには増分更新を使用し、既存のパーティションには完全更新を使用します。

      -- Enable binlog for base table
ALTER TABLE base_sales SET (binlog_level = replica);

-- Assume historical Dynamic Table partition child table exists:
CREATE DYNAMIC TABLE partition_dt_base_sales_20240615 PARTITION OF partition_dt_base_sales FOR VALUES IN ('20240615')
  WITH (
    refresh_mode='incremental',
    auto_refresh_enable='true',
    incremental_auto_refresh_schd_start_time='immediate',
    incremental_auto_refresh_interval='30 minutes'
       );

-- Create new Dynamic Table partition child table with incremental refresh for the latest partition, starting immediately with 30-minute intervals using instance resources
CREATE DYNAMIC TABLE partition_dt_base_sales_20240616 PARTITION OF partition_dt_base_sales FOR VALUES IN ('20240616')
  WITH (
    refresh_mode='incremental',
    auto_refresh_enable='true',
    incremental_auto_refresh_schd_start_time='immediate',
    incremental_auto_refresh_interval='30 minutes'
       );

-- Switch historical partition to full refresh mode
ALTER DYNAMIC TABLE partition_dt_base_sales_20240615 SET (refresh_mode = 'full');
-- If historical partition needs data correction, run a refresh. Use Serverless for better performance
SET hg_computing_resource = 'serverless';
REFRESH DYNAMIC TABLE partition_dt_base_sales_20240615;

    構文変換コマンド

    Hologres V3.1 で動的テーブルの構文がアップグレードされました。V3.0 からアップグレードする場合、V3.1 の構文を使用してテーブルを再作成する必要があります。このプロセスを簡素化するために、Hologres は構文変換ツールを提供しています。

    テーブルの再作成が必要なシナリオ

    • 増分更新を使用する動的テーブルは再作成する必要があります。

    • アップグレードチェック中に構文の非互換性が見つかった場合、アップグレードレポートで指定されたとおりにテーブルを再作成する必要があります。

    説明

    V3.0 構文を使用する動的テーブルは、上記のシナリオに該当しない限り再作成する必要はありません。ただし、これらのテーブルに対しては ALTER 操作しか実行できません。V3.0 構文を使用して新しいテーブルを作成することはできません。

    構文変換コマンドの適用シナリオ

    構文変換コマンドは、増分または完全更新モードを使用する非パーティションテーブルにのみ適用されます。V3.0 構文を使用するパーティション化された動的テーブルは手動で再作成する必要があります。これらのテーブルを再作成する際には、論理パーティションを使用することを推奨します。

    変換が必要なテーブルの表示

    次のコマンドを実行して、アップグレード後に変換が必要なテーブルを表示できます。

    非パーティションテーブル

    SELECT DISTINCT 
    p.dynamic_table_namespace as table_namespace, 
    p.dynamic_table_name as table_name
FROM hologres.hg_dynamic_table_properties p
JOIN pg_class c ON c.relname = p.dynamic_table_name
JOIN pg_namespace n ON n.oid = c.relnamespace AND n.nspname = p.dynamic_table_namespace
WHERE p.property_key = 'refresh_mode' 
    AND p.property_value = 'incremental'
    AND c.relispartition = false 
    AND c.relkind != 'p';

    パーティションテーブル

    SELECT DISTINCT 
    pn.nspname as parent_schema,
    pc.relname as parent_name
FROM hologres.hg_dynamic_table_properties p
JOIN pg_class c ON c.relname = p.dynamic_table_name
JOIN pg_namespace n ON n.oid = c.relnamespace AND n.nspname = p.dynamic_table_namespace
JOIN pg_inherits i ON c.oid = i.inhrelid
JOIN pg_class pc ON pc.oid = i.inhparent
JOIN pg_namespace pn ON pn.oid = pc.relnamespace
WHERE p.property_key = 'refresh_mode' 
    AND p.property_value = 'incremental'
    AND c.relispartition = true 
    AND c.relkind != 'p';

    構文変換コマンドの使用

    構文変換コマンドを使用する前に、次の情報に注意してください。

    • このコマンドは Hologres V3.1.11 以降のバージョンでのみサポートされています。

    • コマンドを実行するにはスーパーユーザー権限が必要です。

    • コマンドを実行すると、次の変更が発生します。

      • 自動更新が有効になっている場合、更新タスクはすぐに開始されます。リソース競合を避けるため、オフピーク時にコマンドを実行することを推奨します。サーバーレスインスタンスを使用して更新タスクを分離できます。

      • リソース使用量が変更されます。

        • 計算グループインスタンスで新しい構文 (V3.1 および V3.2) を使用する場合、ウェアハウスリソースはベーステーブルの TG と動的テーブルの TG のリーダーウェアハウスから割り当てられます。

        • V4.1 インスタンスで古い構文 (V3.0) または新しい構文を使用する場合、ウェアハウスリソースは動的テーブルの TG のリーダーウェアハウスから割り当てられます。

      • 接続数が変更されます。新しい構文は、より安定して効率的なスケジューリングメカニズムを使用するため、各動的テーブルが追加で 1 つの接続を使用します。インスタンスの接続使用率が高く、動的テーブルが多い場合 (数百など)、コマンドを実行する前にアイドル接続をクリーンアップすることを推奨します。

    変換コマンド：

    -- Applies only to non-partitioned tables (both full and incremental refresh). Recreate partitioned tables manually and consider using logical partitions.
-- Convert a single table
call hg_dynamic_table_config_upgrade('<table_name>');

-- Batch convert all tables. Use with caution.
call hg_upgrade_all_normal_dynamic_tables();
    説明

    このコマンドは、現在のデータベース内の V3.0 構文を使用するすべての動的テーブルを V3.1 構文を使用するように変換します。

    構文パラメーターのマッピング

    次の表は、構文変換コマンドを使用する際の V3.0 と V3.1 のパラメーターのマッピングを示しています。

    V3.0 パラメーター名

    V3.1 パラメーター

    説明

    refresh_mode

    auto_refresh_mode

    値は変更されません。例：refresh_mode='incremental' は auto_refresh_mode='incremental' になります。

    auto_refresh_enable

    auto_refresh_enable

    値は変更されません。

    {refresh_mode}_auto_refresh_schd_start_time

    freshness

    auto_refresh_interval の値が freshness に変換されます。

    例：full_auto_refresh_interval='30 minutes' は freshness='30 minutes' になります。

    {refresh_mode}_auto_refresh_interval

    {refresh_mode}_guc_hg_computing_resource

    computing_resource

    値は変更されません。例：full_guc_hg_computing_resource='serverless' は computing_resource='serverless' になります。

    {refresh_mode}_guc_hg_experimental_serverless_computing_required_cores

    refresh_guc_hg_experimental_serverless_computing_required_cores

    値は変更されません。

    {refresh_mode}_guc_<guc>

    refresh_guc_<guc_name>

    値は変更されません。例：

    incremental_guc_hg_experimental_max_consumed_rows_per_refresh='1000000' は refresh_guc_hg_experimental_max_consumed_rows_per_refresh='1000000' になります。

    orientation およびその他のテーブルプロパティ

    orientation およびその他のテーブルプロパティ

    すべての基本的なテーブルプロパティは変更されません。

    次のステップ：動的テーブルの管理

    動的テーブルを作成した後、以下の操作を実行できます。

    よくある質問

    • 問題：Segment Key または Clustering Key が空の場合にエラーが発生します。以下はエラーの例です。

      ERROR: commit ddl phase1 failed: the index partition key "xxx" should not be nullable

    • 原因：このエラーは、動的テーブルの Segment Key または Clustering Key として指定された列に null 値を含めることができないために発生します。Segment Key と Clustering Key のルールに関する詳細については、「Event Time Column (Segment Key)」をご参照ください。

    • 解決策：

      1. エラーが Clustering Key に関連している場合、このエラーは Hologres V3.1.26、V3.2.9、V4.0.0 以降のバージョンで作成されたテーブルでは発生しません。それ以前のバージョンの場合は、インスタンスをアップグレードし、次の GUC を実行して null 許容の Clustering Key を許可してください。

        -- V3.1+ syntax to allow nullable segment key
ALTER DYNAMIC TABLE [ IF EXISTS ] [<schema>.]<table_name> SET
(refresh_guc_hg_experimental_enable_nullable_segment_key=true);

      2. エラーが Segment Key に関連している場合、次の GUC を実行して null 許容の Segment Key を許可してください。Segment Key は Hologres V4.1 以降で null 許容にできます。インスタンスをアップグレードすることを推奨します。

        -- V3.1+ syntax to allow nullable clustering key
ALTER DYNAMIC TABLE [ IF EXISTS ] [<schema>.]<table_name> SET
(refresh_guc_hg_experimental_enable_nullable_clustering_key=true);