Transactions dans les globales InterSystems IRIS

La base de données InterSystems IRIS prend en charge des structures de données intéressantes : les globals. Il s'agit en réalité de clés multi-niveaux avec diverses fonctionnalités supplémentaires telles que des transactions, des fonctions rapides pour naviguer dans les arbres de données, des verrous et son propre langage, l'ObjectScript.

Pour en savoir plus sur les globals, consultez la série d'articles « Globals - des épées-léviers pour le stockage des données » :

Arbres. Partie 1
Arbres. Partie 2
Tableaux creux. Partie 3

Je me suis intéressé à la manière dont les transactions sont mises en œuvre dans les globals et aux spécificités associées. En effet, il s'agit d'une structure de stockage de données complètement différente des tables habituelles. Beaucoup plus bas niveau.

Comme il est connu dans la théorie des bases de données relationnelles, une bonne mise en œuvre des transactions doit satisfaire aux exigences suivantes : ACID:

A — Atomique. Tous les changements effectués dans la transaction sont enregistrés ou aucun.

C — Cohérence. Après la fin de la transaction, l'état logique de la base de données doit être intrinsèquement cohérent. Cette exigence concerne en grande partie le programmeur, mais dans le cas des bases de données SQL, elle concerne également les clés étrangères.

I — Isolation. Les transactions exécutées simultanément ne doivent pas s'influencer mutuellement.

D — Durabilité. Après une transaction réussie, des problèmes au niveau inférieur (comme une panne de courant, par exemple) ne doivent pas avoir d'effet sur les données modifiées par la transaction.

Les globals sont des structures de données non relationnelles. Elles ont été conçues pour un fonctionnement ultra-rapide sur du matériel très limité. Analysons la mise en œuvre des transactions dans les globals à l'aide de l'image Docker officielle d'IRIS..

Pour prendre en charge les transactions dans IRIS, on utilise les commandes : TSTART, TCOMMIT, TROLLBACK.

1. Atomicité

Il est le plus facile de vérifier l'atomicité. Vérifions depuis la console de la base de données.

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

Ensuite, faisons une sortie :

Write ^a(1), " ", ^a(2), " ", ^a(3)

Nous obtiendrons :

1 2 3

Tout est en ordre. L'atomicité est respectée : tous les changements ont été enregistrés.

Compliquons un peu la tâche, introduisons une erreur et voyons comment la transaction est conservé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, nous forcerons l'arrêt du conteneur, le relancerons et regarderons.

docker kill my-iris

Cette commande est pratiquement équivalente à une coupure de courant brutale, car elle envoie un signal d'arrêt immédiat du processus SIGKILL.

Une transaction a-t-elle pu être enregistrée partiellement ?

WRITE ^a(1), ^a(2), ^a(3)
^
 ^a(1)

— Non, cela ne s'est pas enregistré.

Testons la commande de rollback :

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

WRITE ^a(1), ^a(2), ^a(3)
^
 ^a(1)

Rien non plus ne s'est enregistré.

2. Cohérence

Étant donné que dans les bases de données, les clés sont également créées sur des globaux (rappelons que le global est une structure de stockage de données de niveau inférieur par rapport à une table relationnelle), pour satisfaire à l'exigence de cohérence, il faut inclure la modification de la clé dans la même transaction que la modification du global.

Par exemple, nous avons un global ^person, où nous stockons des personnalités et utilisons comme clé le numéro d'identification fiscale.

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

Pour avoir une recherche rapide par nom et prénom, nous avons créé la clé ^index.

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

Pour que la base de données soit cohérente, nous devons ajouter la personnalité comme suit :

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 une transaction :

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

En d'autres termes, le respect des exigences de cohérence repose entièrement sur les épaules du programmeur. Mais quand il s'agit de globaux, c'est normal en raison de leur nature de bas niveau.

3. Isolation

Ici, les choses se compliquent. Plusieurs utilisateurs travaillent simultanément sur la même base, modifiant les mêmes données.

La situation est comparable à celle où de nombreux utilisateurs travaillent simultanément sur le même dépôt de code et essaient de soumettre des modifications dans plusieurs fichiers en même temps.

