🦌 👨🏼‍🎨 💠 MVCC comme moyen d'assurer l'isolement des transactions 🌝 🏇🏾 🎋

Salut, Habr. Je m'appelle Vladislav Rodin. Actuellement, je dirige le cours d'architecte à charge élevée d'OTUS et j'enseigne également des cours sur l'architecture logicielle.

Surtout pour le début d'un nouvel ensemble pour le cours "Architecte de fortes charges", j'ai écrit un petit matériel que je partage volontiers avec vous.

introduction

La dernière fois, nous vous avons parlé des conséquences de l'affaiblissement de l'isolement des transactions dans les bases de données. Aujourd'hui, nous allons discuter plus en détail de l'un des moyens d'assurer cet isolement et d'éviter les anomalies considérées. Comme vous l'avez peut-être remarqué, dans le dernier article, deux approches ont souvent été distinguées: l'une était basée sur le fait que les enregistrements ont certaines versions , et la seconde sur le fait que nous bloquerons l' enregistrement d'une manière ou d'une autre . Ainsi, deux classes de bases de données sont distinguées: les versions et les bloqueurs . Aujourd'hui, nous allons parler de ce que sont les contrôleurs de version et laissons la considération des bloqueurs la prochaine fois.

Versionionistes

Comme je l'ai dit, l'une des approches est basée sur la gestion des versions. Elle est également appelée approche optimiste ou MVCC (contrôle de concurrence multiversionnelle) . En fait, le stockage des versions pour les transactions actives se produit.

Où sont stockées les versions?

La mise en œuvre du mécanisme dépend de la base de données. Je vais en donner quelques exemples.

PostgreSQL

Chaque transaction est caractérisée par un id-shnik. Les transactions id-shnik se développent de façon monotone. Toute ligne a 2 attributs qui représentent des méta-informations pour fournir le mécanisme: updated_by_id - id de la transaction qui a mis à jour cet enregistrement en dernier et supprimé_by_id - id de la transaction qui a supprimé cet enregistrement. Lorsqu'une nouvelle transaction arrive, la base de données détermine les pseudos des transactions en cours d'exécution, les modifications apportées par ces transactions seront ignorées dans la transaction entrante. Il s'avère que la transaction entrante fonctionne comme avec sa version des données. Les anciennes versions des données sont stockées au même endroit que les versions actuelles. Si la mise à jour arrive, une autre ligne est ajoutée et cet enregistrement devient actif. Il est également clair que pour le bon fonctionnement de ce schéma, un "garbage collector" est requis:si un enregistrement a supprimé_par_id = 100 et que l'id-shnik minimum parmi les transactions en cours est 150, cet enregistrement doit être supprimé.

MySQL (moteur InnoDB)

Seule la version actuelle est stockée dans la base de données MySQL. Lorsque la mise à jour arrive, les données à l'intérieur du fichier de table sont corrigées. Après avoir ajusté les données, la version précédente se trouve dans le journal de restauration. Il existe plusieurs journaux de restauration dans MySQL (ils sont différents pour insert'ov et update'ov). Si une transaction nécessite une version précédente de la ligne, le système annule le journal et restaure la version nécessaire. La version est également déterminée par l'ID de transaction.

Oracle

Le schéma est similaire à MySQL: les versions actuelles sont stockées dans le fichier de données, les anciennes versions sont restaurées grâce au journal d'annulation. Le journal d'annulation dans Oracle est réécrit cycliquement. Par conséquent, une situation est possible lorsqu'une transaction a besoin d'une très ancienne version de l'enregistrement, mais dans le journal d'annulation, elle n'est plus là. Si cette situation se produit, la transaction échouera.

MS SQL

MS SQL permet l'inclusion des modes versionioner et blocker. Pour activer le mode versionné dans les paramètres de la base de données, vous devez activer les instantanés. Dans MS SQL, il existe une table système (tempdb), conçue pour stocker des tables temporaires. C'est tempdb qui est utilisé pour stocker les anciennes versions, tandis que le tableau contient les versions actuelles. Le processus système surveille que dans tempdb il existe des versions auxquelles personne ne fait référence, elles peuvent être supprimées. Si la transaction est longue, les versions seront enregistrées pour elle. Tempdb grandit, atteint sa taille maximale, MS SQL alloue un peu d'espace disque. S'il se termine, les transactions avec l'isolement d'instantané ne peuvent pas être effectuées. Si ce mode de fonctionnement est utilisé, il est nécessaire de surveiller les transactions longues,car le retour en arrière d'une telle transaction dans le temps peut coûter autant que cela fonctionne, et peut-être un peu plus.

Conflits

Cette approche est qualifiée d'optimiste, car nous espérons qu'il n'y aura pas de conflit si des transactions de changement de données parallèles sont exécutées. Que se passe-t-il en cas de conflit? Supposons que la transaction T1 modifie 10 000 enregistrements et la transaction T2 modifie 1 enregistrement en parallèle. S'il arrivait que ce 1 enregistrement soit inclus dans ces 10 000, alors l'une des transactions sera annulée: si T1 est exécuté en premier, alors T2 sera annulé, sinon l'inverse.

Mécanisme de retour en arrière

Le mécanisme de restauration des transactions dans les versions versionnées dépend de l'implémentation. Par exemple, dans PostgreSQL, une transaction est marquée comme évacuée et le vide libère de l'espace disque. Un tel mécanisme est assez rapide. Dans Oracle, pour la restauration, les données sont restaurées à partir du journal d'annulation. Dans ce cas, le temps de fonctionnement augmente, cependant, il est encore beaucoup plus rapide que dans les casiers. MySQL fonctionne de la même manière qu'Oracle.

Conclusion

L'approche optimiste est bonne car l'écrivain ne bloque pas le lecteur, le lecteur lit simplement sa version des données. Par conséquent, la gestion des versions est bénéfique si le fardeau principal concerne la lecture plutôt que l'écriture (blog, rapports et autres cas où vous devez lire souvent et beaucoup).

En savoir plus sur le cours ici.

MVCC comme moyen d'assurer l'isolement des transactions