Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

PostgreSQL データベースからデータをストリーミングする

このセクションには、次に関する情報が含まれています。

Datastream が移行元 PostgreSQL データベースから pull されているデータを処理する方法の動作
Datastream でサポートされている PostgreSQL データベースのバージョン
データが移行先にストリーミングできるように移行元 PostgreSQL データベースを設定する方法の概要
PostgreSQL データベースを移行元として使用する場合の既知の制限事項

動作

移行元の PostgreSQL データベースは論理デコーディング機能に依存しています。論理デコーディングでは、データベースにコミットされたすべての変更が公開され、出力プラグインを使用してこれらの変更をユーザーフレンドリーな形式で使用、処理できます。Datastream は、PostgreSQL 10 以降の標準の PostgreSQL 論理デコーディングプラグインである pgoutput プラグインを使用します。

特定の PostgreSQL 移行元からのすべてのスキーマまたは特定のスキーマ、およびスキーマや特定のテーブルのすべてのテーブルを選択できます。
履歴データはすべて複製されます。
指定したデータベースとテーブルからの挿入、更新、削除など、すべてのデータ操作言語（DML）の変更が複製されます。
commit された変更のみが複製されます。
テーブルに REPLICA IDENTITY を定義すると、Datastream は指定された列を主キーとして扱います。
Datastream は、プライマリインスタンスに接続されている場合、移行元データベースに定期的にハートビートメッセージを送信します。その結果、論理デコーディングメッセージイベント（op:"m"）が WAL ファイルに直接挿入されます。これらのメッセージは、移行元の可用性を確保し、鮮度を計算するために Datastream で必要となります。リードレプリカを移行元として使用する場合は、ハートビートメッセージを外部で構成する必要があります。詳細については、リードレプリカからのレプリケーションをご覧ください。他のレプリケーション設定が同じ移行元データベースから読み取る場合は、この点を考慮することをおすすめします。

バージョン

Datastream は PostgreSQL バージョン 10 以降をサポートしています。

Datastream は、次の種類の PostgreSQL データベースをサポートしています。

セルフホストの PostgreSQL
Cloud SQL for PostgreSQL
AlloyDB for PostgreSQL
AlloyDB Omni
Amazon RDS for PostgreSQL
Amazon Aurora PostgreSQL

無料枠

Datastream を使用すると、無料枠を使用して AlloyDB for PostgreSQL から BigQuery にストリーミングできます。毎月最大 100 GiB の変更データキャプチャデータを無料で利用できます。詳細については、 Datastream の料金をご覧ください。

ベストプラクティス

このセクションでは、Datastream で使用する PostgreSQL 移行元を構成する際の推奨されるベストプラクティスについて説明します。

複数のストリームを使用してヘッドオブラインブロッキングを防ぐ

PostgreSQL 移行元の場合、Datastream はストリーム全体に対して 1 つの論理レプリケーションスロットを使用します。1 つの大量のテーブルで大規模なトランザクションや複数の更新が行われると、同じストリーム内の他のすべてのテーブルのデータレプリケーションが遅延する可能性があります。

ヘッドオブラインブロッキングを防ぐには、テーブルのセットごとに個別のストリームを作成します。たとえば、大量のテーブル用に 1 つのストリームを作成し、少量のテーブル用にもう 1 つのストリームを作成できます。これにより、チャーン率の高いテーブルが分離され、他のテーブルのレプリケーションが遅延するのを防ぐことができます。

推奨事項: 書き込み（INSERT/UPDATE/DELETE）レートが非常に高いテーブルを特定し、個別のレプリケーションスロットを使用して、専用の Datastream ストリームに配置します。

長時間実行されるトランザクションを避ける

長時間実行されるトランザクションにより、WAL ログが蓄積される可能性があります。WAL はシーケンシャルであるため、PostgreSQL は、長時間実行されるトランザクションが完了するまで、レプリケーションスロットに必要な古い WAL ファイルを削除できません。これにより、WAL ディスクの使用量が増加します。

また、論理デコーディングが遅くなる可能性があります。この遅延は、大規模なトランザクションによって変更がディスクに書き込まれることが原因です。これにより、commit 時に低速で I/O を多用する再アセンブリが必要となり、後続のすべてのトランザクションのレプリケーションがブロックされます。 推奨事項: 移行元データベースで、長時間実行されるトランザクションを回避するように statement_timeout パラメータと idle_in_transaction_session_timeout パラメータを構成します。詳細については、 PostgreSQL のドキュメントをご覧ください。