La base de données doit gérer tout cela en temps réel. Étant donné que dans des entreprises sérieuses, il existe même une personne spéciale responsable du contrôle des versions (pour le fusionnement des branches, la résolution des conflits, etc.), tandis que la base de données doit faire tout cela en temps réel, il devient évident que la tâche est complexe et que la conception de la base de données et du code qui la maintient est cruciale.

La base de données ne peut pas comprendre le sens des actions effectuées par les utilisateurs afin d'éviter des conflits lorsqu'ils travaillent sur les mêmes données. Elle ne peut que valider une transaction qui contredit une autre ou les exécuter successivement.

Un autre problème est qu'au cours de l'exécution d'une transaction (avant le commit), l'état de la base peut être incohérent. Il est donc souhaitable que d'autres transactions n'aient pas accès à cet état incohérent, ce qui est réalisé dans les bases de données relationnelles de plusieurs manières : création de snapshots, multiversioning des lignes, etc.

Lors de l'exécution parallèle des transactions, il est important qu'elles ne s'interfèrent pas mutuellement. C'est ce qu'on appelle la propriété d'isolation.

SQL définit 4 niveaux d'isolation :

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

Examinons chaque niveau séparément. Les coûts de mise en œuvre de chaque niveau augmentent presque de manière exponentielle.

READ UNCOMMITTED — c'est le niveau d'isolation le plus bas, mais aussi le plus rapide. Les transactions peuvent lire les modifications apportées par d'autres.

READ COMMITTED — c'est le niveau d'isolation suivant, qui constitue un compromis. Les transactions ne peuvent pas lire les modifications effectuées par d'autres avant le commit, mais peuvent lire toutes les modifications apportées après le commit.

Si nous avons une longue transaction T1, pendant laquelle des commits ont eu lieu dans les transactions T2, T3,… Tn, qui ont travaillé avec les mêmes données que T1, alors lors de la requête dans T1, nous obtiendrons à chaque fois un résultat différent. Ce phénomène est appelé lecture non répétable.

REPEATABLE READ — à ce niveau d'isolation, il n'y a pas de phénomène de lecture non répétable, car pour chaque requête de lecture de données, un snapshot des données résultantes est créé et, lors d'une réutilisation dans cette même transaction, les données du snapshot sont utilisées. Cependant, à ce niveau d'isolation, il est possible de lire des données fantômes. Cela signifie lire de nouvelles lignes qui ont été ajoutées par des transactions parallèles validées.

SERIALIZABLE — le niveau d'isolation le plus élevé. Il se caractérise par le fait que les données utilisées d'une manière ou d'une autre dans la transaction (lecture ou modification) ne deviennent accessibles à 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 la transaction par rapport au flux principal. Ouvrons 2 fenêtres de terminal.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Il n'y a pas d'isolation. Un flux voit ce que fait l'autre qui a ouvert la transaction.

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

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

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Les transactions parallèles se voient mutuellement leurs données. Ainsi, nous avons obtenu le niveau d'isolation le plus simple mais le plus rapide, READ UNCOMMITTED.

Cela pouvait être attendu pour les globaux, pour lesquels la performance a toujours été prioritaire.

Que faire si nous avons besoin d'un niveau d'isolation plus élevé pour les opérations sur les globaux ?

Il faut réfléchir à pourquoi il est nécessaire d'avoir des niveaux d'isolation et comment ils fonctionnent.

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

Nous pouvons atteindre cela grâce à des verrouillages adéquats dans ObjectScript, qui ont de nombreuses façons d'être appliqués : on peut faire une verrouillage ordinaire, incrémentale ou multiple avec la commande LOCK.

Des niveaux d'isolation plus bas représentent des compromis visant à augmenter la vitesse de fonctionnement de la base de données.

Voyons comment nous pouvons atteindre différents niveaux d'isolation grâce aux verrouillages.

Cet opérateur permet de prendre non seulement des verrouillages exclusifs, nécessaires pour modifier des données, mais aussi des verrouillages partagés, qui peuvent être pris simultanément par plusieurs flux lorsqu'ils ont besoin de lire des données qui ne doivent pas être modifiées par d'autres processus pendant la lecture.

Plus d'informations sur la méthode des verrouillages en deux phases en russe et en anglais :

