InterSystems IRIS Global Transactions

InterSystems IRIS DBMS prend en charge les curieuses structures de stockage de données - globales. En fait, ce sont des clés à plusieurs niveaux avec divers avantages supplémentaires sous la forme de transactions, des fonctions rapides pour parcourir les arbres de données, des verrous et leur propre langage ObjectScript.

Plus d'informations sur les globaux dans la série d'articles «Globals - Swords-Masons for Data Storage»:

Les arbres. Partie 1
Les arbres. 2e partie
Tableaux clairsemés. 3e partie

Il est devenu intéressant pour moi de savoir comment les transactions sont mises en œuvre dans le monde, quelles sont les fonctionnalités. Après tout, il s'agit d'une structure de stockage des données complètement différente de celle des tables habituelles. Niveau beaucoup plus bas.

Comme vous le savez d'après la théorie des bases de données relationnelles, une bonne implémentation de transaction doit satisfaire aux exigences ACID :

A - Atomique (atomicité). Toutes les modifications apportées à la transaction ou aucune du tout sont enregistrées.

C - Cohérence. Une fois la transaction terminée, l'état logique de la base de données doit être cohérent en interne. À bien des égards, cette exigence s'applique au programmeur, mais dans le cas des bases de données SQL, elle s'applique également aux clés étrangères.

I - Isoler (isolement). Les transactions parallèles ne devraient pas s’affecter.

D - Durable. Une fois la transaction terminée avec succès, les problèmes aux niveaux inférieurs (panne de courant, par exemple) ne devraient pas affecter les données modifiées par la transaction.

Les globaux sont des structures de données non relationnelles. Ils ont été créés pour un travail ultrarapide sur un matériel très limité. Voyons comment les transactions globales sont implémentées à l'aide de l' image Docker IRIS officielle .

Pour prendre en charge les transactions dans IRIS, les commandes suivantes sont utilisées: TSTART , TCOMMIT , TROLLBACK .

1. Atomicité

Le moyen le plus simple de vérifier l'atomicité. Vérification à partir de la console de base de données.

Kill ^a TSTART Set ^a(1) = 1 Set ^a(2) = 2 Set ^a(3) = 3 TCOMMIT 

Nous concluons ensuite:

 Write ^a(1), “ ”, ^a(2), “ ”, ^a(3) 

Nous obtenons:

 1 2 3 

Tout va bien. Atomicité observée: tous les changements sont enregistrés.

Nous compliquons la tâche, introduisons une erreur et voyons comment la transaction est enregistrée, partiellement ou pas du tout.

Vérifions à nouveau l'atomicité:

 Kill ^A TSTART Set ^a(1) = 1 Set ^a(2) = 2 Set ^a(3) = 3 

Ensuite, arrêtez de force le conteneur, démarrez et voyez.

 docker kill my-iris 

Cette commande est presque équivalente à une mise hors tension forcée, car elle envoie un signal pour arrêter immédiatement le processus SIGKILL.

Peut-être que la transaction a été partiellement enregistrée?

 WRITE ^a(1), ^a(2), ^a(3) ^ <UNDEFINED> ^a(1) 

- Non, pas conservé.

Testez la commande de restauration:

 Kill ^A TSTART Set ^a(1) = 1 Set ^a(2) = 2 Set ^a(3) = 3 TROLLBACK WRITE ^a(1), ^a(2), ^a(3) ^ <UNDEFINED> ^a(1) 

Rien n'a été conservé non plus.

2. Cohérence

Étant donné que dans les bases de données sur les globaux, les clés sont également créées sur les globaux (je rappelle qu'un global est une structure de niveau inférieur pour stocker des données qu'une table relationnelle), pour répondre à l'exigence de cohérence, vous devez inclure le changement de clé dans la même transaction que le changement global.

Par exemple, nous avons une personne globale ^ dans laquelle nous stockons des personnalités et nous utilisons le NIF comme clé.

 ^person(1234567, 'firstname') = 'Sergey' ^person(1234567, 'lastname') = 'Kamenev' ^person(1234567, 'phone') = '+74995555555 ... 

Afin d'avoir une recherche rapide par nom et prénom, nous avons fait la clé ^ index.

 ^index('Kamenev', 'Sergey', 1234567) = 1 

Pour que la base soit convenue, nous devons ajouter des personnalités comme celle-ci:

 TSTART ^person(1234567, 'firstname') = 'Sergey' ^person(1234567, 'lastname') = 'Kamenev' ^person(1234567, 'phone') = '+74995555555 ^index('Kamenev', 'Sergey', 1234567) = 1 TCOMMIT 

Par conséquent, lors de la suppression, nous devons également utiliser la transaction:

 TSTART Kill ^person(1234567) ZKill ^index('Kamenev', 'Sergey', 1234567) TCOMMIT 

En d'autres termes, la satisfaction de l'exigence de cohérence incombe entièrement au programmeur. Mais en ce qui concerne les globaux, c'est normal, en raison de leur nature de bas niveau.

3. Isolement

C'est là que les déserts commencent. De nombreux utilisateurs travaillent simultanément sur la même base de données, modifient les mêmes données.

