すべてのプロダクト
Search

このプロダクト

    Hologres:CREATE DYNAMIC TABLE

    ドキュメントセンター

    Hologres:CREATE DYNAMIC TABLE

    最終更新日:Dec 18, 2025

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

    注意事項

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

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

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

    • Hologres V3.1 以降、DPI エンジンは安定性を向上させるために、動的テーブルの更新操作の実行を自動的に最適化します。そのため、更新操作のクエリ 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 (
  -- 動的テーブルのプロパティ
  freshness = '<num> {minutes | hours}', -- 必須
  [auto_refresh_enable = {true | false},] -- オプション
  [auto_refresh_mode = {'full' | 'incremental' | 'auto'},] -- オプション
  
  [base_table_cdc_format = {'stream' | 'binlog'},] -- オプション

  [auto_refresh_partition_active_time = '<num> {minutes | hours | days}',] -- オプション
  [partition_key_time_format = {'YYYYMMDDHH24' | 'YYYY-MM-DD-HH24' | 'YYYY-MM-DD_HH24' | 'YYYYMMDD' | 'YYYY-MM-DD' | 'YYYYMM' | 'YYYY-MM' | 'YYYY'},] --オプション
  
  [computing_resource = {'local' | 'serverless' | '<warehouse_name>'},] -- オプション。warehouse_name の値は Hologres V4.0.7 以降でのみサポートされます。
  [refresh_guc_hg_experimental_serverless_computing_required_cores=xxx,]--オプション。計算リソースの仕様。
  
  [refresh_guc_<guc_name> = '<guc_value>',] -- オプション

  -- 一般的なプロパティ
  [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>; -- クエリの定義。

    パラメーター

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

    パラメーター

    説明

    必須

    デフォルト値

    freshness

    データの鮮度。単位は分または時間です。最小値は 1 分です。DPI エンジンは、最後の更新操作の時間と指定された freshness の値に基づいて、次の更新操作を自動的にスケジュールします。間隔を設定するのと比較して、freshness はより自動化された方法でデータの鮮度を保証します。

    はい

    なし

    auto_refresh_mode

    リフレッシュモード。有効な値：

    • auto：自動モード。クエリが増分更新をサポートしている場合、増分更新が優先されます。それ以外の場合、システムは完全更新にフォールバックします。

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

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

    いいえ

    auto

    auto_refresh_enable

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

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

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

    いいえ

    true

    base_table_cdc_format

    増分更新のためにベーステーブルからデータを消費する方法。

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

    • binlog：バイナリログを使用してベーステーブルからデータを消費します。このパラメーターを設定する場合、ベーステーブルのバイナリログも手動で有効にする必要があります。詳細については、「Hologres バイナリログのサブスクライブ」をご参照ください。

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

    • V3.1 以降、すべてのテーブルはデフォルトでストリーム方式を使用してベーステーブルのデータ変更を消費します。テーブルでバイナリログを有効にしている場合は、ストレージの無駄を避けるために速やかに無効にしてください。

    • ベーステーブルが行指向テーブルの場合、バイナリログ方式のみがサポートされます。 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 となるパーティションです。

    説明

    • 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

    動的テーブルのフィールド名。

    動的テーブルの列名を明示的に指定できますが、列のプロパティやデータ型は指定できません。DPI エンジンが自動的に推測します。

    説明

    列のプロパティとデータ型を指定すると、DPI エンジンが正しく推測できない場合があります。

    いいえ

    クエリ列名

    クエリ列名

    orientation

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

    いいえ

    column

    column

    table_group

    動的テーブルが属するテーブルグループを指定します。デフォルトでは、現在のデータベースのデフォルトテーブルグループです。詳細については、「テーブルグループと Shard Count の操作」をご参照ください。

    いいえ

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

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

    distribution_key

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

    いいえ

    なし

    なし

    clustering_key

    動的テーブルのクラスタリングキーを指定します。詳細については、「クラスタリングキー」をご参照ください。

    いいえ

    設定可能。デフォルトの推測値あり。

    設定可能。デフォルトの推測値あり。

    event_time_column

    動的テーブルの event_time_column を指定します。詳細については、「イベント時間列 (セグメントキー)」をご参照ください。

    いいえ

    なし

    なし

    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

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

    説明

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

    • 完全更新を使用する動的テーブルでバイナリログを有効にすることは推奨しません。

    いいえ

    none

    none

    binlog_ttl

    動的テーブルでバイナリログを有効にした後のバイナリログのライフサイクル。

    いいえ

    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',]

  --増分更新に固有のパラメーター：
    [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>',]

   --完全更新に固有のパラメーター：
    [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 のデフォルト値は serverless です。DB レベルで設定できます。このパラメーターを設定する必要はありません。
    [full_guc_hg_experimental_serverless_computing_required_cores='<num>',]
    
   --共有パラメーター、GUC を設定可能：
   [refresh_guc_<guc>='xxx]',] 
   
  --動的テーブルの一般的なプロパティ：
    [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> --クエリの定義。

    パラメーター

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

    パラメーターカテゴリ

    パラメーター

    説明

    必須

    デフォルト値

    共有更新パラメーター

    refresh_mode

    データ更新モードを指定します。有効値：full および incremental。

    このパラメーターを設定しない場合、更新は実行されません。

    いいえ

    なし

    auto_refresh_enable

    自動更新を有効にするかどうかを指定します。有効値：

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

    • false：自動更新を有効にしません。

    いいえ

    false

    refresh_guc_<guc>

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

    説明

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

    いいえ

    なし

    増分更新 (incremental)

    incremental_auto_refresh_schd_start_time

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

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

    • <timestamptz>：増分更新のカスタム開始時刻。たとえば、2024-08-24 1:00 に設定すると、更新タスクは 2024-08-24 1:00 に開始されます。

    いいえ

    immediate

    incremental_auto_refresh_interval

    増分更新の間隔。単位：minute、minutes、hour、または hours。

    • 値の範囲は 1 分から 48 時間です。

    • このパラメーターを設定しない場合、更新操作は更新開始時刻に一度だけ実行されます。

    いいえ

    なし

    incremental_guc_hg_computing_resource

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

    • local：現在のインスタンスのリソース。

    • serverless：サーバーレスリソースを使用します。インスタンスがサーバーレス要件を満たしているか確認してください。詳細については、「サーバーレスコンピューティングユーザーガイド」をご参照ください。

    説明

    ALTER DATABASE xxx SET incremental_guc_hg_computing_resource=xx コマンドを使用して、DB レベルで増分更新の計算リソースを設定できます。

    いいえ

    local

    incremental_guc_hg_experimental_serverless_computing_required_cores

    更新にサーバーレスリソースを使用する場合、更新のための計算リソース量を設定する必要があります。

    説明

    異なる仕様のインスタンスで利用可能なサーバーレスリソースは限られています。詳細については、「サーバーレスコンピューティングユーザーガイド」をご参照ください。

    いいえ

    なし

    完全更新 (full)

    full_auto_refresh_schd_start_time

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

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

    • <timestamptz>：完全更新のカスタム開始時刻。たとえば、2024-08-24 1:00 に設定すると、更新タスクは 2024-08-24 1:00 に開始されます。

    いいえ

    immediate

    full_auto_refresh_interval

    完全更新の間隔。単位：minute、minutes、hour、または hours。

    • 値の範囲は 1 分から 48 時間です。

    • このパラメーターを設定しない場合、更新操作は更新開始時刻に一度だけ実行されます。

    いいえ

    なし

    full_guc_hg_computing_resource

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

    • local：現在のインスタンスのリソース。

    • serverless：サーバーレスリソースを使用します。インスタンスがサーバーレス要件を満たしているか確認してください。詳細については、「サーバーレスコンピューティングユーザーガイド」をご参照ください。

    説明

    ALTER DATABASE xxx SET full_guc_hg_computing_resource=xx コマンドを使用して、DB レベルで完全更新の計算リソースを設定できます。

    いいえ

    local

    full_guc_hg_experimental_serverless_computing_required_cores

    更新にサーバーレスリソースを使用する場合、更新のための計算リソース量を設定する必要があります。

    説明

    異なる仕様のインスタンスで利用可能なサーバーレスリソースは限られています。詳細については、「サーバーレスコンピューティングユーザーガイド」をご参照ください。

    いいえ

    なし

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

    パラメーター

    説明

    必須

    デフォルト値

    full

    incremental

    col_name

    動的テーブルのフィールド名。

    動的テーブルの列名を明示的に指定できますが、列のプロパティやデータ型は指定できません。DPI エンジンが自動的に推測します。

    説明

    列のプロパティとデータ型を指定すると、DPI エンジンが正しく推測できない場合があります。

    いいえ

    クエリ列名

    クエリ列名

    orientation

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

    いいえ

    column

    column

    table_group

    動的テーブルが属するテーブルグループを指定します。デフォルトでは、現在のデータベースのデフォルトテーブルグループです。詳細については、「テーブルグループと Shard Count の操作」をご参照ください。

    いいえ

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

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

    distribution_key

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

    いいえ

    なし

    なし

    clustering_key

    動的テーブルのクラスタリングキーを指定します。詳細については、「クラスタリングキー」をご参照ください。

    いいえ

    設定可能。デフォルトの推測値あり。

    設定可能。デフォルトの推測値あり。

    event_time_column

    動的テーブルの event_time_column を指定します。詳細については、「イベント時間列 (セグメントキー)」をご参照ください。

    いいえ

    なし

    なし

    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 は、デフォルトでストリームモードを使用して増分データを消費します。V3.0 でベーステーブルにバイナリログをすでに有効にしている場合は、ストレージコストの増加を防ぐために無効にすることを推奨します。

      • V3.0 では、ベーステーブルでバイナリログを有効にする必要があります。ディメンションテーブルの JOIN の場合、ディメンションテーブルでバイナリログを有効にする必要はありません。ベーステーブルでバイナリログを有効にすると、ストレージオーバーヘッドが発生します。バイナリログが占有するストレージスペースをクエリできます。詳細については、「テーブルストレージの詳細」をご参照ください。

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

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

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

    デュアルストリーム JOIN は複数テーブルの JOIN です。そのセマンティクスは OLAP クエリと同じで、HASH JOIN に基づいて実装されています。INNER JOIN、LEFT OUTER JOIN、RIGHT OUTER JOIN、FULL OUTER JOIN の 4 種類の結合をサポートしています。

    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;

-- 更新後、1 つの関連レコードが表示されます。
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);

-- 更新後、2 つの関連レコードが表示されます。ディメンションテーブルの更新はすべてのデータに有効で、関連データを修正できます。
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 を有効にする必要があります。

    -- セッションレベルで有効化
SET hg_experimental_incremental_dynamic_table_enable_hash_join TO ON;

--DB レベルで有効化。新しい接続に有効。
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;

-- 更新後、1 つの関連レコードが表示されます。
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);

-- 更新後、2 つの関連レコードが表示されます。ディメンションテーブルの更新はすべてのデータに有効で、関連データを修正できます。
REFRESH TABLE dt;
SELECT * FROM dt;

    次の結果が返されます。

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

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

    ディメンションテーブルの JOIN のセマンティクスは、各レコードが処理時にディメンションテーブルデータの最新バージョンにのみ関連付けられることを意味します。結合が発生した後にディメンションテーブルのデータが変更された場合 (新しいデータが追加、更新、または削除された場合)、関連付けられたディメンションテーブルのデータは同期的に更新されません。以下は SQL 文の例です：

    説明

    SQL でディメンションテーブルの JOIN セマンティクスが使用されている場合、ディメンションテーブルの JOIN 操作は参加するテーブルのデータ量に依存しません。

    V3.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() は、users をディメンションテーブルとして識別するために使用されます。
FROM orders LEFT JOIN users FOR SYSTEM_TIME AS OF PROCTIME()
ON orders.user_id = users.user_id;

-- 更新後、1 つの関連レコードが表示されます。
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);

-- 更新後、2 つの関連レコードが表示されます。ディメンションテーブルの更新は新しいデータにのみ有効で、関連データを修正することはできません。
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() は、users をディメンションテーブルとして識別するために使用されます。
FROM orders LEFT JOIN users FOR SYSTEM_TIME AS OF PROCTIME()
ON orders.user_id = users.user_id;

-- 更新後、1 つの関連レコードが表示されます。
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);

-- 更新後、2 つの関連レコードが表示されます。ディメンションテーブルの更新は新しいデータにのみ有効で、関連データを修正することはできません。
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 では、統合された完全および増分更新がデフォルトで有効になっています。以下は例です：

    --ベーステーブルを準備し、バイナリログを有効にし、データを挿入します。
CREATE TABLE base_sales(
  day TEXT NOT NULL,
  hour INT,
  user_id BIGINT,
  ts TIMESTAMPTZ,
  amount FLOAT,
  pk text NOT NULL PRIMARY KEY
);

-- ベーステーブルにデータをインポートします。
INSERT INTO base_sales values ('2024-08-29',1,222222,'2024-08-29 16:41:19.141528+08',5,'ddd');


-- ベーステーブルに増分データをインポートします。
INSERT INTO base_sales VALUES ('2024-08-29',2,3333,'2024-08-29 17:44:19.141528+08',100,'aaaaa');


-- 自動更新の増分動的テーブルを作成し、統合された完全および増分データ消費の GUC を有効にします。
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

    V3.0

    V3.0 では、統合された完全および増分更新を実装するために GUC パラメーターを有効にする必要があります。以下は例です：

    --ベーステーブルを準備し、バイナリログを有効にし、データを挿入します。
CREATE TABLE base_sales(
  day TEXT NOT NULL,
  hour INT,
  user_id BIGINT,
  ts TIMESTAMPTZ,
  amount FLOAT,
  pk text NOT NULL PRIMARY KEY
);

-- ベーステーブルにデータをインポートします。
INSERT INTO base_sales values ('2024-08-29',1,222222,'2024-08-29 16:41:19.141528+08',5,'ddd');

-- ベーステーブルのバイナリログを有効にします。
ALTER TABLE base_sales SET (binlog_level = replica);

-- ベーステーブルに増分データをインポートします。
INSERT INTO base_sales VALUES ('2024-08-29',2,3333,'2024-08-29 17:44:19.141528+08',100,'aaaaa');


-- 自動更新の増分動的テーブルを作成し、統合された完全および増分データ消費の GUC を有効にします。
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 にデータをインポートします。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    説明

    増分動的テーブルを作成する前に、ベーステーブルでバイナリログを有効にする必要があります。ディメンションテーブルで有効にする必要はありません。

    --単一テーブルの増分更新動的テーブルを作成し、更新開始時刻を指定して、3 分ごとに更新します。
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 にデータをインポートします。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    説明

    増分動的テーブルを作成する前に、ベーステーブルでバイナリログを有効にする必要があります。ディメンションテーブルで有効にする必要はありません。

    --複数テーブル結合を持つ増分更新動的テーブルを作成します。
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：自動更新動的テーブルの作成

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

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

    --自動更新動的テーブルを作成します。エンジンは自動的に更新モデルを選択します。結果として、増分更新モードが使用されます。
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 'イベント ID';
COMMENT ON COLUMN public.gh_realtime_data.actor_id IS 'イベント開始者 ID';
COMMENT ON COLUMN public.gh_realtime_data.actor_login IS 'イベント開始者ログイン名';
COMMENT ON COLUMN public.gh_realtime_data.repo_id IS 'repoID';
COMMENT ON COLUMN public.gh_realtime_data.repo_name IS 'repo 名';
COMMENT ON COLUMN public.gh_realtime_data.org_id IS 'repo 組織 ID';
COMMENT ON COLUMN public.gh_realtime_data.org_login IS 'repo 組織名';
COMMENT ON COLUMN public.gh_realtime_data.type IS 'イベントタイプ';
COMMENT ON COLUMN public.gh_realtime_data.created_at IS 'イベント発生時刻';
COMMENT ON COLUMN public.gh_realtime_data.action IS 'イベント動作';
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 序数';
COMMENT ON COLUMN public.gh_realtime_data.comment_id IS 'コメント ID';
COMMENT ON COLUMN public.gh_realtime_data.commit_id IS 'コミットレコード ID';
COMMENT ON COLUMN public.gh_realtime_data.member_id IS 'メンバー 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 '作成/削除されたリソースの名前';
COMMENT ON COLUMN public.gh_realtime_data.ref_type IS '作成/削除されたリソースのタイプ';
COMMENT ON COLUMN public.gh_realtime_data.state IS 'issue/pull_request/pull_request_review の状態';
COMMENT ON COLUMN public.gh_realtime_data.author_association IS 'アクターと repo の関係';
COMMENT ON COLUMN public.gh_realtime_data.language IS 'プログラミング言語';
COMMENT ON COLUMN public.gh_realtime_data.merged IS 'マージを受け入れるかどうか';
COMMENT ON COLUMN public.gh_realtime_data.merged_at IS 'コードマージ時間';
COMMENT ON COLUMN public.gh_realtime_data.additions IS '追加されたコード行数';
COMMENT ON COLUMN public.gh_realtime_data.deletions IS '削除されたコード行数';
COMMENT ON COLUMN public.gh_realtime_data.changed_files IS 'プルリクエストで変更されたファイル数';
COMMENT ON COLUMN public.gh_realtime_data.push_size IS 'コミット数';
COMMENT ON COLUMN public.gh_realtime_data.push_distinct_size IS '個別コミット数';
COMMENT ON COLUMN public.gh_realtime_data.hr IS 'イベント発生時間、例：00:23 の場合、hr=00';
COMMENT ON COLUMN public.gh_realtime_data.month IS 'イベント発生月、例：2015 年 10 月の場合、month=2015-10';
COMMENT ON COLUMN public.gh_realtime_data.year IS 'イベント発生年、例：2015 年の場合、year=2015';
COMMENT ON COLUMN public.gh_realtime_data.ds IS 'イベント発生日、ds=yyyy-mm-dd';

COMMIT;

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

      CREATE  DYNAMIC TABLE ads_dt_github_event
LOGICAL PARTITION BY LIST(ds)
WITH (
  -- 動的テーブルのプロパティ
  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 以降、動的テーブルの増分更新は RB_BUILD_AGG 関数をサポートし、任意の長期間にわたるユニークビジター (UV) を計算します。元の事前集計ソリューションと比較して、増分更新には以下の利点があります：

    • より高速なパフォーマンス：毎回増分データのみが計算されるため、計算が高速になります。

    • 低コスト：計算に関与するデータ量が少ないため、使用される計算リソースが削減され、コストが低減されます。このアプローチは、より長いデータ期間にわたる計算をサポートします。

    例：

    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');
--必要に応じて distribution_key を設定します。このテーブルのリアルタイムクエリ要件に基づいて、より良い結果を得るためにどのディメンションでシャーディングするかを決定します。
CALL set_table_property('ods_app_detail', 'distribution_key', 'uid');
--where フィルター条件に使用されます。完全な年、月、日を含む時間フィールドを clustering_key および event_time_column として設定することを推奨します。
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 にデータをインポートします。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    --「test」スキーマを作成します。
CREATE SCHEMA test;

--単一テーブルの完全更新動的テーブルを作成し、すぐに更新を開始し、1 時間ごとに更新します。
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 にデータをインポートします。詳細については、「パブリックデータセットのワンクリックインポート」をご参照ください。

    以下は、増分動的テーブルを作成する例です：

    説明

    増分動的テーブルを作成する前に、ベーステーブルでバイナリログを有効にする必要があります。ディメンションテーブルで有効にする必要はありません。

    --ベーステーブルのバイナリログを有効にします：
BEGIN;
CALL set_table_property('hologres_dataset_tpch_10g.lineitem', 'binlog.level', 'replica');
COMMIT;

--単一テーブルの増分更新動的テーブルを作成し、更新開始時刻を指定して、3 分ごとに更新します。
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 を伴う完全更新動的テーブルの作成

    --複数テーブル結合クエリを持つ動的テーブルを作成し、完全更新モードで、3 時間ごとに更新します。
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 を伴う増分更新動的テーブルの作成

    以下は、ディメンションテーブル JOIN を伴う増分動的テーブルを作成する例です：

    説明

    増分動的テーブルを作成する前に、ベーステーブルでバイナリログを有効にする必要があります。ディメンションテーブルで有効にする必要はありません。

    ディメンションテーブルの JOIN のセマンティクスは、各レコードが処理時にディメンションテーブルデータの最新バージョンにのみ関連付けられることを意味します。結合が発生した後にディメンションテーブルのデータが変更された場合 (新しいデータが追加、更新、または削除された場合)、関連付けられたディメンションテーブルのデータは同期的に更新されません。以下は SQL 文の例です：

    --詳細テーブル
BEGIN;
CREATE TABLE public.sale_detail(
        app_id TEXT,
        uid TEXT,
        product TEXT,
        gmv BIGINT,
        order_time TIMESTAMPTZ
);
--ベーステーブルのバイナリログを有効にします。ディメンションテーブルで有効にする必要はありません。
CALL set_table_property('public.sale_detail', 'binlog.level', 'replica');
COMMIT;

--プロパティテーブル
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 TABLE base_sales(
  uid INT,
  opreate_time TIMESTAMPTZ,
  amount FLOAT,
  tt TEXT NOT NULL,
  ds TEXT,
  PRIMARY KEY(ds)
) PARTITION BY LIST (ds) ;

--既存のパーティション
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');

--最新のパーティション、通常はリアルタイム書き込み
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 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 を使用して動的に作成することもできます。最新のパーティションを増分更新モードで作成し、既存のパーティションを完全更新モードに設定します。

      -- ベーステーブルのバイナリログを有効にします。
ALTER TABLE base_sales SET (binlog_level = replica);

-- 既存の子パーティション動的テーブルは次のようになると仮定します：
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'
       );

-- 新しい子パーティション動的テーブルを作成し、最新のパーティションの更新モードを増分更新に設定し、テーブル作成後すぐに更新を開始し、更新間隔を 30 分に設定し、現在のインスタンスのリソースを更新に使用します。
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'
       );

