🌖 👨🏾‍🏭 👨🏼‍🔧 Quel est le volume de marketing chez ACID? 💮 💴 📚

Bonjour à tous. En contact avec Vladislav Rodin. Je suis actuellement responsable du cours Architecte High Load chez OTUS et j'enseigne également des cours sur l'architecture logicielle.

En plus d'enseigner, comme vous l'avez peut-être remarqué, j'écris également du matériel pour le blog OTUS sur le Haber et je veux coïncider avec l'article d'aujourd'hui pour lancer le cours "Bases de données" , qui est maintenant ouvert au recrutement.

Préface

Les transactions sont apparues dans les années 70 et ont été présentées comme un outil de base de données pour résoudre les problèmes de tolérance aux pannes et d'accès aux données dans un environnement concurrentiel. Ensuite, un certain nombre de propriétés ont été formulées qu'une transaction doit posséder afin de remplir les tâches qui lui sont assignées, et les lettres majuscules de ces propriétés, définies dans le bon ordre, constituaient le magnifique acronyme ACID.

La période au cours de laquelle ces événements ont eu lieu a été caractérisée par l'absence de charges élevées, d'Internet et de problèmes de performances, qui ne pouvaient être résolus que par des méthodes de mise à l'échelle verticale. Par la suite, au début des années 2000, une tendance est apparue sur les bases de données NoSQL, l'abréviation BASE est apparue, ce qui était en fait opposé à l'ACID classique (ACID - acide, BASE - alcalin). Il y a maintenant une tendance inverse pour ACID. Même MongoDB de NoSQL prend désormais en charge ACID.

Voyons ce que signifie cette abréviation et combien elle a de marketing.

ACID représente 4 propriétés:

A = atomicité
C = cohérence
I = isolement
D = durabilité

Parlons maintenant de chaque propriété séparément.

A = atomicité

L'atomicité est un terme surchargé et dans le contexte des transactions dans une base de données peut être formulé comme le principe du «tout ou rien». Si votre transaction contient 10 opérations d'insertion, toutes les 10 seront exécutées (les transactions de validation seront effectuées), ou aucune d'entre elles (les transactions de restauration seront effectuées).

Comment cette propriété est-elle fournie? Le fait est que lorsqu'une transaction contenant ces mêmes 10 insertions arrive dans la base de données, les données ne commencent pas à changer. Avant une transaction, la transaction est écrite directement dans les données d'un journal, dans lequel les modifications apportées par celle-ci sont enregistrées. Ce journal peut également être utilisé pour répliquer des données, ou il peut être complètement sans rapport avec elles, comme je l'ai décrit, par exemple, ici. Grâce à ce journal, les transactions peuvent être validées directement sur les données ou, dans ce cas, les annuler. La règle selon laquelle une transaction doit être clôturée dès que possible découle directement de la compréhension des principes de mise en œuvre de cette propriété: les bases de données sont souvent interdites de nettoyer ce journal pendant qu'une transaction est ouverte, de sorte qu'il peut se boucher, ce qui, à son tour, entraîne des conséquences très désagréables.

C = cohérence (cohérence ou intégrité)

En termes d'ACID, la cohérence ne signifie pas la même chose qu'en termes de théorème CAP (dans la théorie des systèmes distribués, il y a plusieurs degrés de cette cohérence). Par cohérence, nous entendons ce qui suit: certains invariants prédéfinis du système doivent être exécutés à la fois avant et après la transaction de validation. Des exemples d'invariants du système peuvent être représentés: le débit converge avec le prêt, le salaire total des employés ne dépasse pas le budget, le nombre d'employés dans l'entreprise est égal au nombre de postes vacants précédemment ouverts, etc. Dans le langage de la base de données, cela ne signifie que le respect de toutes les contraintes.

La question de la nécessité d'une cohérence au niveau de la base de données est assez controversée, car la présence de contraintes peut indiquer qu'une partie de la logique métier est passée de l'application au niveau de la base de données, ce qui n'est pas universellement reconnu comme une bonne pratique. Au final, l'application elle-même peut décider de ne pas valider de données non valides. Il y a une opinion que la cohérence n'a été ajoutée que pour rendre l'abréviation belle (marketing).

I = isolement

L'isolement est une propriété de base de données qui permet d'exécuter des transactions parallèles de manière séquentielle. Après tout, personne n'interdit à la base de données d'effectuer plusieurs transactions en même temps, il faut s'assurer qu'elles ne s'influencent pas mutuellement, afin que des anomalies de la forme de la condition de concurrence ne se produisent pas. En fait, c'est l'isolement qui résout le problème de l'accès aux données dans un environnement concurrentiel.

La divulgation du concept d'isolement en raison de son volume mérite un article séparé., car c'est précisément l'isolement qui peut être appelé le cœur de l'ACID. Le prix de la transactionnalité se résume souvent au prix de l'isolement, c'est pourquoi l'isolement a différents niveaux, chacun offrant son propre niveau de protection contre les conditions raciales et entraînant l'un ou l'autre des frais généraux. L'isolement n'est pleinement assuré qu'au niveau sérialisable, ce qui est très difficile à mettre en œuvre et rarement nécessaire.

D = durabilité

La durabilité nous dit que si une transaction a été appliquée, elle ne doit en aucun cas disparaître. En fait, cela signifie ce qui suit: si la base de données a répondu qu'une transaction a été validée, la transaction a été validée dans la mémoire non volatile. Cela signifie que l'appel système fsync s'est produit, c'est-à-dire que les tampons ont été vidés sur le disque dur et qu'il a répondu ok.

La durabilité est également un terme marketing, car elle ne peut pas être entièrement fournie. Même si nous rejetons les scénarios artificiels de «brûler la Terre par des extraterrestres», après quoi il n'y aura plus de bases de données ou de transactions, des scénarios plus probables mais extrêmes de destruction physique d'un disque dur particulier sur lequel la transaction a été enregistrée, nous pouvons nous rappeler que les garanties d'appel du système fsync frapper un disque dur dans le contrôleur, qui, à son tour, contient toujours un tampon volatil. Le temps passé dedans est court, mais pas égal à 0. Par conséquent, si vous coupez l'électricité exactement au «bon» moment, la transaction peut toujours être perdue!

Bien que le problème avec fsync ait été résolu dans une base de données Oracle coûteuse, rien ne peut nous protéger des problèmes liés à la destruction physique de la machine. Nous ne pouvons augmenter les garanties qu'en utilisant les sauvegardes et la réplication .

résultats

Malgré le fait qu'ACID offre des propriétés assez intéressantes, telles que l'atomicité et l'isolement, certaines de ces propriétés ne sont que du marketing, et même connues pour leur rigueur par rapport à BASE, ACID ne garantit pas pleinement l'absence d'opportunités de perte de transaction, ainsi que l'impact des résultats effectuer des transactions simultanées les unes sur les autres (l'isolement doit encore être configuré!).

Nous invitons tout le monde à une leçon gratuite sur le sujet: "Un modèle pour travailler avec des données dans PostgreSQL . "