Modelo de concurrencia de Amazon QLDB

El objetivo de Amazon QLDB es abordar las necesidades de las cargas de trabajo de procesamiento de transacciones online (OLTP) de alto rendimiento. QLDB admite capacidades de consulta similares a las de SQL y ofrece transacciones ACID completas. Además, los elementos de datos de QLDB son documentos que ofrecen flexibilidad de esquema y un modelado de datos intuitivo. Con un diario como base, puede usar QLDB para acceder al historial completo y verificable de todos los cambios en sus datos y transmitir transacciones coherentes a otros servicios de datos según sea necesario.

Control de concurrencia

QLDB implementa el control de concurrencia mediante el control de concurrencia optimista (OCC). El OCC se basa en el principio de que varias transacciones pueden completarse con frecuencia sin interferir entre sí.

Al usar OCC, las transacciones en la QLDB no adquieren bloqueos en los recursos de la base de datos y funcionan con un aislamiento serializable total. QLDB ejecuta transacciones simultáneas en serie, de modo que produce el mismo efecto que si esas transacciones se hubieran iniciado en serie.

Antes de confirmarse, cada transacción realiza una comprobación de validación para garantizar que ninguna otra transacción confirmada haya modificado los datos a los que está accediendo. Si esta comprobación revela modificaciones contradictorias o si el estado de los datos cambia, se rechaza la transacción de confirmación. Sin embargo, la transacción se puede reiniciar.

Cuando una transacción se escribe en QLDB, las comprobaciones de validación del modelo OCC las implementa la propia QLDB. Si no se puede escribir una transacción en el diario debido a un error en la fase de verificación de la OCC, QLDB devuelve una OccConflictException a la capa de aplicación. El software de la aplicación es responsable de garantizar que la transacción se reinicie. La aplicación debería abortar la transacción rechazada y, a continuación, volver a intentar toda la transacción desde el principio.

Para obtener información sobre cómo el controlador QLDB gestiona y reintenta los conflictos de OCC y otras excepciones transitorias, consulte Descripción de la política de reintentos del controlador en Amazon QLDB.

Uso de índices para evitar escanear tablas completas

En la QLDB, cada instrucción PartiQL (incluidas las consultas SELECT) se procesa en una transacción y está sujeta a un límite de tiempo de espera de la transacción.

Como práctica recomendada, debe ejecutar las instrucciones con una cláusula de predicado WHERE que filtre un campo indexado o un identificador de documento. QLDB requiere un operador de igualdad en un campo indexado para buscar un documento de manera eficiente; por ejemplo WHERE indexedField = 123 o WHERE indexedField IN (456, 789).

Sin esta búsqueda indexada, la QLDB necesita escanear toda la tabla al leer los documentos. Esto puede provocar una latencia en las consultas y tiempos de espera de las transacciones, además de aumentar las probabilidades de que la OCC entre en conflicto con transacciones competidoras.

Por ejemplo, piense en una tabla llamada Vehicle que solo tiene un índice en el campo VIN. Contiene los siguientes documentos.

VIN	Make	Modelo	Color
"1N4AL11D75C109151"	"Audi"	"A5"	"Silver"
"KM8SRDHF6EU074761"	"Tesla"	"Model S"	"Blue"
"3HGGK5G53FM761765"	"Ducati"	"Monster 1200"	"Yellow"
"1HVBBAANXWH544237"	"Ford"	"F 150"	"Black"
"1C4RJFAG0FC625797"	"Mercedes"	"CLK 350"	"White"

Dos usuarios simultáneos llamados Alice y Bob trabajan con la misma tabla en un libro mayor. Quieren actualizar dos documentos diferentes, de la siguiente manera.

Alice:

UPDATE Vehicle AS v
SET v.Color = 'Blue'
WHERE v.VIN = '1N4AL11D75C109151'

Bob:

UPDATE Vehicle AS v
SET v.Color = 'Red'
WHERE v.Make = 'Tesla' AND v.Model = 'Model S'

Supongamos que Alice y Bob inician sus transacciones al mismo tiempo. La instrucción UPDATE de Alice realiza una búsqueda indexada en el campo VIN, por lo que solo necesita leer ese documento. Alice termina y confirma correctamente su transacción primero.

La instrucción de Bob filtra los campos no indexados, por lo que escanea una tabla y encuentra un OccConflictException. Esto se debe a que la transacción confirmada por Alice modificó los datos a los que accede la instrucción de Bob, que incluyen todos los documentos de la tabla, no solo los documentos que Bob está actualizando.

Conflictos de OCC de inserción

Los conflictos de OCC pueden incluir documentos recién insertados, no solo documentos que ya existían anteriormente. Fíjese en el siguiente diagrama, en el que dos usuarios (Alice y Bob) trabajan con el mismo elemento de una tabla en un libro mayor. Ambos quieren insertar un documento nuevo solo con la condición de que aún no exista un valor predicado.

En este ejemplo, tanto Alice como Bob ejecutan las siguientes instrucciones SELECT y INSERT en una sola transacción. Su aplicación ejecuta la instrucción INSERT solo si la instrucción SELECT no devuelve ningún resultado.

