Bonjour à tous. Ici Vladislav Rodin. Actuellement, je suis le responsable du cours « Architecte des charges élevées » chez OTUS, et j'enseigne également dans des cours consacrés à l'architecture des logiciels.
En plus de l'enseignement, comme vous l'avez peut-être remarqué, j'écris du contenu original pour le blog OTUS sur Habr, et je souhaite consacrer cet article au lancement d'un cours , pour lequel les inscriptions sont actuellement ouvertes.
Introduction
Dans Nous avons discuté du fait que les transactions dans les bases de données servent à résoudre deux problématiques : assurer la résilience et l'accès aux données dans un environnement concurrent. Pour exécuter pleinement ces tâches, une transaction doit posséder les propriétés ACID. Aujourd'hui, nous allons parler en détail de la lettre I (isolation) dans cet acronyme.
Isolation
L'isolation résout le problème de l'accès concurrent aux données, protégeant en fait contre les conditions de course. Idéalement, l'isolation signifie la sérialisation, c'est-à-dire une propriété garantissant que le résultat d'exécution des transactions de manière parallèle est identique à celui d'une exécution séquentielle. Le principal problème de cette propriété est qu'elle est très difficile à assurer techniquement et impacte considérablement les performances du système. C'est pourquoi l'isolation est souvent assouplie, en prenant le risque de certaines anomalies, dont nous parlerons plus bas. La possibilité d'occurrence de certaines anomalies caractérise justement le niveau d'isolation des transactions.
Les anomalies les plus connues sont : dirty read, non-repeatable read, phantom read, mais en réalité, il y en a encore 5 : dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
Le problème de l'anomalie est que des transactions peuvent écraser des données non validées.
Cette anomalie est dangereuse non seulement parce que les données peuvent entrer en conflit après la validation des deux transactions (comme le montre l'image), mais aussi parce qu'elle compromet l'atomicité : autoriser d'écrire sur des données non validées rend incertain comment annuler une transaction sans toucher à l'autre.
L'anomalie se résout assez simplement : on met un verrou sur l'écriture avant de commencer l'écriture, interdisant aux autres transactions de modifier l'enregistrement tant que le verrou n'est pas levé.
Dirty read
Dirty read signifie la lecture de données non validées.
Les problèmes surviennent lorsque des actions doivent être entreprises ou des décisions prises sur la base d'un échantillon.
Pour corriger l'anomalie, il est possible d'implémenter un verrouillage en lecture, mais cela affecterait considérablement les performances. Il est beaucoup plus simple de dire que pour le rollback d'une transaction, l'état d'origine des données (avant le début de l'écriture) doit être impérativement sauvegardé dans le système. Pourquoi ne pas lire à partir de là ? C'est assez peu coûteux, c'est pourquoi la plupart des bases de données désactivent la lecture sale par défaut.
Mise à jour perdue
La mise à jour perdue désigne des mises à jour perdues, et la traduction reflète assez précisément l'essence du problème :
En fait, le résultat de la transaction T2 a été annulé. Cette situation est corrigée par des verrouillages explicites ou implicites d'enregistrement. C'est-à-dire que nous effectuons soit simplement la mise à jour de l'enregistrement, et alors un verrouillage implicite se produit, soit nous exécutons select for update, provoquant l'apparition d'un verrouillage en lecture et en écriture. Notez que cette opération est assez risquée : en faisant une lecture « innocente », nous bloquons d'autres lectures. Certaines bases offrent un select for share, permettant de lire les données, mais n'autorisant pas les modifications.
Mise à jour perdue de curseur
Pour un contrôle plus fin, les bases peuvent proposer d'autres outils, comme les curseurs. Un curseur est une structure contenant un ensemble de lignes et permettant d'itérer sur celles-ci. declare cursor_name for select_statement. Le contenu du curseur est décrit par un select.
À quoi sert un curseur ? En effet, certaines bases de données proposent un verrouillage sur tous les enregistrements sélectionnés par le select (stabilité de lecture), ou uniquement sur l'enregistrement sur lequel se trouve le curseur (stabilité de curseur). Lors de la stabilité de curseur, un court verrouillage est effectué, ce qui permet de réduire le nombre de verrouillages lorsque nous itérons sur un grand échantillon de données. C'est pourquoi l'anomalie de mise à jour perdue est traitée séparément pour les curseurs.
Lecture non répétable
La lecture non répétable consiste à ce qu'au cours de l'exécution de notre transaction, 2 lectures consécutives du même enregistrement entraînent des résultats différents, car une autre transaction est intervenue entre ces deux lectures, a modifié nos données et a été validée.
Pourquoi cela pose-t-il un problème ? Imaginez que le but de la transaction T2 sur l'image est de sélectionner tous les produits dont le prix est inférieur à 150 unités. Quelqu'un a augmenté le prix à 200 unités. Par conséquent, le filtre établi ne fonctionne pas.
Ces anomalies cessent de se produire avec l'ajout de verrouillages à deux phases ou en utilisant le mécanisme MVCC, ce dont nous aimerions parler séparément.
Lecture fantôme
Une lecture est dite fantôme lorsqu'elle consiste à lire des données qui ont été ajoutées par une autre transaction.
Par exemple, on peut observer une sélection incorrecte du produit le moins cher lors de cette anomalie.
Éliminer les lectures fantômes est déjà assez compliqué. Un verrouillage ordinaire n'est pas suffisant, car nous ne pouvons pas verrouiller ce qui n'existe pas encore. Les systèmes 2PL utilisent des verrous prédicatifs, tandis que les systèmes MVCC annulant les transactions qui pourraient être perturbées par une insertion. Les deux mécanismes sont assez lourds.
Biais de lecture
Le biais de lecture se produit lorsque nous travaillons avec plusieurs tables dont le contenu doit changer de manière cohérente.
Supposons que nous ayons des tables représentant des publications et leurs métainformations :
Une transaction lit des tables, une autre les modifie :
À la suite de la transaction T1, la publication a title = Good, et updated_by = T2, ce qui constitue une certaine incohérence.
En réalité, il s'agit d'une lecture non répétable, mais dans le cadre de plusieurs tables.
Pour corriger cela, T1 peut verrouiller toutes les lignes qu'elle va lire, ce qui empêchera la transaction T2 de modifier les informations. Dans le cas de MVCC, la transaction T2 sera annulée. La protection contre cette anomalie peut être importante si nous utilisons des curseurs.
Biais d'écriture
Cet anomalie est également plus facile à expliquer par exemple : supposons qu'au moins un médecin doit être de garde dans notre système, mais que les deux médecins ont décidé d'annuler leur garde :
L'anomalie a conduit à ce qu'aucun médecin ne puisse être de garde. Pourquoi cela s'est-il produit ? Parce que la transaction a vérifié une condition qui peut être violée par une autre transaction, et en raison de l'isolement, nous n'avons pas vu ce changement.
C'est la même lecture non répétable. En option, des sélections peuvent verrouiller ces enregistrements.
Le write skew et le read skew sont des combinaisons des anomalies précédentes. On peut considérer le write skew, qui est en fait un phantom read. Prenons une table contenant les noms des employés, leurs salaires et le projet sur lequel ils travaillent :
En fin de compte, nous obtenons le tableau suivant : chaque manager pensait que son changement ne dépasserait pas le budget, c'est pourquoi ils ont apporté des modifications de personnel qui, au total, ont entraîné un dépassement des coûts.
La raison de l'apparition du problème est exactement la même que dans le cas du phantom read.
Conclusions
L'assouplissement du niveau d'isolation des transactions dans les bases de données est un compromis entre sécurité et performances, et ce choix doit être fait en fonction des risques potentiels pour l'entreprise en cas d'anomalies spécifiques.
Source : habr.com
