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 desencadenan 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 las canalizaciones declarativas de Spark en el comportamiento de Lakeflow.
• El catálogo de ensayo no puede ser un catálogo externo.
• 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.
• El conector ingiere datos sin procesar sin transformaciones. Utilice las canalizaciones declarativas de Spark en Lakeflow en la fase posterior para las transformaciones.

• 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. Para más información sobre la conectividad entre nubes, consulte Conectividad de red.

Tuberías

• Cada canalización de ingesta debe estar asociada exactamente a una puerta de enlace de ingesta. Las pasarelas no se pueden compartir entre canalizaciones.
• 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 crecimiento excesivo 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 que se puedan almacenar mediante 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.
• El conector usa la posición de la ranura de replicación para realizar puntos de control. Si el nodo principal de PostgreSQL se degrada o reemplaza (por ejemplo, durante una conmutación por error), se pierde la información del espacio de replicación. Esto produce un error de ranura no encontrado que requiere una actualización completa de todas las tablas de la canalización. No se admite la conexión a otro nodo de origen.

Evolución del esquema

Los comportamientos descritos en esta sección solo se aplican si habilita el DDL en línea. Cuando el DDL en línea está deshabilitado, el conector sigue detectando cambios en el esquema, pero las tablas afectadas requieren una actualización total. Para habilitar el DDL en línea, consulte Opcional: Configurar el seguimiento de DDL en línea.

Cuando el DDL en línea está activado, el conector se encarga automáticamente de las columnas nuevas y eliminadas.

• Cuando aparece una columna nueva en el origen, el conector la ingiere automáticamente en la siguiente ejecución de la canalización.
• Al eliminar una columna del origen, el conector no lo elimina automáticamente. En su lugar, el conector usa una propiedad de tabla para establecer en inactive la columna eliminada en el destino. Si más adelante aparece otra columna con un nombre que entra 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 siguientes DDL, pero requiere una actualización completa de las tablas de destino.

DDL que requieren 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 uso de mayúsculas y minúsculas (por ejemplo, mytable y MyTable) con una sola canalización. Para admitir estos casos, cree dos pares de puerta de enlace y canalización de ingesta que publiquen en esquemas de destino diferentes.
• 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.
• Para los tipos de datos NUMERIC y DECIMAL
  • Si la precisión es 38 o menos, NaN se asigna a null.
  • Si la precisión es mayor que 38, el valor se almacena como una cadena y NaN se conserva como una cadena.
  • Inf y -Inf solo se admiten para tipos numéricos sin enlazar. Para una precisión mayor que 38, el valor se almacena como una cadena y se conserva el valor infinito.
• Para el tipo de datos DATE: se admite el intervalo de fechas completo de PostgreSQL. Inf y -Inf se convierten en null. Las fechas a.C. se almacenan mediante la numeración del año astronómico. Por ejemplo, 1 a.C. corresponde al año 0 y 2 a.C. corresponde a -1.
• Tipo de datos para TIMESTAMP (sin zona horaria): los valores se ingieren como cadenas. Inf y -Inf se conservan como cadenas.
• Para TIMESTAMP WITH TIME ZONE el tipo de datos: el intervalo de PostgreSQL admitido es 4713-01-01 00:00:00.000000 BC para 294276-12-31 23:59:59.999999 AD, mientras que el intervalo admitido por Databricks es -290308-12-21 BCE 19:59:06 GMT para +294247-01-10 CE 04:00:54 GMT. Las marcas de tiempo anteriores a la marca de tiempo máxima admitida de Databricks se convierten en null. Las fechas a.C. se almacenan mediante la numeración del año astronómico. Por ejemplo, 1 a.C. corresponde al año 0 y 2 a.C. corresponde a -1. Inf y -Inf se convierten en null.
• Para el tipo de dato INTERVAL: los valores de infinito se asignan a 0 years 0 mins 0 days 0 hours 0 mins 0.0 secs.
• MONEY los valores se ingieren como cadenas.
• Las columnas binarias (por ejemplo, BYTEA) no se pueden usar como claves de agrupación en clústeres.
• Cualquier tipo de datos integrado de PostgreSQL que no aparezca en la tabla Transformaciones automáticas de datos se ingiere como cadena.

Tablas particionadas

• 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.
• El max_slot_wal_keep_size parámetro 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.
• Sql en la nube no permite configurar max_slot_wal_keep_size; se fija en -1 (infinito) de forma predeterminada.