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 está totalmente administrado, por lo que la configuración se gestiona automáticamente en función de los patrones de carga de trabajo. Use la consola de administración de AWS o la API para administrar la configuración del clúster.

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

Aurora DSQL admite relaciones de tabla y operaciones de JOIN. Para garantizar la integridad referencial, implemente la validación en la capa de aplicación. Este 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.

Para la gestión temporal de datos, DEBERÍA utilizar expresiones de tabla comunes (CTE) y subconsultas, que ofrecen alternativas flexibles 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.

Para obtener una funcionalidad similar a la de un activador, implemente una lógica basada en eventos en la capa de aplicación.

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 relaciones de claves externas entre tablas, incluidas las operaciones JOIN . Para garantizar la integridad referencial, implemente la validación en la capa de aplicación. 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 DSQL administra automáticamente la optimización del almacenamiento, la recopilación de estadísticas y el ajuste del rendimiento. Los comandos de mantenimiento tradicionales como VACUUM son gestionados por el sistema.

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. Utilice UUID o ID generados por la aplicación para una distribución óptima.

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 para una distribución óptima. Si su aplicación requiere identificadores secuenciales, consulte Secuencias y columnas de identidad.