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 simultanéité Amazon QLDB

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

Contrôle de simultanéité optimiste

Dans QLDB, le contrôle de simultanéité est mis en œuvre à l'aide du contrôle de simultanéité optimiste (OCC). L'OCC part du principe que plusieurs transactions peuvent fréquemment être effectuées sans interférer les unes avec les autres.

Avec OCC, les transactions dans QLDB ne bloquent pas les ressources de la base de données et fonctionnent avec une isolation sérialisable complète. QLDB exé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 dans QLDB, les contrôles de validation du modèle OCC 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 de la phase de vérification d'OCC, QLDB renvoie OccConflictException une transaction à 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 pilote QLDB gère et réessaie les conflits OCC et les autres exceptions transitoires, consultez. Comprendre la politique de nouvelle tentative avec le pilote dans Amazon QLDB

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

Dans QLDB, chaque instruction partiQL (y compris SELECT chaque requête) est traitée dans le cadre d'une transaction et est soumise à une limite de 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. QLDB nécessite un opérateur d'égalité sur un champ indexé pour rechercher efficacement un document ; par exemple, ou. WHERE indexedField = 123 WHERE indexedField IN (456, 789)

Sans cette recherche indexée, QLDB doit effectuer une analyse complète de la table lors de la lecture de documents. Cela peut entraîner une latence des requêtes et des délais d'expiration des transactions, et augmente également les risques de conflit entre l'OCC et les 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.

Conflits d'insertion OCC

Les conflits OCC 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 QLDB la rejette et lance un. OccConflictException 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 conflits OCC. Par exemple, il est possible que QLDB valide avec succès une transaction 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

QLDB empê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'

QLDB rejette la demande de Bob par OccConflictException un même s'il essaie 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 conflit OCC 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. QLDB n'a pas le même concept qu'une connexion RDBMS traditionnelle, car les transactions sont exécutées avec des messages de requête et de réponse HTTP.

Dans QLDB, 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. QLDB prend en charge une transaction active par session.

La limite de sessions actives simultanées par registre est définie dansQuotas et limites dans 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 façon dont le pilote QLDB gère les sessions lors de l'exécution de transactions de données, consultez. Gestion 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 pilote QLDB, consultez les recommandations relatives aux pilotes Configuration de l' QldbDriver objet Amazon QLDB.