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

PostgreSQLコネクタの制限

備考

プレビュー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • マネージド インジェスト パイプラインは、FedRAMP High または FedRAMP Moderate ワークスペースではサポートされていません。

  • コネクタは、変換せずに生データを取り込みます。変換にはダウンストリームの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データ型は文字列として取り込まれます。

  • NUMERICおよびDECIMALデータ型の場合：

    • 精度が38以下の場合、 NaNはnullにマッピングされます。
    • 精度が38より大きい場合、値は文字列として格納され、 NaN文字列として保持されます。
    • Inf および-Inf 、無制限の数値型でのみサポートされます。精度が38を超える場合、値は文字列として格納され、無限大の値は保持されます。

  • DATEデータ型の場合：PostgreSQLの日付範囲全体がサポートされています。Infと-Infはnullに変換されます。紀元前（BC）の日付は、天文学的な年号を用いて記録されます。例えば、紀元前1年は紀元0年に相当し、紀元前2年は紀元前-1年に相当します。

  • TIMESTAMP (タイムゾーンなし) データ型の場合: 値は文字列として取り込まれます。Infと-Infは文字列として保存されます。

  • TIMESTAMP WITH TIME ZONEデータ型の場合：PostgreSQLでサポートされている範囲は4713-01-01 00:00:00.000000 BCから294276-12-31 23:59:59.999999 ADですが、Databricksでサポートされている範囲は-290308-12-21 BCE 19:59:06 GMTから+294247-01-10 CE 04:00:54 GMTです。Databricksがサポートする最大タイムスタンプを超えるタイムスタンプはnullに変換されます。紀元前（BC）の日付は、天文学的な年号を用いて記録されます。例えば、紀元前1年は0年に、紀元前2年は-1年にマッピングされます。 Infと-Infはnullに変換されます。

  • INTERVALデータ型の場合：無限大の値は0 years 0 mins 0 days 0 hours 0 mins 0.0 secsにマッピングされます。

  • MONEY 値は文字列として取り込まれます。

  • 自動データ変換テーブルにリストされていない PostgreSQL 組み込みデータ型は、文字列として取り込まれます。

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

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

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

Amazon RDS と Aurora​

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

PostgreSQL 用 Azure データベース​

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

PostgreSQL用 Google クラウドSQL​

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