🤳🏻 ☹️ ⬅️ Ce qui peut résulter de l'affaiblissement du niveau d'isolement des transactions dans les bases de données ☀️ 👨🏻‍✈️ 🧑🏿‍🤝‍🧑🏽

Bonjour à tous. En contact avec Vladislav Rodin. Actuellement, je dirige le cours d'architecte à charge élevée d'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 hub et je veux coïncider avec l'article d'aujourd'hui pour lancer le cours "PostgreSQL" , qui est actuellement ouvert au recrutement.

introduction

La dernière fois que vous et moi avons parlé de cette transaction dans des bases de données utilisées à deux fins: garantir la tolérance aux pannes et l'accès aux données dans un environnement concurrentiel. Pour effectuer ces tâches, une transaction doit avoir des propriétés ACID. Aujourd'hui, nous parlerons en détail de la lettre I (isolement) dans cette abréviation.

Isolation

L'isolement résout le problème d'accès aux données dans un environnement compétitif, offrant une protection efficace contre les conditions de course. Idéalement, l'isolement signifie la sérialisation, c'est-à-dire 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 à fournir techniquement et, par conséquent, affecte considérablement les performances du système. C'est pourquoi l'isolement est souvent affaibli, acceptant les risques de certaines anomalies, qui seront discutés ci-dessous. La possibilité de l'apparition de certaines anomalies caractérise tout de même le niveau d'isolement des transactions.

Les anomalies les plus célèbres sont: lecture sale, lecture non répétable, lecture fantôme, mais en fait il y en a 5 de plus: écriture sale, mise à jour du curseur perdue, mise à jour perdue, lecture asymétrique, écriture asymétrique.

Écriture sale

L'essence de l'anomalie est que les transactions peuvent remplacer les données non validées.

Cette anomalie est dangereuse non seulement parce que les données peuvent entrer en conflit après avoir validé les deux transactions (comme dans l'image), mais aussi parce que l'atomicité est violée: parce que nous autorisons le remplacement des données non verrouillées, il n'est pas clair comment annuler une transaction sans toucher l'autre. .

L'anomalie est traitée de manière très simple: nous raccrochons le verrou d'écriture avant le début de l'enregistrement, interdisant aux autres transactions de modifier l'enregistrement jusqu'à ce que le verrou soit libéré.

Lecture sale

Une lecture sale signifie lire des données non validées.

Des problèmes surviennent lorsque, sur la base d'un échantillon, il est nécessaire d'effectuer certaines actions ou de prendre des décisions.

Pour corriger l'anomalie, vous pouvez bloquer un verrou de lecture, mais cela affectera fortement les performances. Il est beaucoup plus simple de dire que pour une transaction de restauration, l'état initial des données (avant l'enregistrement) doit être stocké dans le système. Pourquoi ne pas lire à partir de là? C'est assez peu coûteux, donc la plupart des bases de données suppriment la lecture sale par défaut.

Mise à jour perdue

Une mise à jour perdue signifie des mises à jour perdues et la traduction reflète avec précision l'essence du problème:

en fait, le résultat de la transaction T2 a été annulé. Cette situation est corrigée par des verrous d'écriture explicites ou implicites. Autrement dit, soit nous mettons simplement à jour l'enregistrement, puis un verrouillage implicite se produit, soit nous effectuons une sélection pour la mise à jour , provoquant un verrouillage en lecture et en écriture. Veuillez noter qu'une telle opération est assez dangereuse: avec notre lecture «innocente», nous bloquons les autres lectures. Certaines bases de données offrent une sélection de partage plus sécurisée qui vous permet de lire des données, mais ne leur permet pas de changer.

Mise à jour du curseur perdue

Pour un contrôle plus fin, les bases peuvent offrir d'autres outils, par exemple un curseur. Un curseur est une structure qui contient un ensemble de lignes et vous permet de les parcourir. déclarez curseur_nom pour select_statement . Le contenu du curseur est décrit par select.

Pourquoi avons-nous 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 verrou court est implémenté, ce qui nous permet de réduire le nombre de verrous si nous itérons sur un grand échantillon de données. Par conséquent, l'anomalie de mise à jour perdue est mise en évidence 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 changé nos données et a été validée.

Pourquoi est-ce un problème? Imaginez que le but de la transaction T2 dans l'image est de sélectionner tous les produits dont le prix est inférieur à 150 cu 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 verrous biphasés sont ajoutés ou lorsque vous utilisez le mécanisme MVCC, dont je voudrais parler séparément.

Lecture fantôme

Phantom lit des données qui ont été ajoutées par une autre transaction.

À titre d'exemple, vous pouvez 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 normal ne suffit pas, car nous ne pourrions pas bloquer ce qui n'est pas encore disponible. Les systèmes 2PL utilisent le verrouillage prédictif, tandis que les systèmes MVCC utilisent un planificateur de transactions pour annuler les transactions qui pourraient être interrompues par un insert. Les premier et deuxième mécanismes sont assez lourds.

Lire biais

Le biais de lecture survient lorsque nous travaillons avec plusieurs tableaux, dont le contenu doit changer de manière cohérente.

Supposons qu'il existe des tableaux représentant les publications et leurs méta-informations:

une transaction lit les tables, une autre les modifie: à

la suite de la transaction T1, la publication a title = Good et updated_by = T2, ce qui est une certaine incohérence.

En fait, il s'agit d'une lecture non répétable, mais faisant partie de plusieurs tableaux.

Pour la correction, T1 peut raccrocher les verrous sur toutes les lignes qu'il lira, ce qui empêchera T2 de changer les informations. Dans le cas de MVCC, la transaction T2 sera annulée. La protection contre cette anomalie peut devenir importante si nous utilisons des curseurs.

Écrire de biais

Cette anomalie est également plus facile à expliquer à l'aide d'un exemple: supposons que dans notre système, au moins un médecin doit être en service, mais les deux médecins décident d'annuler leur service: l'

anomalie a conduit au fait qu'aucun des médecins ne sera en service. Pourquoi est-ce arrivé? Étant donné que la transaction a vérifié une condition qui pourrait être violée par une autre transaction et en raison de l'isolement, nous n'avons pas vu cette modification.

Il s'agit de la même lecture non répétable. Alternativement, les sélections peuvent accrocher des verrous sur ces enregistrements.

L'écriture asymétrique et la lecture asymétrique sont des combinaisons d'anomalies précédentes. Vous pouvez envisager d'écrire en biais, qui est essentiellement une lecture fantôme. Prenons un tableau dans lequel figurent les noms des employés, leur salaire et le projet sur lequel ils travaillent:

En conséquence, nous obtenons l'image suivante: chaque manager pensait que son changement n'entraînerait pas de budget, alors ils ont fait des changements de personnel, ce qui a conduit au total à un dépassement.

La cause du problème est exactement la même que pour la lecture fantôme.

résultats

L'affaiblissement du niveau d'isolement des transactions dans la base de données est un compromis entre sécurité et performance, le choix de ce niveau doit être approché en fonction des risques potentiels pour l'entreprise en cas d'anomalies.

En savoir plus sur le cours.

Ce qui peut résulter de l'affaiblissement du niveau d'isolement des transactions dans les bases de données