Limitaciones del conector de PostgreSQL

En esta página se enumeran las limitaciones y consideraciones para la ingesta de PostgreSQL mediante Databricks Lakeflow Connect.

Limitaciones generales del conector de base de datos

Las limitaciones de esta sección se aplican a todos los conectores de base de datos de Lakeflow Connect. Siga leyendo las limitaciones específicas del conector.

• Al ejecutar una canalización programada, las alertas no se activan inmediatamente. En su lugar, se desencadenan cuando se ejecuta la siguiente actualización.
• Cuando se elimina una tabla de origen, la tabla de destino no se elimina automáticamente. Debe eliminar manualmente la tabla de destino. Este comportamiento no es coherente con el comportamiento de las canalizaciones declarativas de Spark de Lakeflow.
• Durante los períodos de mantenimiento de origen, Es posible que Databricks no pueda acceder a los datos.
• Si un nombre de tabla de origen entra en conflicto con un nombre de tabla de destino existente, se produce un error en la actualización de la canalización.
• La compatibilidad con la canalización de varios destinos es solo API.
• Opcionalmente, puede cambiar el nombre de una tabla que ingiere. Si cambia el nombre de una tabla de la canalización, se convierte en una canalización solo de API y ya no puede editar la canalización en la interfaz de usuario.
• Si selecciona una columna después de que ya se haya iniciado una canalización, el conector no rellena automáticamente los datos de la nueva columna. Para ingerir datos históricos, ejecute manualmente una actualización completa en la tabla.
• Databricks no puede ingerir dos o más tablas con el mismo nombre en la misma canalización, incluso si proceden de esquemas de origen diferentes.
• El sistema de origen supone que las columnas de cursor están aumentando de forma monotónica.

• Las canalizaciones de ingesta administradas no se admiten para áreas de trabajo en las regiones de Azure GovCloud.

• Cuando el tipo SCD 1 está habilitado, las eliminaciones no generan un evento explícito delete en el flujo de datos de cambios. Para las eliminaciones auditables, use el tipo SCD 2 si el conector lo admite. Para obtener más información, vea Ejemplo: procesamiento de tipo 1 y SCD tipo 2 con datos de origen de CDF.

• El conector solo admite la replicación desde instancias principales de PostgreSQL.

Autenticación

• El conector solo admite la autenticación de nombre de usuario y contraseña.

Variaciones de base de datos

• El conector admite PostgreSQL 13 o superior.
• El conector admite AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database for PostgreSQL, máquinas virtuales de Azure y GCP Cloud SQL for PostgreSQL. El conector también admite PostgreSQL local mediante Azure ExpressRoute, AWS Direct Connect y redes VPN.

Tuberías

• Cada canalización de ingesta debe estar asociada exactamente a una puerta de enlace de ingesta.
• Aunque la canalización de ingesta se ejecuta en computación sin servidor, la puerta de enlace de ingesta debe ejecutarse en computación clásica.
• La puerta de enlace de ingesta debe ejecutarse en modo continuo para evitar el inflado del registro de escritura anticipada (WAL) y la acumulación de ranuras de replicación.

Replication

• La replicación lógica requiere PostgreSQL 13 o superior con el parámetro wal_level establecido en logical.

• Cada tabla que replique debe tener su identidad de réplica establecida en FULL o DEFAULT. Databricks recomienda usar la identidad de réplica FULL para tablas sin claves principales o con columnas TOASTable.
• Las ranuras de replicación no se eliminan automáticamente cuando se eliminan las canalizaciones. Debe limpiar manualmente las ranuras de replicación para evitar la acumulación de WAL. Consulte Limpiar ranuras de replicación.

Evolución del esquema

El conector controla automáticamente las columnas nuevas y eliminadas.

