ACIDE

En informatique , ACID ( atomicité , cohérence , isolation , durabilité ) est un ensemble de propriétés des transactions de bases de données destinées à garantir la validité des données malgré les erreurs, les pannes de courant et autres incidents. Dans le contexte des bases de données , une séquence d'opérations de base de données qui satisfait les propriétés ACID (qui peuvent être perçues comme une seule opération logique sur les données) est appelée une transaction . Par exemple, un transfert de fonds d'un compte bancaire à un autre, même impliquant plusieurs changements tels que le débit d'un compte et le crédit d'un autre, est une transaction unique.

En 1983, Andreas Reuter et Theo Härder ont inventé l'acronyme ACID , en s'appuyant sur les travaux antérieurs de Jim Gray qui a nommé l'atomicité, la cohérence et la durabilité, mais pas l'isolement, pour caractériser le concept de transaction. Ces quatre propriétés sont les principales garanties du paradigme de transaction, qui a influencé de nombreux aspects du développement des systèmes de bases de données .

Selon Gray et Reuter, le système de gestion des informations IBM prenait en charge les transactions ACID dès 1973 (bien que l'acronyme ait été créé plus tard).

Les caractéristiques de ces quatre propriétés telles que définies par Reuter et Härder sont les suivantes :

Les transactions sont souvent composées de plusieurs instructions . L'atomicité garantit que chaque transaction est traitée comme une seule « unité », qui réussit complètement ou échoue complètement : si l'une des instructions constituant une transaction échoue, la transaction entière échoue et la base de données reste inchangée. Un système atomique doit garantir l'atomicité dans chaque situation, y compris les pannes de courant, les erreurs et les plantages. Une garantie d'atomicité empêche les mises à jour de la base de données de ne se produire que partiellement, ce qui peut causer des problèmes plus graves que le rejet total de la série entière. En conséquence, la transaction ne peut pas être observée en cours par un autre client de base de données. À un moment donné, elle n'a pas encore eu lieu, et au moment suivant, elle a déjà eu lieu dans son intégralité (ou rien ne s'est produit si la transaction a été annulée en cours).

La cohérence garantit qu'une transaction ne peut amener la base de données que d'un état cohérent à un autre, en préservant les invariants de la base de données : toutes les données écrites dans la base de données doivent être valides selon toutes les règles définies, y compris les contraintes , les cascades , les déclencheurs et toute combinaison de celles-ci. Cela empêche la corruption de la base de données par une transaction illégale. Un exemple d'invariant de base de données est l'intégrité référentielle , qui garantit la relation clé primaire – clé étrangère .

Les transactions sont souvent exécutées simultanément (par exemple, plusieurs transactions lisent et écrivent dans une table en même temps). L'isolation garantit que l'exécution simultanée de transactions laisse la base de données dans le même état que celui qui aurait été obtenu si les transactions avaient été exécutées séquentiellement. L'isolation est l'objectif principal du contrôle de concurrence ; selon le niveau d'isolation utilisé, les effets d'une transaction incomplète peuvent ne pas être visibles pour les autres transactions.

La durabilité garantit qu'une fois qu'une transaction a été validée, elle restera validée même en cas de défaillance du système (par exemple, une panne de courant ou un crash ). Cela signifie généralement que les transactions terminées (ou leurs effets) sont enregistrées dans une mémoire non volatile .

Les exemples suivants illustrent plus en détail les propriétés ACID. Dans ces exemples, la table de base de données comporte deux colonnes, A et B. Une contrainte d'intégrité exige que la valeur de A et la valeur de B totalisent 100. Le code SQL suivant crée une table comme décrit ci-dessus :

CRÉER UNE TABLE acidtest ( A ENTIER , B ENTIER , VÉRIFIER ( A + B = 100 ));

