メインコンテンツまでスキップ
に最終更新

PostgreSQLコネクタの制限

備考

プレビュー

LakeFlow ConnectのPostgreSQLコネクタはパブリック プレビュー段階です。 パブリック プレビューに登録するには、Databricks アカウント チームにお問い合わせください。

このページでは、 Databricks LakeFlow Connectを使用したPostgreSQL取り込みに関する制限事項と考慮事項を示します。

一般的なデータベースコネクタの制限​

このセクションの制限は、 Lakeflowコネクトのすべてのデータベースコネクタに適用されます。 コネクタ固有の制限事項については、引き続きお読みください。

  • スケジュールされたパイプラインを実行しても、アラートはすぐにはトリガーされません。代わりに、次の更新が実行されたときにトリガーされます。

  • ソース テーブルを削除しても、宛先テーブルは自動的に削除されません。宛先テーブルを手動で削除する必要があります。この動作は、 Lakeflow Spark宣言型パイプラインの動作と一致しません。

  • ソースメンテナンス期間中、Databricks はデータにアクセスできない可能性があります。

  • ソース テーブル名が既存の宛先テーブル名と競合する場合、パイプラインの更新は失敗します。

  • 複数の宛先パイプラインのサポートは API のみです。

  • オプションで、取り込むテーブルの名前を変更できます。パイプライン内のテーブルの名前を変更すると、そのパイプラインは API 専用となり、UI でパイプラインを編集できなくなります。

  • パイプラインが既に開始された後に列を選択した場合、コネクタは新しい列のデータを自動的にバックフィルしません。履歴データを取り込むには、テーブルで完全な更新を手動で実行します。

  • Databricks は、異なるソース スキーマからのものである場合でも、同じパイプラインに同じ名前を持つ 2 つ以上のテーブルを取り込むことはできません。

  • ソース システムは、カーソル列が単調に増加すると想定します。

  • マネージド インジェスチョン パイプラインは、AWS GovCloud リージョン (FedRAMP High) のワークスペースではサポートされていません。

  • マネージド インジェスト パイプラインは、 us-east-2またはus-west-1リージョンの FedRAMP Moderate ワークスペースではサポートされていません。

  • SCDタイプ 1 が有効になっている場合、削除によって変更データフィードに明示的なdeleteイベントが生成されません。 監査可能な削除の場合、コネクタがサポートしている場合は SCD タイプ 2 を使用します。詳細については、 「例: CDF ソース データを使用した SCD タイプ 1 および SCD タイプ 2 の処理」を参照してください。

  • コネクタは、変換せずに生データを取り込みます。変換にはダウンストリームのLakeFlow Spark宣言型パイプライン パイプラインを使用します。

  • コネクタはプライマリ PostgreSQL インスタンスからのレプリケーションのみをサポートします。

認証​

  • コネクタはユーザー名とパスワードの認証のみをサポートします。

データベースのバリエーション​

  • コネクタは PostgreSQL 13 以上をサポートしています。
  • コネクタは、 AWS RDS PostgreSQL 、Aurora PostgreSQL 、 Amazon EC2 、 Azure Database for PostgreSQL 、 Azure仮想マシン、 GCPクラウドSQL for PostgreSQLをサポートしています。 このコネクタは、Azure ExpressRoute、AWS Direct Connect、VPN ネットワークを使用したオンプレミスの PostgreSQL もサポートします。

パイプライン​

  • 各取り込みパイプラインは、正確に 1 つの取り込みゲートウェイに関連付ける必要があります。
  • インジェスト パイプラインはサーバレス コンピュートで実行されますが、インジェスト ゲートウェイはクラシック コンピュートで実行する必要があります。
  • 先行書き込みログ (WAL) の膨張とレプリケーション スロットの蓄積を防ぐには、インジェスト ゲートウェイを連続モードで実行する必要があります。

レプリケーション​

  • AWS RDS と Aurora の場合は、 rds.logical_replicationを1に設定します。

  • 複製する各テーブルのレプリカ ID はFULLまたはDEFAULTに設定されている必要があります。Databricks では、主キーのないテーブルや TOASTable 列のあるテーブルにはFULLレプリカ ID を使用することをお勧めします。

  • パイプラインを削除しても、レプリケーション スロットは自動的に削除されません。WAL の蓄積を防ぐには、レプリケーション スロットを手動でクリーンアップする必要があります。「レプリケーション スロットのクリーンアップ」を参照してください。

