Hologres:Liquid Table

Liquid Table とは

Liquid Table は、Hologres の新しいテーブルストレージモードです。その決定的な機能は次のとおりです：

これにより、従来のデータウェアハウスにおいて「データ増加後にシャードの粒度を調整するには法外なコストがかかる」という長年の問題点に対処します。

主な機能

• オンラインリシャーディング： ALTER TABLE を使用して、アプリケーションに対して透過的に、いつでもシャード数を変更できます。

• 複数のストレージ形式: 列指向 (column)、行指向 (row)、およびハイブリッド (row,column) をサポートします。

• 制御されたデータ再分散： バックグラウンドでの自動的なデータ再分散か、より高速なメタデータの切り替えのために再分散をスキップするかを選択できます。

• パーティションウィンドウ制御： データ再分散を直近 N 日/月 のパーティションに限定し、I/O オーバーヘッドを削減します。

• 幅広い機能互換性： Dynamic Table、GSI、フルテキストインデックス、ベクターインデックス (HGraph)、タイムトラベル (MVCC)、Binlog、および論理パーティションテーブルと連携します。

典型的なユースケース

1. データ増加が初期のシャード見積もりを上回る： 16 シャードで開始し、6ヶ月後に 64 シャードにスケールします。

2. トラフィックイベントのための一時的なスケールアウト： セールイベントの前にシャードを追加してクエリ同時実行数を高め、イベント後にスケールインしてリソースを解放します。

3. ホット/コールドパーティション管理： ホットパーティションをスケールアウトしたまま、コールドな履歴パーティションをスケールインします。

4. エラスティックスケーリングによる AI ベクトル検索： リコールボリュームの増加に応じてベクターテーブルを動的にスケールします。インデックスは全体を通して利用可能なままです。

Liquid Table の作成

CREATE TABLE ステートメントに WITH (liquid_table = 'true') を追加します：

-- カラムナストレージ (デフォルト、OLAP ワークロード向け)
CREATE TABLE my_table (
    id   INT NOT NULL,
    name TEXT,
    ts   TIMESTAMPTZ,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true');

-- 行指向ストレージ (ポイントルックアップ/高頻度の更新向け)
CREATE TABLE my_row_table (
    id   INT NOT NULL,
    name TEXT,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true', orientation = 'row');

-- ハイブリッドストレージ (ポイントルックアップと OLAP の混合ワークロード向け)
CREATE TABLE my_hybrid_table (
    id   INT NOT NULL,
    name TEXT,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true', orientation = 'row,column');

シャード数の変更 (リシャーディング)

リシャーディングは、テーブルを別のテーブルグループに再割り当てして行います：

-- ターゲットのテーブルグループが存在しない場合は作成します
CALL hg_create_table_group('tg_64', 64);

-- スケールアウト (同期的に有効になります)
ALTER TABLE my_table SET (table_group = 'tg_64');

-- スケールイン
ALTER TABLE my_table SET (table_group = 'tg_16');

現在のシャード設定の確認

-- テーブルのテーブルグループとシャード数を確認します
SELECT property_key, property_value
FROM hologres.hg_table_properties
WHERE table_name = 'my_table'
AND property_key = 'table_group';

-- テーブルグループのメタデータを確認します
SELECT * FROM hologres.hg_table_group_properties
WHERE tablegroup_name = 'tg_64';

作成時のプロパティ

liquid_table_enable_data_reorganization の値の選択

パーティションウィンドウの例

-- 直近 30 日分のパーティションのみを再分散します (単一の時間型パーティションキーが必要です)
ALTER TABLE order_log SET (
    table_group = 'tg_64',
    liquid_table_reorganization_partition_window = '30 day'
);

これは、履歴のコールドパーティションにほとんどアクセスしない長期保持のログテーブルやファクトテーブルに最適です。再分散が必要なのはホットパーティションのみです。

互換性マトリクス (V4.2.0)

インデックス共存の例

-- フルテキストインデックス
CREATE INDEX ft_idx ON my_table USING FULLTEXT (content)
    WITH (tokenizer = 'jieba');

-- GSI (グローバルセカンダリインデックス)
CREATE GLOBAL INDEX gsi_name ON my_table(name) INCLUDE (ts);

-- ベクターインデックス (vectors プロパティ経由)
ALTER TABLE my_table SET (vectors = '{
    "embedding": {
        "algorithm": "HGraph",
        "distance_method": "Cosine"
    }
}');

Liquid Table にインデックスを作成した後、ALTER TABLE ... SET (table_group = '...') を使用して直接リシャーディングを実行できます。すべてのインデックスは、新しいシャードで自動的に使用可能な状態のままになります。

影響の概要

書き込みへの影響

1) 書き込みは失敗しない見込みですが、クライアントリトライを設定してください。メタデータの切り替え中、少数の同時リクエストで一時的なエラー (例: 接続タイムアウト) が発生する可能性があります。コネクタでは自動リトライを有効にしてください。長時間の書き込み不可は発生しません。

2) 書き込みレイテンシーは観測可能なスパイクが発生します。これは「影響ゼロ」ではありません。処理中の書き込みは、新しいトポロジーが有効になるまで待機する必要があります。スパイクは通常ミリ秒～秒の範囲ですが、次の場合にはより長くなることがあります。

• テーブル上で長時間実行されるトランザクションが存在する場合。

• インスタンスの I/O 使用率がすでに高い場合。

• スケーリングファクターが非常に大きい場合 (例: 8 シャードから 128 シャードへ直接スケールアウトする)。

3) 再配布フェーズ中、書き込みはブロックされませんが、レイテンシーがわずかに増加する可能性があります。