L'atomicité est la garantie que les séries d'opérations de base de données dans une transaction atomique se produiront toutes (opération réussie) ou aucune ne se produira (opération infructueuse). La série d'opérations ne peut pas être séparée en n'exécutant que certaines d'entre elles, ce qui rend la série d'opérations « indivisible ». Une garantie d'atomicité empêche les mises à jour de la base de données de ne se produire que partiellement, ce qui peut causer des problèmes plus graves que le rejet pur et simple de la série entière. En d'autres termes, l'atomicité signifie indivisibilité et irréductibilité. Alternativement, nous pouvons dire qu'une transaction logique peut être composée de plusieurs transactions physiques. Tant que toutes les transactions physiques qui la composent ne sont pas exécutées, la transaction logique n'aura pas eu lieu.

Un exemple de transaction atomique est un transfert monétaire du compte bancaire A vers le compte B. Il se compose de deux opérations, le retrait de l'argent du compte A et son dépôt sur le compte B. Nous ne voudrions pas voir le montant retiré du compte A avant d'être sûr qu'il a également été transféré sur le compte B. L'exécution de ces opérations dans une transaction atomique garantit que la base de données reste dans un état cohérent , c'est-à-dire que l'argent n'est ni débité ni crédité si l'une de ces deux opérations échoue.

La cohérence est un terme très général, qui exige que les données respectent toutes les règles de validation. Dans l'exemple précédent, la validation est une exigence selon laquelle A + B = 100 . Toutes les règles de validation doivent être vérifiées pour garantir la cohérence. Supposons qu'une transaction tente de soustraire 10 de A sans modifier B . Étant donné que la cohérence est vérifiée après chaque transaction, on sait que A + B = 100 avant le début de la transaction. Si la transaction supprime 10 de A avec succès, l'atomicité sera atteinte. Cependant, un contrôle de validation montrera que A + B = 90 , ce qui est incompatible avec les règles de la base de données. La transaction entière doit être annulée et les lignes affectées ramenées à leur état antérieur à la transaction. S'il y avait eu d'autres contraintes, déclencheurs ou cascades, chaque opération de modification aurait été vérifiée de la même manière que ci-dessus avant la validation de la transaction. Des problèmes similaires peuvent survenir avec d'autres contraintes. Nous avons peut-être exigé que les types de données de A et B soient des entiers. Si nous saisissons ensuite, par exemple, la valeur 13,5 pour A , la transaction sera annulée ou le système pourra déclencher une alerte sous la forme d'un déclencheur (si/quand le déclencheur a été écrit à cet effet). Un autre exemple serait celui des contraintes d'intégrité, qui ne nous permettraient pas de supprimer une ligne dans une table dont la clé primaire est référencée par au moins une clé étrangère dans d'autres tables.

Pour démontrer l'isolation, nous supposons que deux transactions s'exécutent en même temps, chacune tentant de modifier les mêmes données. L'une des deux doit attendre que l'autre termine afin de maintenir l'isolation.

Considérons deux transactions :

• T ₁ transfère 10 de A à B.
• T ₂ transfère 20 de B à A.

Combinées, il y a quatre actions :

1. T ₁ soustrait 10 de A.
2. T ₁ ajoute 10 à B.
3. T ₂ soustrait 20 de B.
4. T ₂ ajoute 20 à A.

Si ces opérations sont effectuées dans l'ordre, l'isolement est maintenu, même si T2 _doit attendre. Imaginez ce qui se passe si T1 _échoue à mi-chemin. La base de données élimine les effets de T1 et T2 _{ne voit} que les données valides.

En entrelaçant les transactions, l'ordre réel des actions pourrait être :

1. T ₁ soustrait 10 de A.
2. T ₂ soustrait 20 de B.
3. T ₂ ajoute 20 à A.
4. T ₁ ajoute 10 à B.

Encore une fois, considérons ce qui se passe si T ₁ échoue lors de la modification de B à l'étape 4. Au moment où T ₁ échoue, T ₂ a déjà modifié A ; il ne peut pas être restauré à la valeur qu'il avait avant T ₁ sans laisser une base de données non valide. C'est ce qu'on appelle un conflit d'écriture-écriture , car deux transactions ont tenté d'écrire dans le même champ de données. Dans un système typique, le problème serait résolu en revenant au dernier état correct connu, en annulant la transaction T ₁ ayant échoué et en redémarrant la transaction T ₂ interrompue à partir de l'état correct.