スキーマの進化​

コネクタは新しい列と削除された列を自動的に処理します。

  • ソースに新しい列が表示されると、Databricks は次のパイプライン実行時にそれを自動的に取り込みます。
  • 列がソースから削除されても、Databricks はそれを自動的に削除しません。代わりに、コネクタはテーブル プロパティを使用して、削除された列を宛先のinactiveに設定します。後でinactive列と名前が競合する別の列が現れた場合、パイプラインは失敗します。この場合は、テーブルを完全に更新するか、非アクティブな列を手動で削除してください。

コネクタは、下記の DDL (列名の変更など) を処理できますが、ターゲット テーブルを完全に更新する必要があります。

完全な更新が必要な DDL​

  • 列のデータ型の変更
  • 列の名前を変更する
  • テーブルの主キーの変更
  • テーブルをログなしからログありへ、またはその逆に変換する
  • パーティションの追加または削除（パーティションテーブルの場合）

ステージング​

ステージング カタログをフォーリンカタログにすることはできません。

テーブル​

  • Databricks では、パイプラインごとに 250 個以下のテーブルを取り込むことを推奨しています。ただし、これらのテーブル内でサポートされる行または列の数に制限はありません。
  • Databricks は、大文字と小文字のみが異なる名前を持つ 2 つのテーブル (たとえば、 mytableとMyTable ) を 1 つのパイプラインで取り込むことはできません。このようなケースをサポートするには、異なるターゲット スキーマに公開する 2 つのゲートウェイ インジェスト パイプライン ペアを作成します。
  • source_catalog 、 source_schema 、およびsource_table名前は、データベース名の場合は大文字と小文字が区別されますが、スキーマ名とテーブル名の場合は大文字と小文字は区別されません (PostgreSQL のデフォルトの動作に従います)。たとえば、ソース データベースの名前がMyDatabaseの場合、 ingestion_definitionではそれをMyDatabaseとして指定する必要があります。
  • 1 つのパイプラインで複数のソース データベースまたはスキーマから取り込むことはできますが、同じ名前の 2 つのテーブルを取り込むことはできません。たとえば、同じパイプラインにschema1.ordersとschema2.ordersの両方を取り込むことはできません。
  • ingestion_definitionのobjectsフィールドには、複数のテーブルまたはスキーマの仕様を含めることができます。ただし、異なるソース スキーマ内のソース テーブル名は重複できません。名前が重複すると、取り込みパイプラインが失敗します。

データ型​

  • ユーザー定義型とサードパーティの拡張型は文字列として取り込まれます。
  • TIMEおよびTIMETZデータ型は文字列として取り込まれます。
  • 自動データ変換テーブルにリストされていない PostgreSQL 組み込みデータ型は、文字列として取り込まれます。
  • 数値データ型の場合: NaN は null に変換されます。
  • 日付とタイムスタンプの場合: 紀元前の日付または西暦 9999 年以降の日付はサポートされていません。
  • 日付、タイムスタンプ、間隔では無限大はサポートされていません。

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

  • PostgreSQL パーティション テーブルがサポートされています。
  • 各パーティションは、レプリケーションの目的で個別のテーブルとして扱われます。
  • パーティションを追加または削除するには、テーブルを完全に更新する必要があります。

特定のPostgreSQLバリエーションにおける制限​

Amazon RDS と Aurora​

  • rds.logical_replication問題は1に設定する必要があります。

PostgreSQL 用 Azure データベース​

  • 論理レプリケーションがサーバーで有効になっている必要があります。
  • 単一サーバー展開の場合、論理レプリケーションは、汎用層とメモリ最適化層でのみ使用できます。
  • フレキシブル サーバーの展開では、すべての層で論理レプリケーションがサポートされます。
  • m ax_wal_slot_keep_size parameterは読み取り専用で、-1 (無限大) に固定されており、構成できません。

PostgreSQL用 Google クラウドSQL​

  • cloudsql.logical_decodingフラグを有効にする必要があります。
  • SQLクラウドでは max_wal_slot_keep_size を構成できません。デフォルトでは -1 (無限大) に固定されています。