Modelo de simultaneidad de Amazon QLDB

El objetivo de Amazon QLDB es satisfacer las necesidades de las cargas de trabajo de procesamiento de transacciones en línea (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 utilizar 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 simultaneidad

En QLDB, el control de concurrencia se implementa mediante un control de concurrencia optimista (OCC). La OCC se basa en el principio de que, con frecuencia, se pueden completar varias transacciones sin interferir entre sí.

Con OCC, las transacciones en QLDB no bloquean 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 iniciaran 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 confirmada. Sin embargo, la transacción se puede reiniciar.

Cuando una transacción se escribe en QLDB, la propia QLDB implementa las comprobaciones de validación del modelo OCC. Si no se puede escribir una transacción en el diario debido a un error en la fase de verificación del OCC, QLDB devuelve una transacciónOccConflictException 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 debe anular 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, consulteDescripción de la política de reintentos con el controlador en Amazon QLDB.

Uso de índices para evitar escaneos completos de tablas

En QLDB, cada sentencia PartiQL (incluidas todas lasSELECT consultas) 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 sentencias con una cláusula deWHERE predicado 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 oWHERE indexedField IN (456, 789).

Sin esta búsqueda indexada, QLDB necesita realizar un escaneo completo de la tabla al leer documentos. Esto puede provocar latencia en las consultas y tiempos de espera de las transacciones, y también aumenta las posibilidades de que se produzca un conflicto entre el OCC y las transacciones de la competencia.

Por ejemplo, considere una tabla denominadaVehicle que solo tiene un índice en elVIN campo. Contiene los siguientes documentos.

VINO	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.

Alicia:

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. LaUPDATE declaración de Alice realiza una búsqueda indexada en elVIN campo, por lo que solo necesita leer ese documento. Alice finaliza la transacción y la confirma correctamente primero.

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

Conflictos de OCC de inserción

Los conflictos de OCC pueden incluir documentos que se han insertado recientemente, no solo documentos que existían anteriormente. Fíjese en el siguiente diagrama, en el que dos usuarios de simultaneidad (Alice y Bob) trabajan con la misma tabla en un libro mayor. Ambos desean insertar un documento nuevo solo con la condición de que aún no exista un valor de predicado.

En este ejemplo, tanto Alice como Bob ejecutan las siguientesINSERT sentenciasSELECT y sentencias en una sola transacción. Su aplicación ejecuta laINSERT sentencia solo si laSELECT sentencia 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. AmbasSELECT consultas no devuelven ningún documento existente con unVIN deABCDE12345EXAMPLE. Por lo tanto, sus solicitudes continúan con laINSERT declaración.

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

LaSELECT consulta 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. Sin embargo, su próximaSELECT consulta devolverá el documento que Alice insertó, por lo que la aplicación de Bob no ejecutará elINSERT.

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 la tablaINSERT sin comprobar primero siVIN ya existe alguna, es posible que la tabla acabe con documentos conVIN valores duplicados.

Tenga en cuenta otros escenarios de reintento además de los conflictos de OCC. Por ejemplo, es posible que QLDB confirme correctamente una transacción en el lado del servidor, pero el cliente agota el tiempo de espera mientras espera una respuesta. Como práctica recomendada, haz que las transacciones de escritura sean idempotentes para evitar cualquier efecto secundario inesperado en caso de concurrencia o de reintentos.

Redacción: OCC: conflictos

QLDB evita las redacciones simultáneas de las revisiones en el mismo bloque del diario. Pensemos en un ejemplo en el que dos usuarios simultáneos (Alice y Bob) desean redactar dos revisiones de documentos diferentes que están confirmadas en el mismo bloque de un libro mayor. Primero, Alice solicita la redacción de una revisión ejecutando el procedimientoREDACT_REVISION almacenado, de la siguiente manera.

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

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

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

QLDB rechaza la solicitud de Bob aOccConflictException pesar de que están intentando redactar dos revisiones diferentes del documento. Esto se debe a que la revisión de Bob se encuentra en el mismo bloque que la revisión que Alice está redactando. Cuando la solicitud de Alice termine de procesarse, Bob podrá volver a intentar su solicitud de redacción.

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

Administración de las sesiones de simultaneidad

Si tiene experiencia en el uso de un sistema de administración de base de datos relacional (RDBMS), es posible que esté familiarizado con los límites de las conexiones de simultaneidad. QLDB no tiene el mismo concepto de una conexión RDBMS tradicional porque las transacciones se ejecutan con mensajes de solicitud y respuesta HTTP.

En QLDB, el concepto análogo es una sesión activa. Conceptualmente, una sesión es similar al inicio de sesión de un usuario: administra la información sobre las solicitudes de transacciones de datos a un libro mayor. Una sesión activa es aquella que ejecuta una transacción de forma activa. También puede ser una sesión en la que se finalizó recientemente una transacción y el servicio anticipa que iniciará otra transacción inmediatamente. QLDB admite una transacción en ejecución activa por sesión.

El límite de sesiones activas simultáneas por registro se define enCuotas y límites de Amazon QLDB. Una vez alcanzado este límite, cualquier sesión que intente iniciar una transacción generará 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, consulteGestión de sesiones con el conductor. Para conocer las prácticas recomendadas para configurar un grupo de sesiones en su aplicación mediante el controlador QLDB, consulteConfiguración de QldbDriver objeto las recomendaciones de controladores de Amazon QLDB.