View a markdown version of this page

Control de simultaneidad en Aurora DSQL - Amazon Aurora DSQL
Respuestas de control de simultaneidadDirectrices para optimizar el rendimiento de las transacciones

Control de simultaneidad en Aurora DSQL

La simultaneidad permite que varias sesiones accedan y modifiquen datos simultáneamente sin poner en riesgo la integridad y la coherencia de los datos. Aurora DSQL proporciona compatibilidad con PostgreSQL a la vez que implementa un moderno mecanismo de control de simultaneidad sin bloqueos. Mantiene el pleno cumplimiento de ACID mediante el aislamiento de instantáneas, lo que garantiza la coherencia y la fiabilidad de los datos.

Una ventaja clave de Aurora DSQL es la arquitectura sin bloqueo, que elimina los cuellos de botella habituales en el rendimiento de las bases de datos. Aurora DSQL impide que las transacciones lentas bloqueen otras operaciones y elimina el riesgo de bloqueos. Gracias a este enfoque, Aurora DSQL resulta especialmente valioso para aplicaciones de alto rendimiento en las que el rendimiento y la escalabilidad son fundamentales.

Respuestas de control de simultaneidad

Aurora DSQL utiliza el control de simultaneidad optimista (OCC), que funciona de forma diferente a los sistemas tradicionales basados en bloqueos. En lugar de utilizar bloqueos, OCC evalúa los conflictos en el momento de la confirmación. Cuando Aurora DSQL detecta un conflicto, devuelve un error de serialización de PostgreSQL con código SQLSTATE 40001. El mensaje de respuesta incluye un código OCC que identifica el tipo de conflicto:

OC000: conflicto de datos

Dos transacciones intentaron modificar la misma fila. La transacción con el tiempo de confirmación más temprano se produce correctamente y la transacción en conflicto recibe la respuesta OC000:

ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001)
OC001: conflicto de esquema

El catálogo de esquemas en caché de la sesión no está actualizado. Cuando Aurora DSQL detecta que la versión del catálogo ha cambiado desde que la sesión cargó su caché y que la transacción no puede rebasarse de forma segura a la versión actual, la transacción recibe la respuesta OC001:

ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)

cualquier operación que modifique el catálogo de esquemas puede provocar una respuesta OC001, incluidas las instrucciones DDL como CREATE TABLE y ALTER TABLE, así como las instrucciones GRANT y REVOKE. Para obtener más información, consulte DDL y las transacciones distribuidas en Aurora DSQL.

Diseñe las aplicaciones para implementar la lógica de reintento para gestionar estas respuestas. El patrón de diseño ideal es idempotente, lo que habilita el reintento de transacciones como primer recurso siempre que sea posible. La lógica recomendada es similar a la lógica de anular y reintentar en una situación estándar de tiempo de espera de bloqueo o interbloqueo de PostgreSQL. No obstante, OCC requiere que las aplicaciones ejerciten esta lógica con mayor frecuencia.

Directrices para optimizar el rendimiento de las transacciones

Para optimizar el rendimiento, minimice la alta contención en claves únicas o en intervalos de claves pequeños. Para alcanzar este objetivo, diseñe el esquema de forma que las actualizaciones se repartan por el intervalo de claves del clúster mediante las siguientes directrices:

  • Elija una clave principal aleatoria para las tablas.

  • Evite patrones que aumenten la contención en claves únicas. Este enfoque garantiza un rendimiento óptimo incluso a medida que crezca el volumen de transacciones.