3.1 Émergence d'ACIDE
L'abréviation ACID est apparue pour la première fois en 1983 dans un article de Theo Haerder et Andreas Reuter. Pour simplifier le texte et le rendre plus convaincant, je donnerai une traduction d'un fragment de cet article (avec de légères réductions). Cet extrait utilise un exemple de transaction bancaire dans laquelle de l'argent est transféré d'un compte à un autre.
Le concept de transaction, qui dans l'exemple inclut toutes les interactions avec la base de données entre $BEGIN_TRANSACTIONet $COMMIT_TRANSACTION, nécessite que toutes les actions soient effectuées de manière indivisible : soit toutes les actions sont correctement reflétées dans l'état de la base de données, soit rien ne se passe. Si à tout moment avant d'atteindre $COMMIT_TRANSACTIONl'utilisateur entre une instruction ERRORcontenant $RESTORE_TRANSACTION, aucune modification n'est reflétée dans la base de données.
Pour réaliser cette indivisibilité, une transaction doit avoir les quatre propriétés suivantes :
Atomicité (atomicité). La transaction doit être du type tout ou rien décrit ci-dessus, et quoi qu'il arrive, l'utilisateur doit savoir dans quel état se trouve la transaction.
Cohérence (Cohérence). Une transaction qui atteint sa fin normale de transaction (EOT) et valide ainsi ses résultats maintient la cohérence de la base de données. En d'autres termes, chaque transaction réussie, par définition, ne valide que des résultats valides. Cette condition est nécessaire pour soutenir la quatrième propriété - la durabilité.
Isolement (Isolement). Les événements qui se produisent dans une transaction doivent être masqués des autres transactions exécutées simultanément. Si cette condition n'était pas remplie, alors pour les raisons mentionnées ci-dessus, la transaction serait impossible de revenir à son début. Pour réaliser l'isolement, des méthodes appelées synchronisation sont utilisées ...
Durabilité (Durabilité). Une fois qu'une transaction s'est terminée et a validé ses résultats dans la base de données, le système doit s'assurer que ces résultats survivent à tout échec ultérieur. Puisqu'il n'y a pas de portée de contrôle qui couvre des ensembles de transactions, le système de gestion de base de données (SGBD) n'a aucun contrôle au-delà des limites des transactions.
Par conséquent, l'utilisateur doit être assuré que si le système l'informe que quelque chose s'est produit, alors ce "quelque chose" s'est réellement produit. Étant donné que, par définition, toute transaction (réalisée avec succès - S.K.) est correcte, les résultats de transactions incorrectes apparaissant inévitablement (c'est-à-dire des transactions contenant des données erronées) ne peuvent être éliminés que par la transaction "contre" correspondante (contre-transaction).
3.2 L'émergence des transactions
Ces quatre propriétés - Atomicité, Cohérence, Isolation et Durabilité (ACID) - décrivent les principales caractéristiques du paradigme transactionnel qui affectent de nombreux aspects de la conception du système de base de données. Par conséquent, nous pensons que la capacité de tout système à prendre en charge les transactions est la pierre de touche (test ACID) de la qualité de ce système.
Un simple programme PL/1-SQL qui transfère des fonds d'un compte à un autre.
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */J'ai fourni un exemple de ce code pour vous rappeler qu'en fait, les propriétés ACID, d'une part, peuvent être considérées comme des exigences pour tout SGBD qui prétend prendre en charge les transactions, et d'autre part, comme la définition d'une transaction dans un système de base de données . Cette définition est entièrement conforme à la pratique mondaine. Il est difficile d'imaginer, par exemple, qu'un client effectuant une transaction bancaire (que ce soit avec l'aide d'un caissier humain en direct ou en utilisant les services bancaires par Internet) ne s'attende pas à ce que la banque satisfasse à toutes les propriétés d'ACID. Une banque qui ne prend pas en charge les propriétés ACID pour ses transactions perdra, au mieux, des clients et, au pire, fera faillite.
3.3 Connectivité ACID
Il est très important que les propriétés ACID soient inséparables, la suppression de l'une d'entre elles rend la combinaison restante insignifiante. En particulier, si nous éliminons la propriété de cohérence (au sens où elle a été utilisée dans la citation ci-dessus), nous perdrons le critère d'exactitude d'une transaction. Le système de base de données ne sera pas en mesure de décider de manière significative si les transactions sont autorisées ou non, et toutes les vérifications de l'exactitude des opérations effectuées dans l'état actuel de la base de données devront être effectuées dans le code de l'application.
Vous devez comprendre que dans ce cas, nous parlons de cohérence logique. Le client de la banque a besoin que la banque travaille selon les règles établies par lui et connues des clients, de sorte qu'il soit impossible d'effectuer toute transaction qui viole ces règles, de sorte que la prochaine transaction du même client soit exécutée dans un environnement convenu conformément à ces règles.
Le client de la boutique en ligne a besoin que les marchandises commandées et payées par lui lui soient livrées dans les délais (conformément aux règles établies et connues du client). Sinon, il ne fera pas confiance à ce magasin. Dans le même temps, ni le client de la banque ni le client de la boutique Internet ne se soucient de la cuisine interne de l'entreprise, des mesures internes prises pour mener à bien sa transaction. Le client ne se soucie pas de savoir comment la cohérence physique de cette entreprise est maintenue, comment les opérations sont effectuées au niveau de la couche physique.
Si le SGBD se charge de maintenir la cohérence logique des transactions (et de la base de données), alors les applications deviennent plus simples, plus compréhensibles et plus fiables. Toute la logique du domaine d'application (banque, magasin, entrepôt, etc.) concernant les transactions et l'état valide des données entre dans le système de base de données. Et les exigences pour ce système sont très simples : prise en charge des transactions ACID, en tenant compte des règles de cohérence fournies dans la base de données par l'application. De mon point de vue, le rejet des transactions ACID crée des difficultés démesurées pour les développeurs d'applications qui, qu'on le veuille ou non, devront implémenter eux-mêmes quelque chose de similaire afin de satisfaire les besoins naturels de leurs clients.
Et encore une fois, je note que les propriétés ACID définissent en fait le concept de transaction. À mon avis, pour avoir au moins une certaine possibilité de parler d'un système de gestion de données transactionnelles dans lequel la propriété de cohérence des transactions n'est pas prise en charge, il est absolument nécessaire de définir ce que l'on entend par le terme transaction dans ce cas.
Malheureusement, aujourd'hui, dans de nombreux cas (en particulier, c'est caractéristique de la direction NoSQL), les gens parlent de prendre en charge les applications OLTP sans préciser du tout de quel type de transactions il s'agit. Par conséquent, dans cet article, j'utiliserai la combinaison transaction ACID pour faire référence à des transactions réelles, et le terme transaction non qualifié sera utilisé dans un sens informel, différent selon les contextes.
Traitons maintenant du "théorème" de CAP et essayons de comprendre ce que signifie cohérence au sens de Brewer.