Einschränkungen des PostgreSQL-Connectors

Auf dieser Seite werden die Einschränkungen und Überlegungen für die Aufnahme von PostgreSQL mithilfe von Databricks Lakeflow Connect aufgeführt.

Allgemeine Einschränkungen des Datenbankkonnektors

Die Einschränkungen in diesem Abschnitt gelten für alle Datenbankkonnektoren in Lakeflow Connect. Lesen Sie weiter, um verbindungsspezifische Einschränkungen zu erfahren.

• Wenn Sie eine geplante Pipeline ausführen, werden Warnungen nicht sofort ausgelöst. Stattdessen werden sie ausgelöst, wenn das nächste Update ausgeführt wird.
• Wenn eine Quelltabelle gelöscht wird, wird die Zieltabelle nicht automatisch gelöscht. Sie müssen die Zieltabelle manuell löschen. Dieses Verhalten entspricht nicht dem Verhalten von Lakeflow Spark Declarative Pipelines.
• Während der Quellwartungszeiträume können Databricks möglicherweise nicht auf Ihre Daten zugreifen.
• Wenn ein Quelltabellenname mit einem vorhandenen Zieltabellennamen in Konflikt steht, schlägt die Pipelineaktualisierung fehl.
• Die Unterstützung für Multi-Destination-Pipelines erfolgt ausschließlich über die API.
• Sie können nach Belieben eine Tabelle umbenennen, die Sie importieren. Wenn Sie eine Tabelle in Ihrer Pipeline umbenennen, wird sie zu einer nur API-Pipeline, und Sie können die Pipeline nicht mehr in der Benutzeroberfläche bearbeiten.
• Wenn Sie eine Spalte auswählen, nachdem eine Pipeline bereits gestartet wurde, füllt der Verbinder die Daten für die neue Spalte nicht automatisch aus. Um historische Daten zu erfassen, führen Sie manuell eine vollständige Aktualisierung der Tabelle aus.
• Databricks können nicht zwei oder mehr Tabellen mit demselben Namen in derselben Pipeline aufnehmen, auch wenn sie aus verschiedenen Quellschemas stammen.
• Das Quellsystem geht davon aus, dass die Cursorspalten monoton steigen.

• Managed Ingestion Pipelines werden für Arbeitsbereiche in Azure GovCloud Regionen nicht unterstützt.

• Wenn SCD Typ 1 aktiviert ist, erzeugen Löschvorgänge kein explizites delete Ereignis im Änderungsdatenfeed. Verwenden Sie für überprüfbare Löschungen SCD-Typ 2, wenn der Connector ihn unterstützt. Ausführliche Informationen finden Sie unter Beispiel: SCD-Typ 1- und SCD-Typ 2-Verarbeitung mit CDF-Quelldaten.

• Der Connector unterstützt nur die Replikation von primären PostgreSQL-Instanzen.

Authentifizierung

• Der Connector unterstützt nur die Benutzernamen- und Kennwortauthentifizierung.

Datenbankvarianten

• Der Connector unterstützt PostgreSQL 13 oder höher.
• Der Connector unterstützt AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure-Datenbank für PostgreSQL, virtuelle Azure-Computer und GCP Cloud SQL für PostgreSQL. Der Connector unterstützt auch lokale PostgreSQL mit Azure ExpressRoute, AWS Direct Connect und VPN-Netzwerk.

Pipelines

• Jede Aufnahmepipeline muss genau einem Aufnahmegateway zugeordnet sein.
• Obwohl die Pipeline zum Einbinden von Daten auf Serverless-Compute ausgeführt wird, muss das Gateway zum Einbinden von Daten auf klassischem Compute ausgeführt werden.
• Das Aufnahmegateway muss im kontinuierlichen Modus ausgeführt werden, um zu verhindern, dass Write-Ahead Log (WAL) Aufblähung und Replikationsslot-Akkumulation auftreten.

Replikation

• Für die logische Replikation ist PostgreSQL 13 oder höher erforderlich, wobei der wal_level-Parameter auf logical gesetzt ist.

• Jede Tabelle, die Sie replizieren, muss die Replikatidentität auf FULL oder DEFAULT festgelegt haben. Databricks empfiehlt die Verwendung der FULL Replikatidentität für Tabellen ohne Primärschlüssel oder mit TOASTable-Spalten.
• Replikationsplätze werden nicht automatisch entfernt, wenn Sie Pipelines löschen. Sie müssen Replikationsplätze manuell bereinigen, um die WAL-Akkumulation zu verhindern. Siehe Replikations-Slots bereinigen.

Schemaentwicklung

Der Verbinder behandelt automatisch neue und gelöschte Spalten.