SELECT * FROM Vehicle v WHERE v.VIN = 'ABCDE12345EXAMPLE'

INSERT INTO Vehicle VALUE
{
    'VIN' : 'ABCDE12345EXAMPLE',
    'Type' : 'Wagon',
    'Year' : 2019,
    'Make' : 'Subaru',
    'Model' : 'Outback',
    'Color' : 'Gray'
}

Supongamos que Alice y Bob inician sus transacciones al mismo tiempo. Sus dos consultas SELECT no devuelven ningún documento existente con un VIN de ABCDE12345EXAMPLE. Por lo tanto, sus solicitudes continúan con la instrucción INSERT.

Alice termina y confirma correctamente su transacción primero. Entonces, Bob intenta confirmar su transacción, pero QLDB la rechaza y lanza una OccConflictException. Esto se debe a que la transacción confirmada por Alice modificó el conjunto de resultados de la consulta SELECT de Bob y el OCC detecta este conflicto antes de confirmar la transacción de Bob.

La consulta SELECT es necesaria para que este ejemplo de transacción sea idempotente. A continuación, Bob puede volver a intentar toda la transacción desde el principio. Pero su siguiente consulta SELECT devolverá el documento que Alice insertó, por lo que la solicitud de Bob no ejecutará INSERT.

Hacer que las transacciones sean idempotentes

La transacción de inserción de la sección anterior también es un ejemplo de transacción idempotente. En otras palabras, ejecutar la misma transacción varias veces produce resultados idénticos. Si Bob ejecuta INSERT sin comprobar primero si un determinado VIN ya existe, es posible que la tabla acabe con documentos con valores VIN duplicados.

Considere otros escenarios de reintentos además de los conflictos de OCC. Supongamos que QLDB confirma correctamente la transacción en el lado del servidor pero el cliente agota el tiempo de espera mientras espera una respuesta. Le recomendamos que haga que las transacciones de escritura sean idempotentes para evitar cualquier efecto secundario inesperado en caso de reintentos.

Conflictos de OCC de edición

QLDB evita la edición simultánea de revisiones en el mismo bloque de diario. Piense en un ejemplo en el que dos usuarios simultáneos (Alice y Bob) quieren editar dos revisiones de documentos diferentes que estén consignadas en el mismo bloque de un libro mayor. En primer lugar, Alice solicita la edición de una revisión ejecutando el procedimiento almacenado REDACT_REVISION, tal como se indica a continuación.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '5PLf9SXwndd63lPaSIa0O6', 'ADR2Ll1fGsU4Jr4EqTdnQF'

Luego, mientras la solicitud de Alice aún se está procesando, Bob solicita la edición de otra revisión, de la siguiente forma.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '8F0TPCmdNQ6JTRpiLj2TmW', '05K8zpGYWynDlEOK5afDRc'

QLDB rechaza la solicitud de Bob con una OccConflictException a pesar de que están intentando editar dos revisiones de documentos diferentes. Esto se debe a que la revisión de Bob se encuentra en el mismo bloque que la revisión que Alice está editando. Cuando la solicitud de Alice termine de procesarse, Bob podrá volver a intentar su solicitud de edición.

Del mismo modo, si dos transacciones simultáneas intentan editar la misma revisión, solo se podrá procesar una solicitud. La otra solicitud falla con una excepción de conflicto de OCC hasta que se complete la edición. Posteriormente, cualquier solicitud de edición de la misma revisión generará un error que indicará que la revisión ya está editada.

Administración de las sesiones de concurrencia

Si tiene experiencia en el uso de un sistema de administración de base de datos relacional (RDBMS), puede que esté familiarizado con las conexiones simultáneas. QLDB no tiene el mismo concepto de conexión RDBMS tradicional, ya que las transacciones se ejecutan con mensajes de solicitud y respuesta HTTP.

El concepto análogo en QLDB es el de sesión activa. Conceptualmente, una sesión es similar al inicio de sesión de un usuario: gestiona la información sobre sus solicitudes de transacción de datos a un libro mayor. Una sesión activa es aquella en la que se ejecuta una transacción de forma activa. También puede tratarse de una sesión en la que se ha finalizado recientemente una transacción, y el servicio prevé iniciar otra transacción de forma inmediata. QLDB admite una transacción en ejecución activa por sesión.

El límite de sesiones activas simultáneas por libro mayor se define en Cuotas y límites de Amazon QLDB. Una vez alcanzado este límite, cualquier sesión que intente iniciar una transacción dará como resultado un error (LimitExceededException).

Para obtener información sobre el ciclo de vida de una sesión y sobre cómo el controlador QLDB gestiona las sesiones al ejecutar transacciones de datos, consulte Gestión de sesiones con el controlador. Para conocer las prácticas recomendadas para configurar un grupo de sesiones en su aplicación mediante el controlador QLDB, consulte Configuración del objeto QLDBDriver en las recomendaciones de controlador Amazon QLDB.