Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Modèle de QLDB simultanéité Amazon

Amazon QLDB est destiné à répondre aux besoins des charges de travail de traitement des transactions en ligne (OLTP) à hautes performances. QLDBprend en SQL charge des fonctionnalités de requête similaires et fournit des ACID transactions complètes. En outre, les éléments de QLDB données sont des documents, offrant une flexibilité de schéma et une modélisation intuitive des données. Avec un journal comme base, vous pouvez accéder QLDB à l'historique complet et vérifiable de toutes les modifications apportées à vos données, et transmettre des transactions cohérentes à d'autres services de données selon vos besoins.

Contrôle de simultanéité optimiste

DansQLDB, le contrôle de simultanéité est mis en œuvre à l'aide d'un contrôle de simultanéité optimiste ()OCC. OCCrepose sur le principe selon lequel plusieurs transactions peuvent fréquemment être effectuées sans interférer les unes avec les autres.

En utilisantOCC, les transactions QLDB ne bloquent pas les ressources de la base de données et fonctionnent avec une isolation sérialisable complète. QLDBexécute des transactions simultanées en série, de manière à produire le même effet que si ces transactions étaient démarrées en série.

Avant d'être validée, chaque transaction effectue un contrôle de validation pour s'assurer qu'aucune autre transaction validée n'a modifié les données auxquelles elle accède. Si cette vérification révèle des modifications contradictoires ou si l'état des données change, la transaction de validation est rejetée. Cependant, la transaction peut être redémarrée.

Lorsqu'une transaction écrit dansQLDB, les contrôles de validation du OCC modèle sont mis en œuvre par QLDB lui-même. Si une transaction ne peut pas être écrite dans le journal en raison d'un échec lors de la phase de vérification deOCC, QLDB renvoie une transaction OccConflictException à la couche application. Le logiciel d'application est chargé de s'assurer que la transaction est redémarrée. L'application doit abandonner la transaction rejetée, puis réessayer l'ensemble de la transaction depuis le début.

Pour savoir comment le QLDB pilote gère et réessaie OCC les conflits et autres exceptions transitoires, voir. Comprendre la politique de nouvelle tentative avec le chauffeur sur Amazon QLDB

Utilisation d'index pour éviter l'analyse complète des tables

DansQLDB, chaque instruction partiQL (y compris chaque SELECT requête) est traitée dans une transaction et est soumise à un délai d'expiration de transaction.

Il est recommandé d'exécuter des instructions avec une clause de WHERE prédicat filtrant en fonction d'un champ indexé ou d'un identifiant de document. QLDBnécessite un opérateur d'égalité sur un champ indexé pour rechercher efficacement un document ; par exemple, WHERE indexedField = 123 ouWHERE indexedField IN (456, 789).

Sans cette recherche indexée, il QLDB faut effectuer une analyse complète du tableau lors de la lecture de documents. Cela peut entraîner une latence des requêtes et des délais d'attente pour les transactions, et augmente également les risques de OCC conflit avec des transactions concurrentes.

Par exemple, considérez une table nommée Vehicle qui possède un index sur le VIN champ uniquement. Il contient les documents suivants.

Deux utilisateurs simultanés nommés Alice et Bob travaillent avec la même table dans un registre. Ils souhaitent mettre à jour deux documents différents, comme suit.

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'

Supposons qu'Alice et Bob commencent leurs transactions en même temps. La UPDATE déclaration d'Alice effectue une recherche indexée sur le VIN terrain, elle n'a donc besoin que de lire ce document. Alice termine et valide sa transaction avec succès en premier.

La déclaration de Bob filtre sur les champs non indexés. Elle analyse donc une table et rencontre un. OccConflictException Cela est dû au fait que la transaction validée d'Alice a modifié les données auxquelles la déclaration de Bob accède, qui incluent tous les documents du tableau, et pas seulement le document que Bob est en train de mettre à jour.

OCCConflits d'insertion

OCCles conflits peuvent inclure des documents récemment insérés, et pas uniquement des documents qui existaient auparavant. Prenons le schéma suivant, dans lequel deux utilisateurs simultanés (Alice et Bob) travaillent avec la même table dans un registre. Ils souhaitent tous deux insérer un nouveau document uniquement à condition qu'aucune valeur de prédicat n'existe encore.