Prenons l'exemple d'une transaction qui transfère 10 de A vers B. Tout d'abord, elle supprime 10 de A, puis ajoute 10 à B. À ce stade, l'utilisateur est informé que la transaction a réussi. Cependant, les modifications sont toujours en file d'attente dans la mémoire tampon du disque en attendant d'être validées sur le disque. Une panne de courant et les modifications sont perdues, mais l'utilisateur suppose (de manière compréhensible) que les modifications persistent.

Le traitement d'une transaction nécessite souvent une séquence d'opérations qui peut échouer pour plusieurs raisons. Par exemple, le système peut ne plus avoir de place sur ses disques ou avoir épuisé le temps CPU qui lui était alloué. Il existe deux familles de techniques courantes : la journalisation anticipée et la pagination fantôme . Dans les deux cas, des verrous doivent être acquis sur toutes les informations à mettre à jour et, selon le niveau d'isolement, éventuellement sur toutes les données pouvant être lues également. Dans la journalisation anticipée, la durabilité est garantie en écrivant la modification envisagée dans un journal persistant avant de modifier la base de données. Cela permet à la base de données de revenir à un état cohérent en cas de panne. Dans la mise en miroir, les mises à jour sont appliquées à une copie partielle de la base de données et la nouvelle copie est activée lorsque la transaction est validée.

De nombreuses bases de données utilisent le verrouillage pour fournir des fonctionnalités ACID. Le verrouillage signifie que la transaction marque les données auxquelles elle accède afin que le SGBD sache qu'il ne doit pas autoriser d'autres transactions à les modifier jusqu'à ce que la première transaction réussisse ou échoue. Le verrou doit toujours être acquis avant le traitement des données, y compris les données lues mais non modifiées. Les transactions non triviales nécessitent généralement un grand nombre de verrous, ce qui entraîne une surcharge importante et bloque d'autres transactions. Par exemple, si l'utilisateur A exécute une transaction qui doit lire une ligne de données que l'utilisateur B souhaite modifier, l'utilisateur B doit attendre que la transaction de l'utilisateur A soit terminée. Le verrouillage en deux phases est souvent appliqué pour garantir une isolation complète.

Une alternative au verrouillage est le contrôle de concurrence multiversion , dans lequel la base de données fournit à chaque transaction de lecture la version antérieure, non modifiée, des données qui sont modifiées par une autre transaction active. Cela permet aux lecteurs de fonctionner sans acquérir de verrous, c'est-à-dire que les transactions d'écriture ne bloquent pas les transactions de lecture et que les lecteurs ne bloquent pas les écritures. Pour revenir à l'exemple, lorsque la transaction de l'utilisateur A demande des données que l'utilisateur B est en train de modifier, la base de données fournit à A la version de ces données qui existait lorsque l'utilisateur B a démarré sa transaction. L'utilisateur A obtient une vue cohérente de la base de données même si d'autres utilisateurs modifient des données. Une implémentation, à savoir l'isolation par snapshot , assouplit la propriété d'isolation.

Garantir les propriétés ACID dans une transaction distribuée sur une base de données distribuée , où aucun nœud n'est responsable de toutes les données affectant une transaction, présente des complications supplémentaires. Les connexions réseau peuvent échouer, ou un nœud peut terminer avec succès sa partie de la transaction et être ensuite obligé d'annuler ses modifications en raison d'une défaillance sur un autre nœud. Le protocole de validation en deux phases (à ne pas confondre avec le verrouillage en deux phases ) fournit l'atomicité des transactions distribuées pour garantir que chaque participant à la transaction s'accorde sur le fait que la transaction doit être validée ou non. En bref, dans la première phase, un nœud (le coordinateur) interroge les autres nœuds (les participants), et ce n'est que lorsque tous répondent qu'ils sont prêts que le coordinateur, dans la deuxième phase, formalise la transaction.