• バックグラウンドのデータ移行がインスタンスの I/O を消費し、フォアグラウンドの書き込みとリソースを競合する可能性があります。

• I/O 使用率が高いインスタンスでは、再配布中の書き込みレイテンシーが定常状態よりわずかに高くなる可能性があり、スループットもわずかに低下する可能性があります。

• 再配布フェーズ中は、インスタンスの I/O と書き込み RT メトリクスを継続的に監視することを推奨します。

4) COPY / バルクインポートのワークロード：リシャーディングと再配布が完全に完了してから、バルクインポートを開始してください。リシャーディング中に大量のインポートを行うと、再配布時間が大幅に延び、書き込みレイテンシーの変動も増幅します。

クエリへの影響

1) クエリは失敗せず、ブロックもされない見込みです。

• メタデータの切り替え中、新しいクエリは新しいトポロジーに対して実行されます。

• 処理中のクエリは通常どおり完了します。

• まれに、切り替えの瞬間に発行されたクエリが、ルートの再ルーティングによりタイムアウトする可能性があります。クライアントのリトライで対処してください。

2) 切り替えの瞬間における読み取りレイテンシーへの影響は通常は最小限ですが、ゼロではありません。

• 書き込みと比べると、読み取りパスは切り替えの影響を受けにくくなります。

• 切り替えのタイミングと重なったクエリでは、ルートの再ルーティングが発生します。レイテンシーに敏感なリアルタイム API では、ミリ秒レベルのジッターが観測される可能性があります。

• 高 QPS のポイントクエリシナリオでは、短時間のジッターが発生することを前提に、上流のタイムアウト設定を計画してください。

3) 古いデータに対するクエリパフォーマンスは、再配布が完了するまで大幅に低下する可能性があります。

4) 新しく書き込まれたデータに対するクエリは、ほとんど影響しません。

• 新しいデータは新しいシャードトポロジーに書き込まれるため、クエリパフォーマンスは定常状態と一致します。

• ただし、クエリが新旧両方のデータにまたがる場合 (例: 時間範囲スキャン)、全体の RT は古いデータ側のパフォーマンス低下に影響されます。

5) インデックスクエリ (GSI、フルテキスト、ベクター) は引き続き機能しますが、安定したパフォーマンスは期待できない場合があります。リシャーディング後もインデックスは利用できますが、インデックスルックアップの物理 I/O がバックグラウンドの再配布と競合し、再配布が完了するまで応答時間が増加する可能性があります。P99 とロングテールクエリを注意深く監視してください。

レイテンシーに敏感なワークロードに対する推奨事項

お使いのワークロードが次のいずれかに該当する場合は、リシャーディングをリスクの高い変更として扱い、変更管理プロセスに従ってください。