--既存のパーティションを完全更新モードに変換します。
ALTER DYNAMIC TABLE partition_dt_base_sales_20240615 SET (refresh_mode = 'full');
--既存のパーティションにデータ修正が必要な場合は、更新を実行できます。サーバーレスで行うことを推奨します。
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.1 および V3.2) を使用する場合、使用されるウェアハウスリソースは、ベーステーブルの TG のリーダーウェアハウスと動的テーブルの TG のリーダーウェアハウスです。

        • 古い構文 (V3.0) を使用する場合、またはインスタンスが V4.1 で新しい構文を使用する場合、計算グループインスタンスでは、使用されるウェアハウスリソースは動的テーブルの TG のリーダーウェアハウスです。

      • 接続数の変更：新しい構文は、より安定して効率的な基盤となるスケジューリング機能を使用します。各動的テーブルは追加で 1 つの接続を使用します。インスタンスの接続使用率が高く、数百もの動的テーブルがある場合は、まずアイドル接続をクリアすることを推奨します。

    構文変換コマンドは次のとおりです。

    --非パーティションテーブルにのみ適用されます (更新モードには完全および増分更新が含まれます)。パーティションテーブルの場合は、手動で再作成し、論理パーティションを使用することを推奨します。
--単一テーブルの変換
call hg_dynamic_table_config_upgrade('<table_name>');

--すべてのテーブルを一括変換します。注意して使用してください。
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 およびその他のテーブルプロパティ

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

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

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

    よくある質問

    • 現象：セグメントキー/クラスタリングキーが空であるため、エラーが報告されます。以下はエラーメッセージの例です：

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

    • 原因：動的テーブルのセグメントキー/クラスタリングキーは、null 値を許可しない列です。セグメントキーとクラスタリングキーの設定ルールの詳細については、「イベント時間列 (セグメントキー)」をご参照ください。

    • 解決策：CREATE DYNAMIC TABLE DDL の前に以下の GUC パラメーターを追加し、DDL 文と一緒に実行します。

      SET hg_experimental_enable_nullable_segment_key = true;
SET hg_experimental_enable_nullable_clustering_key = true;

      以下は例です。

      SET hg_experimental_enable_nullable_segment_key = true;
SET hg_experimental_enable_nullable_clustering_key = true;

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;