• Wenn eine neue Spalte in der Quelle angezeigt wird, nimmt Databricks sie automatisch in die nächste Pipelineausführung ein.
• Wenn eine Spalte aus der Quelle gelöscht wird, löscht Databricks sie nicht automatisch. Stattdessen verwendet der Verbinder eine Tabelleneigenschaft, um die gelöschte Spalte im Ziel auf inactive zu setzen. Wenn später eine weitere Spalte mit einem konfliktierenden Namen mit der inactive Spalte angezeigt wird, schlägt die Pipeline fehl. Führen Sie in diesem Fall eine vollständige Aktualisierung der Tabelle aus, oder legen Sie die inaktive Spalte manuell ab.

Der Connector kann die unten genannten DDLs (z. B. Spaltenumbenennungen) verarbeiten, erfordert jedoch eine vollständige Aktualisierung der Zieltabellen.

DDL erfordert vollständige Aktualisierung

• Ändern des Datentyps einer Spalte
• Umbenennen einer Spalte
• Ändern des Primärschlüssels einer Tabelle
• Konvertieren einer Tabelle von nicht protokolliert in protokolliert oder umgekehrt
• Hinzufügen oder Entfernen von Partitionen (für partitionierte Tabellen)

Staging

Der Stagingkatalog kann kein fremder Katalog sein.

Tabellen

• Databricks empfiehlt, maximal 250 Tabellen pro Pipeline zu erfassen. Es gibt jedoch keine Beschränkung für die Anzahl von Zeilen oder Spalten, die in diesen Tabellen unterstützt werden.
• Databricks kann keine zwei Tabellen verarbeiten, deren Namen sich nur in der Groß- und Kleinschreibung unterscheiden (z. B. mytable und MyTable), mit einer einzigen Pipeline. Um solche Fälle zu unterstützen, erstellen Sie zwei Gateway-Aufnahmepipeline-Paare, die in verschiedene Zielschemata veröffentlichen.
• Die source_catalog, source_schema und source_table Namen sind für den Datenbanknamen groß-/kleinschreibungssensitiv, aber für Schema- und Tabellennamen wird die Groß-/Kleinschreibung nicht beachtet (gemäß dem Standardverhalten von PostgreSQL). Wenn die Quelldatenbank z. B. MyDatabase benannt ist, müssen Sie sie als MyDatabase in der ingestion_definition angeben.
• Obwohl Sie aus mehreren Quelldatenbanken oder Schemas in einer Pipeline aufnehmen können, können Sie nicht zwei Tabellen mit demselben Namen aufnehmen. Sie können beispielsweise weder schema1.orders noch schema2.orders in derselben Pipeline aufnehmen.
• Sie können mehrere Tabellen- oder Schemaspezifikationen in das objects Feld der ingestion_definition. Die Quelltabellennamen in verschiedenen Quellschemas können sich jedoch nicht überlappen. Überlappende Namen führen zu Einem Ausfall der Aufnahmepipeline.

Datentypen

• Benutzerdefinierte Typen und Erweiterungstypen von Drittanbietern werden als Zeichenfolgen aufgenommen.
• Die Datentypen TIME und TIMETZ werden als Zeichenfolgen importiert.
• Jeder integrierte PostgreSQL-Datentyp, der nicht in der Tabelle "Automatische Datentransformationen" aufgeführt ist, wird als Zeichenfolge aufgenommen.
• Bei numerischem Datentyp: NaN wird in Null konvertiert.
• Für Datum und Zeitstempel: Bc-Datumsangaben oder -datumsangaben nach 9999AD werden nicht unterstützt.
• Infinity wird für Datum, Zeitstempel oder Intervall nicht unterstützt.

Partitionierte Tabellen

• PostgreSQL partitionierte Tabellen werden unterstützt.
• Jede Partition wird als separate Tabelle für Replikationszwecke behandelt.
• Zum Hinzufügen oder Entfernen von Partitionen ist eine vollständige Aktualisierung der Tabelle erforderlich.

Einschränkungen für bestimmte PostgreSQL-Variationen

Amazon RDS und Aurora

• Der rds.logical_replication Parameter muss auf 1.

Azure-Datenbank für PostgreSQL

• Die logische Replikation muss in den Serverparametern aktiviert sein.
• Für Einzelserver-Bereitstellungen ist die logische Replikation nur in den Ebenen "Allgemeiner Zweck" und "Arbeitsspeicheroptimiert" verfügbar.
• Für flexible Serverbereitstellungen wird die logische Replikation auf allen Ebenen unterstützt.
• Der max_wal_slot_keep_size parameter ist schreibgeschützt, auf -1 (unendlich) festgelegt und kann nicht konfiguriert werden.

Google Cloud SQL für PostgreSQL

• Das cloudsql.logical_decoding Flag muss aktiviert sein.
• Cloud SQL lässt die Konfiguration von max_wal_slot_keep_size nicht zu; sie ist standardmäßig auf -1 (unendlich) festgelegt.