• Cuando aparece una nueva columna en el origen, Databricks la incorpora automáticamente en la siguiente ejecución del flujo de trabajo.
• Cuando se elimina una columna del origen, Databricks no la elimina automáticamente. En su lugar, el conector usa una propiedad de tabla para establecer la columna eliminada en inactive en el destino. Si más adelante aparece otra columna que tiene un nombre en conflicto con la columna inactive, la canalización falla. En este caso, ejecute una actualización completa de la tabla o quite manualmente la columna inactiva.

El conector puede controlar las DDL mencionadas a continuación (por ejemplo, el cambio de nombre de columna), pero requiere una actualización completa de las tablas de destino.

DDL requiere una actualización completa

• Cambio del tipo de datos de una columna
• Cambiar el nombre de una columna
• Cambio de la clave principal de una tabla
• Convertir una tabla de no registrada a registrada o viceversa
• Agregar o quitar particiones (para tablas con particiones)

Staging

El catálogo de ensayo no puede ser un catálogo externo.

Tables

• Databricks recomienda ingerir 250 o menos tablas por canalización. Sin embargo, no hay ningún límite en el número de filas o columnas que se admiten en estas tablas.
• Databricks no puede ingerir dos tablas cuyos nombres solo difieren en el caso (por ejemplo, mytable y MyTable) mediante una canalización. Para admitir estos casos, cree dos pares de canalizaciones de ingestión y puerta de enlace que publiquen en diferentes esquemas de destino.
• Los nombres source_catalog, source_schema y source_table distinguen entre mayúsculas y minúsculas para el nombre de la base de datos, pero no distinguen entre mayúsculas y minúsculas para los nombres de esquemas y tablas (siguiendo el comportamiento predeterminado de PostgreSQL). Por ejemplo, si la base de datos de origen se denomina MyDatabase, debe especificarla como MyDatabase en .ingestion_definition
• Aunque puede cargar datos desde varias bases de datos de origen o esquemas en una misma canalización, no puede cargar dos tablas con el mismo nombre. Por ejemplo, no puede ingerir ni schema1.orders, ni schema2.orders en la misma canalización.
• Puede incluir varias especificaciones de tabla o esquema en el objects campo de ingestion_definition. Sin embargo, los nombres de tabla de origen en esquemas de origen diferentes no se pueden superponer. Los nombres superpuestos causan un fallo en la tubería de ingesta.

Tipos de datos

• Los tipos definidos por el usuario y los tipos de extensión de terceros se ingieren como cadenas.
• Los tipos de datos TIME y TIMETZ se ingieren como cadenas.
• Cualquier tipo de datos integrado de PostgreSQL que no aparezca en la tabla Transformaciones automáticas de datos se ingiere como cadena.
• Para el tipo de datos numérico: NaN se convierte en NULL.
• No se admiten fechas a.C. ni fechas posteriores al 9999 d.C. para la fecha y la marca de tiempo.
• Infinity no está soportado para las fechas, las marcas de tiempo o los intervalos.

Tablas con particiones

• Se admiten tablas con particiones de PostgreSQL.
• Cada partición se trata como una tabla independiente con fines de replicación.
• La adición o eliminación de particiones requiere una actualización completa de la tabla.

Limitaciones para variaciones específicas de PostgreSQL

Amazon RDS y Aurora

• El rds.logical_replication parámetro debe establecerse en 1.

Base de Datos de Azure para PostgreSQL

• La replicación lógica debe estar habilitada en los parámetros del servidor.
• En el caso de las implementaciones de servidor único, la replicación lógica solo está disponible en los niveles Uso general y Optimizado para memoria.
• En el caso de las implementaciones de servidor flexible, la replicación lógica se admite en todos los niveles.
• ax_wal_slot_keep_size parameter M es de solo lectura, se fija en -1 (infinito) y no se puede configurar.

Google Cloud SQL para PostgreSQL

• La cloudsql.logical_decoding marca debe estar habilitada.
• Cloud SQL no permite configurar max_wal_slot_keep_size; se fija en -1 (infinito) de forma predeterminada.