La situation est comparable à la situation où de nombreux utilisateurs travaillent simultanément avec le même référentiel avec le code et tentent de valider des modifications sur plusieurs fichiers à la fois.

La base de données devrait résoudre ce problème en temps réel. Étant donné que dans les entreprises sérieuses, il y a même une personne spéciale qui est responsable du contrôle de version (pour la fusion des succursales, la résolution des conflits, etc.), et la base de données devrait faire tout cela en temps réel, la complexité de la tâche et la conception correcte de la base de données et le code qui le sert.

La base de données ne peut pas comprendre la signification des actions effectuées par les utilisateurs afin de prévenir les conflits s'ils travaillent sur les mêmes données. Il ne peut annuler qu'une transaction contrairement à une autre ou les exécuter séquentiellement.

Un autre problème est que pendant l'exécution de la transaction (avant la validation), l'état de la base de données peut être incohérent, il est donc souhaitable que d'autres transactions n'aient pas accès à l'état incohérent de la base de données, qui est obtenu dans les bases de données relationnelles de plusieurs manières: création d'instantanés, lignes multiversionnelles et etc.

Dans l'exécution parallèle de transactions, il est important pour nous qu'elles n'interfèrent pas entre elles. C'est la propriété de l'isolement.

SQL définit 4 niveaux d'isolement:

• LIRE NON ENGAGÉ
• LIRE ENGAGÉ
• LECTURE RÉPÉTABLE
• SÉRIALISABLE

Examinons chaque niveau séparément. Les coûts de mise en œuvre de chaque niveau augmentent presque exponentiellement.

LIRE NON ENGAGÉ est le niveau d'isolement le plus bas, mais le plus rapide. Les transactions peuvent lire les modifications apportées par l'autre.

READ COMMITTED est le prochain niveau d'isolement, qui est un compromis. Les transactions ne peuvent pas lire les modifications apportées par l'autre avant un commit, mais peuvent lire toutes les modifications apportées après un commit.

Si nous avons une longue transaction T1, au cours de laquelle il y a eu des validations dans les transactions T2, T3 ... Tn qui fonctionnaient avec les mêmes données que T1, alors lorsque nous demandons des données dans T1, nous obtiendrons des résultats différents à chaque fois. Ce phénomène est appelé lecture non répétable.

REPEATABLE READ - dans ce niveau d'isolement, nous n'avons pas le phénomène de lecture non répétable, car pour chaque demande de lecture de données, un instantané des données de résultat est créé et lorsqu'elles sont réutilisées dans la même transaction, les données de l'instantané sont utilisées. Cependant, à ce niveau d'isolement, les données fantômes peuvent être lues. Cela fait référence à la lecture de nouvelles lignes ajoutées par des transactions validées simultanées.

SERIALIZABLE est le plus haut niveau d'isolement. Il se caractérise par le fait que les données utilisées de quelque manière que ce soit dans la transaction (lecture ou modification) ne deviennent disponibles pour d'autres transactions qu'après la fin de la première transaction.

Commençons par déterminer s'il existe une isolation des opérations dans une transaction par rapport au thread principal. Ouvrons 2 fenêtres de terminal.

Il n'y a pas d'isolement. Un thread voit ce que fait le second qui a ouvert la transaction.

Voyons si les transactions de différents flux voient ce qui se passe à l'intérieur.

Nous ouvrons 2 fenêtres de terminal et ouvrons 2 transactions en parallèle.

Les transactions simultanées voient les données des autres. Nous avons donc obtenu le niveau d'isolement le plus simple, mais aussi le plus rapide LIRE NON COMMITÉ.

En principe, cela pourrait être prévu pour les mondiaux, pour qui la vitesse a toujours été primordiale.

Mais que faire si nous avons besoin d'un niveau d'isolement plus élevé dans les opérations mondiales?

Ici, vous devez vous demander pourquoi les niveaux d'isolation sont nécessaires et comment ils fonctionnent.

Le niveau d'isolement le plus élevé de SERIALIZE signifie que le résultat des transactions exécutées simultanément est équivalent à leur exécution séquentielle, ce qui garantit l'absence de collisions.

Nous pouvons le faire à l'aide de verrous compétents en ObjectScript, qui ont beaucoup de façons différentes d'appliquer: vous pouvez faire des verrous multiples réguliers et incrémentiels avec la commande LOCK .

Des niveaux d'isolement plus faibles sont des compromis conçus pour augmenter la vitesse de la base de données.

Voyons comment nous pouvons atteindre différents niveaux d'isolement à l'aide de verrous.

Cet opérateur vous permet de prendre non seulement les verrous exclusifs nécessaires pour modifier les données, mais aussi les verrous dits partagés, qui peuvent prendre plusieurs threads à la fois, lorsqu'ils ont besoin de lire des données qui ne devraient pas être modifiées par d'autres processus pendant la lecture.

Plus d'informations sur la méthode de verrouillage à deux phases en russe et en anglais:

→ Verrouillage biphasé
→ Verrouillage biphasé

