Modelo de simultaneidad de Amazon QLDB - Amazon Quantum Ledger Database (Amazon QLDB)

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Modelo de simultaneidad de Amazon QLDB

Amazon QLDB está destinada a 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 SQL y ofrece transacciones ACID completas. Además, los elementos de datos QLDB son documentos que ofrecen flexibilidad de esquema y modelado de datos intuitivo. Con un diario en el núcleo, QLDB facilita el acceso 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 optimista

En QLDB, el control de concurrencia se implementa mediantecontrol de simultaneidad optimista(OCC). OCC funciona según el principio de que muchas transacciones pueden completarse con frecuencia sin interferir entre sí.

Con OCC, las transacciones en QLDB no adquieren bloqueos en los recursos de la base de datos y funcionan con aislamiento serializable completo. QLDB ejecuta transacciones simultáneas de forma serie, de modo que produce el mismo efecto que si esas transacciones se iniciaran en serie.

Antes de comprometerse, cada transacción realiza una comprobación de validación para garantizar que ninguna otra transacción comprometida haya modificado los datos a los que accede. Si esta comprobación revela modificaciones contradictorias o 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 escribe en QLDB, QLDB implementa las comprobaciones de validación del modelo OCC. Si una transacción no se puede escribir en el diario debido a un fallo en la fase de verificación de OCC, QLDB devuelve unOccConflictExceptiona la capa de aplicación. El software de la aplicación es responsable de garantizar que la transacción se reinicie. La solicitud 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 vuelve a intentar 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 análisis completos de tablas

En QLDB, todas las declaraciones partiQL (incluidas todas lasSELECTconsulta) se procesa en una transacción y está sujeta a unlímite de tiempo de espera de transacciones.

Como práctica recomendada, se deben ejecutar sentencias conWHEREcláusula predicada que se filtra en un campo indexado o en un ID de documento. QLDB requiere unigualdadoperador en un campo indexado para buscar un documento de forma eficiente; por ejemplo,WHERE indexedField = 123oWHERE indexedField IN (456, 789).

Sin esta búsqueda indexada, QLDB necesita realizar unExaminación completa de tablasal leer documentos. Esto puede provocar latencia de consultas y tiempos de espera de transacción, y también aumenta las posibilidades de que se produzca un conflicto de OCC con transacciones competidoras.

Por ejemplo, considere una tabla denominadaVehicleque tiene un índice en elVINsolo campo. 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 están trabajando 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. AliceUPDATErealiza una búsqueda indexada en elVIN, por lo que solo necesita leer ese documento. Alice termina y confirma con éxito su transacción primero.

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

Conflictos 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 simultáneos (Alice y Bob) trabajan con la misma tabla de un libro mayor. Ambos desean insertar un nuevo documento solo con la condición de que aún no exista un valor predicado.


                Diagrama de control de concurrencia optimista (OCC) de Amazon QLDB que muestra un ejemplo de excepción de conflicto entre dos usuarios simultáneos.

En este ejemplo, Alice y Bob ejecutan lo siguiente:SELECTyINSERTestados de cuenta dentro de una sola transacción. Su aplicación ejecuta elINSERTdeclaración solo si elSELECTdeclaración no devuelve resultados.

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. Ambos de sus dosSELECTlas consultas no devuelven ningún documento existente con unVINdeABCDE12345EXAMPLE. Por lo tanto, sus solicitudes proceden con elINSERTstatement.

Alice termina y confirma con éxito su transacción primero. Luego, Bob intenta confirmar su transacción, pero QLDB la rechaza y lanza unOccConflictException. Esto se debe a que la transacción comprometida de Alice modificó el conjunto de resultados de BobSELECTy OCC detecta este conflicto antes de confirmar la transacción de Bob.

LaSELECTse requiere consulta para que este ejemplo de transacción seaidempotente. Bob puede volver a intentar toda su transacción desde el principio. Pero su próximoSELECTdevolverá 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 en elsección anteriores también un ejemplo de unidempotentetransacción. En otras palabras, ejecutar la misma transacción varias veces produce resultados idénticos. Si Bob dirige elINSERTsin comprobar primero si un determinadoVINya existe, la tabla podría terminar con documentos duplicadosVINvalores.

Considere otros escenarios de reintentos 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 se agota el tiempo de espera mientras espera una respuesta. Como práctica recomendada, haga que sus transacciones de escritura sean idempotentes para evitar efectos secundarios inesperados en caso de concurrencia o reintentos.

Administración de las sesiones simultáneas

Si tiene experiencia con el sistema de administración de bases de datos relacionales (RDBMS, por sus siglas en inglés), es posible que esté familiarizado con los límites de conexión simultáneos. QLDB no tiene el mismo concepto de conexión RDBMS tradicional porque las transacciones se ejecutan con mensajes de solicitud y respuesta HTTP.

En QLDB, el concepto análogo es unsesión activa. Una sesión es conceptualmente similar a un inicio de sesión de usuario: administra la información sobre las solicitudes de transacción de datos a un libro mayor. Una sesión activa es aquella que ejecuta activamente una transacción. También puede ser una sesión que recientemente finalizó una transacción en la que 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 libro mayor se define enCuotas y límites de Amazon QLDB. Una vez alcanzado este límite, cualquier sesión que intente iniciar una transacción producirá un error (LimitExceededException).

Para obtener información sobre el ciclo de vida de una sesión y cómo el controlador QLDB gestiona las sesiones al ejecutar transacciones de datos, consulteAdministración de sesiones con el conductor. Para obtener información sobre las prácticas recomendadas para configurar un grupo de sesiones en la aplicación mediante el controlador QLDB, consulteConfiguración de QldbDriver objetoenRecomendaciones de controladores de Amazon QLDB.