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.
• 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.

• Las canalizaciones de ingesta administradas no se admiten para las áreas de trabajo FedRAMP High o FedRAMP Moderate.

• El conector ingiere datos sin procesar sin transformaciones. Utilice las canalizaciones declarativas de Lakeflow Spark downstream 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 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.
• 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.
• 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.