Migración de PostgreSQL a Aurora DSQL

Utilice CREATE INDEX ASYNC en lugar de CREATE INDEX para la creación de índices sin bloqueo.

Ventaja: Creación de índices sin tiempo de inactividad en tablas grandes.

Use DELETE FROM table_name en lugar de TRUNCATE.

Alternativa: Para una recreación completa de las tablas, utilice DROP TABLE y, a continuación, CREATE TABLE.

Aurora DSQL no admite los comandos ALTER SYSTEM porque el sistema está totalmente administrado. La configuración se gestiona automáticamente en función de los patrones de carga de trabajo.

Ventaja: No es necesario ajustar la base de datos ni administrar los parámetros.

Utilice identificadores únicos universales (UUID) o claves compuestas en lugar de secuencias que se incrementen de forma automática. Las secuencias que se incrementan automáticamente conllevan una gran cantidad de conflictos en un sistema distribuido, ya que varios escritores intentan actualizar los mismos datos. Los UUID proporcionan la misma función, pero no requieren coordinación.

Ejemplo de: id UUID PRIMARY KEY DEFAULT gen_random_uuid()

Aurora DSQL admite relaciones de tablas y operaciones JOIN, pero aún no impone restricciones de clave externa. Esta elección de diseño se ajusta a los patrones modernos de bases de datos distribuidas, en los que la validación de la capa de aplicaciones proporciona más flexibilidad y evita cuellos de botella en el rendimiento derivados de las operaciones en cascada.

Patrón: Implemente comprobaciones de integridad referencial en la capa de aplicaciones mediante convenciones de nomenclatura, lógica de validación y límites de transacción coherentes. Muchas aplicaciones a gran escala prefieren este enfoque para controlar mejor la gestión de errores y el rendimiento.

Utilice CTE, subconsultas o tablas normales con lógica de limpieza en lugar de tablas temporales.

Alternativa: Cree tablas con nombres específicos de cada sesión y límpielas en su aplicación.

Aurora DSQL proporciona una base de datos integrada denominada postgres por clúster.

Consejo de migración: Si la aplicación utiliza varias bases de datos, cree clústeres de Aurora DSQL independientes para una separación lógica o utilice esquemas dentro de un único clúster.

Aún no se admiten las tablas temporales en Aurora DSQL. Se pueden utilizar expresiones de tabla comunes (CTE) y subconsultas como alternativa para consultas complejas.

Alternativa: Utilice CTE con cláusulas WITH para conjuntos de resultados temporales o tablas normales con nombres únicos para datos específicos de la sesión.

Aurora DSQL elimina los espacios de tabla y la administración de almacenamiento manual. El almacenamiento se escala y se optimiza automáticamente en función de sus patrones de datos.

Ventaja: No es necesario supervisar el espacio en disco, planificar la asignación de almacenamiento ni administrar las configuraciones de los espacios de tabla.

Aurora DSQL no admite los desencadenadores.

Estrategia de migración: Traslade la lógica de los desencadenadores al código de la aplicación, utilice arquitecturas basadas en eventos con servicios de AWS como EventBridge o implemente registros de auditoría mediante el registro de aplicaciones.

Aurora DSQL admite funciones basadas en SQL, pero no lenguajes procedurales como PL/pgSQL.

Alternativa: Utilice funciones SQL para las transformaciones de datos o traslade la lógica compleja a la capa de aplicación o a funciones de AWS Lambda.

Aurora DSQL utiliza el control de simultaneidad optimista (OCC), un enfoque sin bloqueos diferente a los mecanismos de bloqueo de bases de datos tradicionales. En lugar de adquirir bloqueos que afecten a otras transacciones, Aurora DSQL permite que las transacciones continúen sin bloquearse y detecta los conflictos en el momento de la confirmación. De este modo, se eliminan los interbloqueos y se impide que las transacciones lentas bloqueen otras operaciones.

Diferencia clave: Cuando se producen conflictos, Aurora DSQL devuelve un error de serialización en lugar de hacer que las transacciones esperen bloqueos. Esto requiere que las aplicaciones implementen una lógica de reintento, similar a la gestión de tiempos de espera de bloqueo en las bases de datos tradicionales, pero los conflictos se resuelven de forma inmediata en lugar de provocar esperas de bloqueo.

Patrón de diseño: Implemente lógica de transacción idempotente con mecanismos de reintento. Diseñe esquemas para minimizar la contención mediante claves principales aleatorias y la distribución de actualizaciones en todo su intervalo de claves. Para obtener más información, consulte Control de simultaneidad en Aurora DSQL.

Aurora DSQL admite las relaciones de claves externas entre tablas, incluidas las operaciones JOIN , pero aún no se admiten restricciones de clave externa. Si bien aplicar la integridad referencial puede resultar útil, las operaciones en cascada (como las eliminaciones en cascada) pueden provocar problemas de rendimiento inesperados; por ejemplo, eliminar un pedido con mil partidas se convierte en una transacción de mil y una filas. Por este motivo, muchos clientes evitan las restricciones de clave externa.

Patrón de diseño: Implemente comprobaciones de integridad referencial en la capa de aplicaciones, utilice patrones de coherencia final o aproveche los servicios de AWS para la validación de datos.

Aurora SQL no requiere comandos VACUUM, TRUNCATE ni ALTER SYSTEM. El sistema administra automáticamente la optimización del almacenamiento, la recopilación de estadísticas y el ajuste del rendimiento.

Ventaja: Elimina la necesidad de ventanas de mantenimiento de base de datos, la programación del vaciado y la afinación de los parámetros del sistema.

Aurora DSQL particiona y distribuye sus datos de forma automática en función de los patrones de acceso. No son necesarios el particionamiento manual ni las secuencias.

Consejo de migración: Elimine la lógica de particionamiento manual y deje que Aurora DSQL se encargue de la distribución de datos. Utilice UUID o ID generados por la aplicación en lugar de secuencias.