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 QLDB simultaneidad de Amazon

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

Control de concurrencia

EnQLDB, el control de simultaneidad se implementa mediante un control de simultaneidad optimista (). OCC OCCfunciona según el principio de que varias transacciones pueden completarse con frecuencia sin interferir entre sí.

Al OCC utilizarlas, las transacciones de QLDB entrada no bloquean los recursos de la base de datos y funcionan con un aislamiento serializable total. QLDBejecuta 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 escribeQLDB, las comprobaciones de validación del OCC modelo se implementan por QLDB sí mismas. Si una transacción no se puede escribir en el diario debido a un error en la fase de verificaciónOCC, 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 QLDB conductor gestiona y reintenta OCC los conflictos y otras excepciones transitorias, consulte. Descripción de la política de reintentos con el conductor en Amazon QLDB

Uso de índices para evitar escanear tablas completas

EnQLDB, cada sentencia PartiQL (incluidas todas las SELECT 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 las instrucciones con una cláusula de predicado WHERE que filtre por campo indexado o por identificador de documento. QLDBrequiere un operador de igualdad en un campo indexado para buscar un documento de manera eficiente; por ejemplo, o. WHERE indexedField = 123 WHERE indexedField IN (456, 789)

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

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

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 inserción OCC

OCClos conflictos 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. Luego, Bob intenta confirmar su transacción, pero la QLDB rechaza y lanza una. OccConflictException Esto se debe a que la transacción confirmada por Alice modificó el conjunto de resultados de la SELECT consulta de Bob y 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.

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

Conflictos de redacción OCC

QLDBimpide la redacció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'

QLDBrechaza la solicitud de Bob con una a OccConflictException pesar de que están intentando redactar 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 fracasa con una excepción de OCC conflicto hasta que se complete la redacció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 bases de datos relacionales (RDBMS), es posible que esté familiarizado con los límites de conexión simultánea. QLDBno tiene el mismo concepto de RDBMS conexión tradicional porque las transacciones se ejecutan con mensajes de HTTP solicitud y respuesta.

EnQLDB, el concepto análogo es una 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. QLDBadmite 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 en 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 gestiona el QLDB controlador las sesiones al ejecutar transacciones de datos, consulteGestión de sesiones con el controlador. Para conocer las mejores prácticas para configurar un grupo de sesiones en su aplicación mediante el QLDB controlador, consulte Configurar el QldbDriver objeto las recomendaciones de QLDB controladores de Amazon.