パブリケーションを作成するときにテーブルフィルタを使用する

少数のテーブルからのみ変更を複製する場合は、それらのテーブルのみを含む PUBLICATION を作成してください。パブリケーションのスコープが特定のテーブルに設定されている場合、PostgreSQL は、それらのテーブルの変更のみをレプリケーションスロットに効率的に保持します。これにより、レプリケーションスロットのサイズが縮小され、論理デコーディングのパフォーマンスが向上します。

レプリケーションスロットをプロアクティブに管理する

Datastream は、PostgreSQL プライマリインスタンスで論理レプリケーションスロットを使用します。これにより、WAL ファイルは Datastream が処理されたことを確認するまで保持されます。レプリケーションスロットを削除せずにストリームが失敗、一時停止、削除された場合、PostgreSQL は WAL ファイルを無期限に保持し続けます。これにより、データベースサーバーのディスクがいっぱいになり、本番環境で停止が発生する可能性があります。

推奨事項: 効率的なアラートを設定し、移行元 PostgreSQL サーバーの WAL ディスク使用量をモニタリングします。

レプリカ ID を正しく構成する

REPLICA IDENTITY 設定は、UPDATE イベントと DELETE イベントの WAL に書き込むデータを PostgreSQL に指示します。これにより、Datastream は変更された行を特定できます。

BigQuery を移行先として使用する場合は、REPLICA IDENTITY を FULL に設定しないでください。Datastream は、ログに記録された列を BigQuery MERGE オペレーションの論理キーとして使用します。 REPLICA IDENTITY が FULL に設定されていて、テーブルに 17 個以上の列がある場合、MERGE オペレーションの主キーの BigQuery の 16 列の制限を超えるため、ストリームが中断されます。

推奨事項 （優先順）:

最適: 主キーを使用します。REPLICA IDENTITY DEFAULT のデフォルト設定では、既存の主キーが自動的かつ効率的に使用されます。
良好: 主キーが存在しない場合は、UNIQUE NOT NULL インデックスを作成し、REPLICA IDENTITY USING INDEX INDEX_NAME を設定します。
推奨度が低い: 一意の識別子がないテーブルでのみ REPLICA IDENTITY FULL 設定を使用します。BigQuery にレプリケートする場合は、パフォーマンスへの影響、16 列の制限、主キーでサポートされているデータ型の制限に注意してください。

リードレプリカからのレプリケーション

Datastream は、PostgreSQL バージョン 16 以降の PostgreSQL リードレプリカインスタンスからのレプリケーションをサポートしています。

リードレプリカからレプリケートするには、プライマリインスタンスで次の設定手順を行う必要があります。

プライマリインスタンスでパブリケーションを作成する: Datastream がリードレプリカに接続している間、レプリケートするデータを定義するパブリケーションはプライマリインスタンスで作成する必要があります。
WAL ハートビートを構成する: Datastream は、チェックポイントメカニズムに定期的な WAL ハートビートメッセージを使用します。プライマリインスタンスに接続する場合、Datastream はこれらのハートビートの生成を処理します。ただし、リードレプリカの場合、これらのハートビートは外部で生成する必要があります。

定期的なハートビートを設定する方法の 1 つは、pg_cron 拡張機能を使用して PostgreSQL に cron タスクを作成することです。

SELECT cron.schedule_in_database(
    'datastream-heartbeat',             -- Job name
    '* * * * *',                        -- Every minute
   $$SELECT pg_logical_emit_message(true, 'datastream', 'cdc heartbeat')$$,
    'DATABASE_NAME',              -- Change this to your database name
    'USERNAME',                   -- Username to run as
    true                                -- Enabled
);

次のように置き換えます。

DATABASE_NAME: ハートビートを生成するデータベースの名前。
USERNAME: タスクを実行するユーザーの名前。通常は postgres。

既知の制限事項

PostgreSQL データベースを移行元として Datastream を使用する場合の既知の制限事項は次のとおりです。