影響期間の目安（保守的）

結論

デフォルトの動作

Binlog が有効になっている Liquid Table は、デフォルトではリシャーディングが許可されていません。ALTER TABLE ... SET (table_group = ...) を直接実行すると、エラーが返されます。

強制リシャーディングプロシージャ

-- ステップ 1: 実験的な GUC を有効にします (セッションレベルのみ)
SET hg_experimental_enable_liquid_resharding_for_table_with_binlog = on;

-- ステップ 2: リシャーディングを実行します
ALTER TABLE my_binlog_table SET (table_group = 'tg_64');

-- ステップ 3: 古いシャード上のデルタデータをクリーンアップします
CALL hg_liquid_resharding_drop_non_current_delta('my_binlog_table');

Binlog コンシューマーへの影響

アプローチ 1： REBUILD による変換 (推奨)

Hologres V4.2 以降では、ASYNC REBUILD TABLE を使用して、既存のテーブルをその場で Liquid Table に再構築できます。新しいテーブルの作成や手動でのデータ移行が不要で、テーブル名も変更されません。REBUILD の詳細については、「REBUILD」をご参照ください。

-- 既存のテーブルをその場で Liquid Table に変換します (テーブル名は変更されません)
ASYNC REBUILD TABLE my_table
SET (
    liquid_table = 'true'
);

アプローチ 2：新しいテーブルへの移行

新しい Liquid Table を作成し、既存のテーブルからデータを移行し、アトミックなトランザクションリネームを使用して切り替えます。

-- 1. 同じスキーマで新しい Liquid Table を作成します
CREATE TABLE my_table_new (
    id   INT NOT NULL,
    name TEXT,
    ts   TIMESTAMPTZ,
    PRIMARY KEY(id)
) WITH (liquid_table = 'true');

-- 2. データをコピーします
INSERT INTO my_table_new SELECT * FROM my_table_old;

-- 3. インデックスを再作成します (存在する場合)
CREATE INDEX ... ON my_table_new ...;

-- 4. トランザクションを使用してアトミックにスワップします
BEGIN;
ALTER TABLE my_table_old RENAME TO my_table_bak;
ALTER TABLE my_table_new RENAME TO my_table;
COMMIT;

-- 5. 検証後にバックアップを削除します
DROP TABLE my_table_bak;

Liquid Table を有効化するタイミング

強く推奨：

• テーブルのライフサイクルを通じて、データ量が 5 倍以上に増加すると見込まれる場合。

• 季節的なトラフィックスパイクやセールイベントがあり、エラスティックシャードスケーリングが必要な場合。

• リアルタイムデータウェアハウスのコアファクトテーブル、またはワイドテーブル。

• AI ベクトル検索テーブル。

適用を延期できるケース：

• データ量が安定している小規模なディメンションテーブル。

• 物理パーティションテーブルに依存するワークロード。

• MaxCompute の直接読み取りに依存するワークロード。

シャード数の計画に関するガイドライン

リシャーディング実行時のヒント

1. オフピーク時間に実行：トラフィックが少ないメンテナンスウィンドウ中にALTERを実行してください。

2. 大規模 DML を静止：バルクINSERT/UPDATE/DELETEジョブが実行されていないことを確認してください。

3. 2 のべき乗の倍数を優先：例：16 → 32 → 64 は、16 → 50 よりもパフォーマンスが安定します。

4. 大規模テーブルではパーティションウィンドウを使用：長期間運用するパーティションテーブルでは、liquid_table_reorganization_partition_window を設定して再分散の範囲を制限してください。

5. Binlog テーブルをエンドツーエンドでリハーサル：ステージング環境で、リシャーディングとダウンストリームの再起動という一連のフローを事前にテストしてください。

監視に関する推奨事項

• 再分散が完了するまで：古いシャードと新しいシャードのクエリ応答時間を定期的に比較し、進捗を確認してください。

• インスタンスのリソース使用率：リシャーディングでは追加の I/O オーバーヘッドが発生します。CPU と I/O 使用率を監視してください。

• Binlog カーソルラグ：Binlog が有効なテーブルでは、ダウンストリームコンシューマーラグ を監視してください。