Dans cet exemple, Alice et Bob exécutent les INSERT instructions suivantes SELECT dans le cadre d'une seule transaction. Leur application exécute l'INSERTinstruction uniquement si celle-ci SELECT ne renvoie aucun résultat.

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

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

Supposons qu'Alice et Bob commencent leurs transactions en même temps. Leurs deux SELECT requêtes ne renvoient aucun document existant avec un VIN deABCDE12345EXAMPLE. Leurs demandes sont donc suivies de la INSERT déclaration.

Alice termine et valide sa transaction avec succès en premier. Bob essaie ensuite de valider sa transaction, mais la QLDB rejette et lance unOccConflictException. Cela est dû au fait que la transaction validée d'Alice a modifié le jeu de résultats de la SELECT requête de Bob et OCC détecte ce conflit avant de valider la transaction de Bob.

La SELECT requête est requise pour que cet exemple de transaction soit idempotent. Bob peut alors réessayer l'intégralité de sa transaction depuis le début. Mais sa prochaine SELECT requête renverra le document inséré par Alice, de sorte que l'application de Bob n'exécutera pas leINSERT.

Rendre les transactions idempotentes

La transaction d'insertion de la section précédente est également un exemple de transaction idempotente. En d'autres termes, exécuter plusieurs fois la même transaction produit des résultats identiques. Si Bob exécute le INSERT sans vérifier au préalable si une donnée existe VIN déjà, le tableau peut se retrouver avec des documents contenant des VIN valeurs dupliquées.

Envisagez d'autres scénarios de nouvelle tentative en plus des OCC conflits. Par exemple, il est possible qu'une transaction soit validée QLDB avec succès du côté serveur, mais que le client expire en attendant une réponse. Il est recommandé de rendre vos transactions d'écriture idempotentes afin d'éviter tout effet secondaire inattendu en cas de simultanéité ou de nouvelles tentatives.

Conflits de rédaction OCC

QLDBempêche la rédaction simultanée de révisions sur le même bloc de journal. Prenons l'exemple de deux utilisateurs simultanés (Alice et Bob) qui souhaitent rédiger deux révisions de document différentes qui sont validées sur le même bloc dans un registre. Alice demande tout d'abord la rédaction d'une révision en exécutant la procédure REDACT_REVISION stockée, comme suit.

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

Alors que la demande d'Alice est toujours en cours de traitement, Bob demande la rédaction d'une autre révision, comme suit.

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

QLDBrejette la demande de Bob avec un OccConflictException même s'ils essaient de rédiger deux révisions de document différentes. Cela est dû au fait que la révision de Bob se trouve dans le même bloc que la révision qu'Alice est en train de rédiger. Une fois le traitement de la demande d'Alice terminé, Bob peut réessayer sa demande de rédaction.

De même, si deux transactions simultanées tentent de supprimer la même révision, une seule demande peut être traitée. L'autre demande échoue avec une exception de OCC conflit jusqu'à ce que la rédaction soit terminée. Par la suite, toute demande de rédaction de la même révision entraînera une erreur indiquant que la révision est déjà expurgée.

Gestion des sessions simultanées

Si vous avez déjà utilisé un système de gestion de base de données relationnelle (RDBMS), vous connaissez peut-être les limites de connexions simultanées. QLDBn'a pas le même concept qu'une RDBMS connexion traditionnelle car les transactions sont exécutées avec des messages de HTTP demande et de réponse.

DansQLDB, le concept analogue est une session active. Une session est conceptuellement similaire à une connexion utilisateur : elle gère les informations relatives à vos demandes de transaction de données adressées à un registre. Une session active est une session qui exécute activement une transaction. Il peut également s'agir d'une session ayant récemment terminé une transaction au cours de laquelle le service prévoit de commencer immédiatement une autre transaction. QLDBprend en charge une transaction active par session.

La limite de sessions actives simultanées par registre est définie dansQuotas et limites sur Amazon QLDB. Une fois cette limite atteinte, toute session qui tente de démarrer une transaction entraîne une erreur (LimitExceededException).

Pour plus d'informations sur le cycle de vie d'une session et sur la manière dont le QLDB pilote gère les sessions lors de l'exécution de transactions de données, consultezGestion des sessions avec le chauffeur. Pour connaître les meilleures pratiques relatives à la configuration d'un pool de sessions dans votre application à l'aide du QLDB pilote, consultez Configuration de l' QldbDriver objet les recommandations relatives aux QLDB pilotes Amazon.