ストリームは 10,000 テーブルに制限されています。
次の条件が満たされない限り、5 億行を超えるテーブルはバックフィルできません。
1. テーブルには一意の B-tree インデックスがある。
2. インデックスには、次の型の列は含まれません: DOUBLE、FLOAT、MONEY、REAL、JSON、JSONB、BYTEA、TXID、XML、複合データ型またはジオメトリデータ型。
3. インデックスのどの列も null 値を許容できません。
4. インデックスのすべての列が昇順、またはインデックスのすべての列が降順になります。
5. インデックスのすべての列がストリームに含まれる。
主キーのないテーブルには REPLICA IDENTITY が必要です。それ以外の場合、INSERT イベントのみが移行先に複製されます。
主キーを持つテーブルでは、REPLICA IDENTITY を FULL または NOTHING に設定できません。DEFAULT に設定する必要があります。
移行元のスキーマに対するすべての変更を自動的に検出できない場合があります。その場合、データが破損する可能性があります。次のスキーマの変更により、データが破損したり、イベントのダウンストリームが処理されなかったりする可能性があります。
- 列をドロップする。
- テーブルの中央に列を追加する。
- 列のデータ型を変更する。
- 列を並べ替える。
- テーブルをドロップする（新しいデータを追加して同じテーブルを再作成する場合に関連）。
Datastream は、geometric データ型の列をサポートしていません。
Datastream は、range データ型の列をサポートしていません。
Datastream は、サポートされていないデータ型の配列、ユーザー定義のデータ型（ENUM など）の配列、または DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONE データ型の配列をサポートしていません。このような列は無視されます。
2026 年 2 月 17 日より前に作成されたストリームの場合: Datastream は、テーブルのレプリカ ID の一部である列に TOAST 値が含まれている行の UPDATE イベントの複製をサポートしていません。このようなイベントは破棄されます。この日付以降に作成されたストリームには、この例外は適用されません。
Datastream は、2,950 個を超えるネストされたオブジェクトを含む JSON 値または JSONB 値を含む行の複製をサポートしていません。このような JSON 値や JSONB 値を含むイベントは、移行先データベースに複製されません。
Datastream は、NUMERIC (precision, scale) 列に NaN 値を含む行の複製をサポートしていません。このような列の値は NULL 値に置き換えられます。
Datastream は、hstore データ型の列の複製をサポートしていません。このような列の値は NULL 値に置き換えられます。
Datastream は、SQL_ASCII でエンコードされた移行元データベースからの非 ASCII レコードの複製をサポートしていません。このようなレコードは破棄されます。
Datastream は、行レベルのセキュリティ（RLS）ポリシーが定義されているテーブルの複製をサポートしていません。この制限を回避する方法については、PostgreSQL の移行元の動作と制限事項をご覧ください。
The Oversized-Attribute Storage Technique（TOAST）を使用する可変長データ型の列をストリーミングする場合、変更されていない TOAST 値が UPDATE オペレーション中に WAL ログから削除されると、Datastream は移行元データベースにクエリを実行して、欠損値をポイントインタイムで取得する必要があります（補完と呼ばれるアクティブなルックアッププロセス）。Datastream はデータベースにクエリを実行してこれらの列をストリーミングするため、連続する更新や挿入後の迅速な削除など、迅速な更新を伴うシナリオでは、中間変更がキャプチャされない可能性があります。DELETE オペレーションでは補完はトリガーされません。この制限は、すべての中間変更がキャプチャされることを想定している追記専用書き込みモードを使用する場合に特に重要です。
Datastream は、生成された列に対する変更をキャプチャしません。
データベースで PostgreSQL のメジャーバージョンアップグレードが実行されると、Datastream が動作を停止したり、新しいイベントをキャプチャしなくなったりする可能性があります。アップグレードの前にレプリケーションスロットを削除し、データベースをアップグレードしてから、レプリケーションスロットを再作成することをおすすめします。ストリームが失敗した場合は、新しいレプリケーションスロット名を指定してストリームを復元し、データの整合性が必要な場合はバックフィルを実行します。
自動ストリーム設定フローを使用する場合、Datastream は PostgreSQL システムテーブルの複製をサポートしていません。自動フローを使用して作成したストリームを編集してシステムテーブルを追加すると、Datastream はこれらのテーブルを無視し、これらのテーブルからデータや変更を複製しません。

次のステップ

Datastream で使用する PostgreSQL 移行元を構成する方法を学習する。

PostgreSQL データベースからデータをストリーミングする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

動作