Salut tout le monde. Vladislav Rodin est en contact. Je suis actuellement responsable du cours High Workload Architect à l'OTUS et j'enseigne également des cours d'architecture logicielle.
En plus d'enseigner, comme vous l'avez peut-être remarqué, j'écris du matériel original pour le blog OTUS sur Habré et je souhaite que l'article d'aujourd'hui coïncide avec le lancement du cours. , qui est ouvert aux inscriptions dès maintenant.
introduction
В nous avons évoqué le fait que les transactions dans les bases de données servent à résoudre deux problèmes : assurer la tolérance aux pannes et l'accès aux données dans un environnement concurrentiel. Pour effectuer pleinement ces tâches, la transaction doit avoir des propriétés ACID. Aujourd'hui, nous parlerons en détail de la lettre Je (isolement) dans cette abréviation.
Isolation
L'isolement résout le problème de l'accès aux données dans un environnement concurrentiel, en offrant essentiellement une protection contre les conditions de concurrence. Idéalement, l'isolation signifie la sérialisation, qui est une propriété qui garantit que le résultat de l'exécution des transactions en parallèle est le même que si elles étaient exécutées séquentiellement. Le principal problème de cette propriété est qu’elle est très difficile à réaliser techniquement et, par conséquent, a un impact significatif sur les performances du système. C’est pourquoi l’isolement est souvent fragilisé, acceptant les risques de certaines anomalies, qui seront évoquées ci-dessous. La possibilité que certaines anomalies se produisent caractérise précisément le niveau d'isolement des transactions.
Les anomalies les plus connues sont : lecture sale, lecture non répétable, lecture fantôme, mais en fait il y en a 5 autres : écriture sale, mise à jour perdue du curseur, mise à jour perdue, biais de lecture, biais d'écriture.
Écriture sale
L'essence de l'anomalie est que les transactions peuvent écraser les 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 dans l'image), mais aussi parce que l'atomicité est violée : puisque nous autorisons l'écrasement des données non validées, il n'est pas clair comment annuler une transaction sans en affecter une autre. .
L'anomalie peut être traitée assez simplement : nous attachons un verrou à l'enregistrement avant de démarrer l'enregistrement, interdisant aux autres transactions de modifier l'enregistrement jusqu'à ce que le verrou soit supprimé.
Sale lecture
Une lecture sale signifie lire des données non validées.
Des problèmes surviennent lorsque des actions ou des décisions doivent être prises sur la base de l'échantillon.
Pour corriger l'anomalie, vous pouvez attacher un verrou en lecture, mais cela aura un impact considérable sur les performances. Il est beaucoup plus simple de dire que pour une transaction de rollback, l'état initial des données (avant le début de l'enregistrement) doit être sauvegardé dans le système. Pourquoi ne pas lire à partir de là ? C'est suffisamment peu coûteux pour que la plupart des bases de données suppriment les lectures sales par défaut.
Mise à jour perdue
Une mise à jour perdue signifie des mises à jour perdues, et la traduction reflète assez fidèlement l'essence du problème :
En fait, le résultat de la transaction T2 a été annulé. Cette situation peut être corrigée par des verrous en écriture explicites ou implicites. Autrement dit, soit nous mettons simplement à jour l'enregistrement, puis un verrouillage implicite se produit, soit nous effectuons sélectionner pour la mise à jour, provoquant un verrouillage en lecture et en écriture. Attention, une telle opération est assez dangereuse : avec notre lecture « innocente », nous bloquons les autres lectures. Certaines bases de données offrent des fonctionnalités plus sécurisées sélectionner pour partager, permettant aux données d'être lues mais non modifiées.
Le curseur a perdu la mise à jour
Pour un contrôle plus fin, les bases peuvent proposer d'autres outils, comme un curseur. Un curseur est une structure qui contient un ensemble de lignes et vous permet de les parcourir. déclarer le nom_curseur pour select_statement. Le contenu du curseur est décrit par select.
Pourquoi avez-vous besoin d'un curseur ? Le fait est que certaines bases de données proposent un verrouillage sur tous les enregistrements sélectionnés par select (stabilité de lecture), ou uniquement sur l'enregistrement sur lequel se trouve actuellement le curseur (stabilité du curseur). Avec la stabilité du curseur, un verrouillage court est implémenté, ce qui nous permet de réduire le nombre de verrous si nous parcourons un grand échantillon de données. Par conséquent, l’anomalie de mise à jour perdue est isolée séparément pour le curseur.
Lecture non répétable
La lecture non répétable est que lors de l'exécution de notre transaction, 2 lectures consécutives du même enregistrement conduiront à 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 est-ce même un problème ? Imaginez que l'objectif de la transaction T2 dans l'image soit de sélectionner tous les biens dont le prix est inférieur à 150 USD. Quelqu'un d'autre a mis à jour le prix à 200 $. Ainsi, le filtre installé n'a pas fonctionné.
Ces anomalies cessent de se produire lorsque des verrouillages biphasés sont ajoutés ou lorsque le mécanisme MVCC est utilisé, dont je voudrais discuter séparément.
Lecture fantôme
Phantom est une lecture de données ajoutées par une autre transaction.
A titre d’exemple, on peut observer la mauvaise sélection du produit le moins cher lorsque cette anomalie se produit.
Se débarrasser des lectures fantômes est déjà assez difficile. Un blocage régulier ne suffit pas, car nous ne pouvons pas bloquer quelque chose qui n’existe pas encore. Les systèmes 2PL utilisent le verrouillage prédictif, tandis que les systèmes MVCC disposent d'un planificateur de transactions qui annule les transactions susceptibles d'être perturbées par une insertion. Les premier et deuxième mécanismes sont assez lourds.
Lire le biais
Le biais de lecture se produit lorsque nous travaillons avec plusieurs tables dont le contenu doit changer de manière cohérente.
Disons que nous avons des tableaux représentant les publications et leurs méta-informations :
Une transaction lit les tables, l'autre les modifie :
À la suite de la transaction T1, la publication a title = Good et update_by = T2, ce qui constitue une sorte d'incohérence.
En fait, il s'agit d'une lecture non répétable, mais faisant partie de plusieurs tableaux.
Pour résoudre ce problème, T1 peut verrouiller toutes les lignes qu'il lira, ce qui empêchera la transaction T2 de modifier les informations. En cas de MVCC, la transaction T2 sera annulée. La protection contre cette anomalie peut devenir importante si l'on utilise des curseurs.
Inclinaison d'écriture
Cette anomalie est également plus facile à expliquer avec un exemple : supposons que dans notre système au moins un médecin soit de garde, mais que les deux médecins décident d'annuler leur garde :
L’anomalie signifiait qu’aucun des médecins ne serait de garde. Pourquoi est-ce arrivé? Parce que la transaction vérifiait une condition qui pourrait être violée par une autre transaction, et en raison de l'isolement, nous n'avons pas constaté ce changement.
Il s’agit de la même lecture non répétable. Alternativement, les sélections peuvent placer des verrous sur ces enregistrements.
Le biais d’écriture et le biais de lecture sont des combinaisons des anomalies précédentes. Vous pouvez envisager un biais d'écriture, qui est essentiellement une lecture fantôme. Prenons un tableau contenant les noms des employés, leurs salaires et le projet sur lequel ils travaillent :
En conséquence, nous obtenons le tableau suivant : chaque manager pensait que son changement n'entraînerait pas de dépassement du budget, ils ont donc procédé à des changements de personnel qui, ensemble, ont conduit à des dépassements de coûts.
La cause du problème est exactement la même que celle de la lecture fantôme.
résultats
L'assouplissement du niveau d'isolement des transactions dans la base de données est un compromis entre sécurité et performances ; le choix de ce niveau doit être abordé en fonction des risques potentiels pour l'entreprise si certaines anomalies surviennent.
Source: habr.com