→ Verrouillage en deux phases
→ Two-phase locking

La difficulté réside dans le fait qu'au cours de 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 ?

Nous créerons à l'aide de verrouillages des fenêtres de visibilité dans lesquelles l'état de la base sera cohérent. Et toutes les demandes à de telles fenêtres de visibilité d'état cohérent seront contrôlées par des verrouillages.

Les verrous partagés sur les mêmes données sont réutilisables : plusieurs processus peuvent les acquérir. Ces verrouillages interdisent à d'autres processus de modifier les données, c'est-à-dire qu'ils sont utilisés pour former des fenêtres d'état cohérent de la base de données.

Les verrous exclusifs sont utilisés pour modifier les données : un tel verrou peut être acquis uniquement par un seul processus. Un verrou exclusif peut être acquis par :

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

Plus la fenêtre de visibilité est étroite, plus les autres processus doivent attendre longtemps, mais plus l'état de la base de données peut être cohérent dans celle-ci.

READ_COMMITED — l'essence de ce niveau est que nous voyons uniquement les données validées d'autres flux. Si les données dans une autre transaction ne sont pas encore validées, 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, il nous faudra donc nous contenter de verrous.

Par conséquent, nous devrons permettre la lecture des données uniquement lors de moments de cohérence à l'aide de verrous partagés.

Supposons que nous avons une base d'utilisateurs ^person qui se transfèrent de l'argent.

Le 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 la requête du montant d'argent chez 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 nous devons afficher l'état du compte dans l'espace personnel, nous pouvons utiliser un verrou partagé ou ne pas en utiliser du tout :

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

Cependant, supposons que les opérations de gestion de la base de données se déroulent presque instantanément (je rappelle que les globales sont une structure beaucoup plus basse niveau que la table relationnelle), alors la nécessité de ce niveau diminue.

REPEATABLE READ — à ce niveau d'isolation, il est permis qu'il y ait plusieurs lectures de données qui peuvent être modifiées par des transactions parallèles.

Par conséquent, nous devrons établir un verrou partagé sur les données que nous modifions et des verrous exclusifs sur les données que nous changeons.

L'opérateur LOCK permet de spécifier en détail toutes les verrouillages nécessaires dans un seul opérateur, ce qui peut être très nombreux.

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

d'autres opérations (pendant ce temps, des flux parallèles tentent de modifier ^person(123, amount), mais ne peuvent pas)

LOCK +^person(123, amount)
modifier ^person(123, amount)
LOCK -^person(123, amount)

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

Lors de l'énumération des verrouillages séparés par des virgules, ceux-ci sont pris séquentiellement, mais si l'on fait ainsi :

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

ils sont alors pris atomiquement tous en même temps.

SÉRIALISER — nous devrons définir des verrouillages de manière à ce que, finalement, toutes les transactions qui ont des données communes s'exécutent de manière séquentielle. Pour cette approche, la plupart des verrouillages doivent être exclusifs et pris aux plus petites régions du global pour des performances optimales.

En ce qui concerne les débits dans le global ^person, seul le niveau d'isolation SÉRIALISER est acceptable, car l'argent doit être dépensé strictement de manière séquentielle, sinon il est possible de dépenser la même somme plusieurs fois.

4. Durabilité

J'ai effectué des tests avec une coupure brutale du conteneur par

docker kill my-iris

La base les a bien supportés. Aucun problème n'a été détecté.

Conclusion

Pour les globals dans InterSystems IRIS, le support des transactions est en place. Elles sont réellement atomiques et fiables. Cependant, pour garantir la cohérence de la base de données dans les globals, des efforts du programmeur et l'utilisation de transactions sont nécessaires, car il n'y a pas de constructions complexes intégrées comme les clés étrangères.

Le niveau d'isolation des globals sans utilisation de verrouillages est READ UNCOMMITTED, et avec l'utilisation de verrouillages, il peut atteindre jusqu'au niveau SÉRIALISER.

La justesse et la rapidité des transactions sur les globals dépendent fortement des compétences du programmeur : plus les verrouillages partagés sont largement utilisés lors de la lecture, plus le niveau d'isolation est élevé, et plus les verrouillages exclusifs sont étroitement pris, plus la rapidité est importante.

Source : habr.com