La difficulté est que pendant la transaction, l'état de la base de données peut être incohérent, cependant, ces données incohérentes sont visibles par d'autres processus. Comment éviter cela?

En utilisant des verrous, nous ferons de telles fenêtres de visibilité dans lesquelles l'état de la base de données sera convenu. Et tous les appels à de telles fenêtres de visibilité de l'état convenu seront contrôlés par des verrous.

Les verrous partagés des mêmes données sont réutilisables - plusieurs processus peuvent les prendre. Ces verrous empêchent d'autres processus de modifier les données, c'est-à-dire ils sont utilisés pour former les fenêtres de l'état coordonné de la base de données.

Des verrous exclusifs sont utilisés pour modifier les données - un seul processus peut prendre un tel verrou. Le blocage exclusif peut prendre:

1. Tout processus si les données sont libres
2. Seul le processus qui a un verrou partagé sur ces données et le premier a demandé un verrou exclusif.

Plus la fenêtre de visibilité est étroite, plus il faut de temps aux autres processus pour attendre, mais plus l'état de la base de données peut être cohérent.

READ_COMMITED - l'essence de ce niveau est que nous ne voyons que les données d'autres flux qui sont verrouillés. Si les données d'une autre transaction ne sont pas encore validées, alors nous voyons leur ancienne version.

Cela nous permet de paralléliser le travail au lieu d'attendre que le verrou soit libéré.

Sans astuces spéciales, nous ne pourrons pas voir l'ancienne version des données dans IRIS, nous devons donc faire avec les verrous.

Par conséquent, nous devrons utiliser des verrous partagés pour permettre la lecture des données uniquement à des moments de cohérence.

Supposons que nous ayons une base d'utilisateurs ^ personne qui se transfère de l'argent.

Moment du transfert de la personne 123 à la personne 242:

 LOCK +^person(123), +^person(242) Set ^person(123, amount) = ^person(123, amount) - amount Set ^person(242, amount) = ^person(242, amount) + amount LOCK -^person(123), -^person(242) 

Le moment de demander le montant d'argent à la personne 123 avant le débit doit être accompagné d'un verrou exclusif (par défaut):

 LOCK +^person(123) Write ^person(123) 

Et si vous devez afficher l'état du compte dans votre compte, vous pouvez utiliser le verrouillage partagé ou ne pas l'utiliser du tout:

 LOCK +^person(123)#”S” Write ^person(123) 

Cependant, si nous supposons que les opérations de base de données sont effectuées presque instantanément (je me souviens que les globaux sont une structure de niveau beaucoup plus faible qu'une table relationnelle), alors le besoin de ce niveau diminue.

REPEATABLE READ - Dans ce niveau d'isolement, il est supposé qu'il peut y avoir plusieurs lectures de données qui peuvent être modifiées par des transactions simultanées.

En conséquence, nous devrons mettre un verrou partagé sur la lecture des données que nous modifions et des verrous exclusifs sur les données que nous modifions.

Heureusement, l'opérateur LOCK permet à un opérateur de répertorier en détail tous les verrous nécessaires, qui peuvent être très nombreux.

 LOCK +^person(123, amount)#”S”  ^person(123, amount) 

autres opérations (pour le moment, les threads parallèles tentent de changer ^ personne (123, montant), mais ne peuvent pas)

 LOCK +^person(123, amount)  ^person(123, amount) LOCK -^person(123, amount)  ^person(123, amount) LOCK -^person(123, amount)#”S” 

Lorsque vous répertoriez des verrous séparés par des virgules, ils sont pris de manière séquentielle, et si vous le faites:

 LOCK +(^person(123),^person(242)) 

puis ils sont pris atomiquement en une seule fois.

SÉRIALISER - nous devrons définir les verrous de sorte que finalement toutes les transactions qui ont des données communes soient exécutées séquentiellement. Pour cette approche, la plupart des serrures doivent être exclusives et prises dans les plus petites zones du monde pour des performances.

Si nous parlons de radiations dans la personne globale, alors seul le niveau d'isolement SERIALIZE lui est acceptable, car l'argent doit être dépensé strictement séquentiellement, sinon il est possible de dépenser le même montant plusieurs fois.

4. Durabilité

J'ai effectué des tests avec une découpe difficile du conteneur à travers

 docker kill my-iris 

La base les a bien tolérés. Aucun problème n'a été identifié.

Conclusion

Pour les pays du monde entier, InterSystems IRIS prend en charge les transactions. Ils sont vraiment atomiques, fiables. Pour garantir la cohérence de la base de données sur les globaux, les efforts du programmeur et l'utilisation des transactions sont nécessaires, car il n'y a pas de constructions intégrées complexes telles que des clés étrangères.

Le niveau d'isolement des globaux sans utilisation de verrous est LIRE NON COMMIS, et lors de l'utilisation de verrous, il peut être assuré jusqu'au niveau SERIALIZE.

L'exactitude et la rapidité des transactions sur les globaux dépendent beaucoup de la compétence du programmeur: plus les verrous partagés sont largement utilisés lors de la lecture, plus le niveau d'isolement est élevé et plus les verrous exclusifs sont pris, plus la vitesse est élevée.