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. Este proceso de evaluación de conflictos en el momento de la confirmación también se llama adjudicació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 TABLEyALTER TABLE, así como las instruccionesGRANTyREVOKE. 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.
Tipos de conflictos de datos
Gracias al mecanismo de control de simultaneidad de Aurora DSQL, las cláusulas SELECT ... FOR
UPDATE y SELECT ... FOR KEY SHARE producen resultados mediante la detección optimista de conflictos en el momento de la confirmación, en lugar de mediante bloqueos. En Aurora DSQL, cuando una transacción escribe una fila y otra la lee con una de las cláusulas anteriores, puede surgir un conflicto en el momento de la confirmación según las columnas que utilicen las transacciones. Las siguientes cláusulas determinan cómo Aurora DSQL detecta estos conflictos.
Definición de columna de claves
Las columnas de claves son miembros de un índice único, no parcial y sin expresión. Todas las demás columnas son columnas sin clave.
SELECT ... FOR UPDATE-
Declara que Aurora DSQL adjudica las filas seleccionadas como si la transacción escribiera en ellas. Si otra transacción ejecuta
UPDATE,DELETE,SELECT ... FOR UPDATEoSELECT ... FOR KEY SHAREen la misma fila y se confirma primero, la transacción que ejecutóSELECT ... FOR UPDATEproduce un error y recibe una respuestaOC000. Esta cláusula entra en conflicto con cualquier escritura simultánea en la fila y con lecturas simultáneas de tipoFOR UPDATEoFOR KEY SHARE. SELECT ... FOR KEY SHARE-
Declara que la transacción depende de las columnas de clave de las filas seleccionadas. Si otra transacción elimina la fila, cambia las columnas de claves o ejecuta
SELECT ... FOR UPDATEy confirma primero, la transacción que ejecutóSELECT ... FOR KEY SHAREproduce un error y recibe una respuestaOC000. UnaUPDATEconcurrente con columnas sin clave no entra en conflicto.
Aurora DSQL no admite las cláusulas NO KEY UPDATE ni FOR SHARE. Sin embargo, DML utiliza el mecanismo NO KEY UPDATE de forma implícita. La siguiente matriz resume cuándo entran en conflicto dos transacciones simultáneas que acceden a la misma fila. Una X indica que las dos operaciones están en conflicto: la última transacción que se confirme producirá un error y recibirá una respuesta OC000. Una celda en blanco indica que ambas transacciones pueden confirmarse.
| Operación | INSERT, DELETE, UPDATE (columnas de clave) o SELECT ... FOR UPDATE |
UPDATE (solo columnas sin clave) |
SELECT ... FOR KEY SHARE |
|---|---|---|---|
INSERT, DELETE, UPDATE (columnas de clave) o SELECT ... FOR UPDATE |
X | X | X |
UPDATE (solo columnas sin clave) |
X | X | |
SELECT ... FOR KEY SHARE |
X |
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.
