Quelle est la relation entre ACID et la transaction de base de données?
ACID donne-t-il une transaction de base de données ou est-ce la même chose?
Quelqu'un pourrait-il éclairer ce sujet.
Comment fonctionnent les transactions ACID et base de données?
Réponses:
ACID est un ensemble de propriétés que vous souhaitez appliquer lors de la modification d'une base de données.
- Atomicité
- Cohérence
- Isolement
- Durabilité
Une transaction est un ensemble de modifications associées qui est utilisé pour obtenir certaines des propriétés ACID. Les transactions sont des outils pour atteindre les propriétés ACID.
L'atomicité signifie que vous pouvez garantir que toute une transaction se produit, ou rien de tout cela; vous pouvez effectuer des opérations complexes comme une seule unité, tout ou rien, et une panne, une panne de courant, une erreur ou quoi que ce soit d'autre ne vous permettra pas d'être dans un état dans lequel seuls certains des changements associés se sont produits.
La cohérence signifie que vous garantissez que vos données seront cohérentes; aucune des contraintes que vous avez sur les données associées ne sera jamais violée.
L'isolement signifie qu'une transaction ne peut pas lire les données d'une autre transaction qui n'est pas encore terminée. Si deux transactions s'exécutent simultanément, chacune verra le monde comme si elles s'exécutaient séquentiellement, et si l'une a besoin de lire des données écrites par une autre, elle devra attendre que l'autre soit terminée.
La durabilité signifie qu'une fois qu'une transaction est terminée, il est garanti que toutes les modifications ont été enregistrées sur un support durable (tel qu'un disque dur), et le fait que la transaction a été achevée est également enregistré.
Ainsi, les transactions sont un mécanisme pour garantir ces propriétés; ils sont une manière de regrouper les actions associées de telle sorte que dans son ensemble, un groupe d'opérations puisse être atomique, produire des résultats cohérents, être isolé des autres opérations et être enregistré durablement.
6
Vous dites "La cohérence signifie que vous garantissez que vos données seront cohérentes; aucune des contraintes que vous avez sur les données associées ne sera jamais violée." Si par contraintes, vous entendez celles définies dans la base de données (par exemple, vérifier les contraintes), qu'est-ce que la gestion des transactions a à voir pour éviter qu'elles ne soient violées? Ne sont-ils pas toujours en vigueur? Il me semble que le C dans ACID doit avoir une autre signification.
—
Marc Rochkind
@MarcRochkind Une transaction vous permet d'appliquer des contrôles de cohérence même si des opérations individuelles au sein de la transaction violeraient les contraintes de cohérence. Par exemple, si vous mettez à jour un système de comptabilité en partie double, vous devrez peut-être débiter plusieurs comptes et créditer plusieurs comptes en même temps. Sans transactions, vous vérifieriez les contraintes après chaque instruction et échoueriez car les instructions individuelles ne préservent pas la cohérence. Avec les transactions, bien que les déclarations individuelles ne préservent pas la cohérence, la transaction dans son ensemble le fait.
—
Brian Campbell
" et si l'un a besoin de lire des données écrites par un autre, il devra attendre que l'autre soit terminé " - n'est pas entièrement vrai. La première transaction peut (et va) lire ces données et verra l'état tel qu'il était avant le début de la deuxième transaction.
—
a_horse_with_no_name
@BrianCampbell 1) La cohérence est à la fois des "contraintes de contrôle" comme UNIQUE, FOREIGN KEY ainsi qu'un état valide (selon la logique métier / l'exigence de l'application) à la fin de la transaction? 2) L'atomicité et / ou l'isolement ne garantissent-ils pas à eux seuls la cohérence? Devrions-nous mentionner explicitement la cohérence comme une propriété requise?
—
user104309
@a_horse_with_no_name vous parlez d'OCC (contrôle de concurrence optimiste) contre PCC (pessimiste). Les deux peuvent être implémentés dans un système de base de données compatible ACID, selon que vous recherchez la cohérence ou la haute disponibilité.
—
Siddhartha le
ACID sont des propriétés souhaitables de tout moteur de traitement de transaction.
Un SGBD est (s'il est bon) un type particulier de moteur de traitement des transactions qui expose, généralement dans une très large mesure mais pas tout à fait entièrement, ces propriétés.
Mais il existe d'autres moteurs qui peuvent également exposer ces propriétés. Le type de logiciel qui était autrefois appelé "moniteurs TP" en est un bon exemple (l'équivalent actuel étant principalement des serveurs Web).
De tels moniteurs TP peuvent accéder à des ressources autres qu'un SGBD (par exemple une imprimante), tout en garantissant l'ACID envers leurs utilisateurs. À titre d'exemple de ce que peut signifier ACID lorsqu'une imprimante est impliquée dans une transaction:
- Atomicité: un document entier est imprimé ou rien du tout
- Cohérence: en fin de transaction, l'alimentation papier est positionnée en haut de page
- Isolation: aucun document ne se mélange lors de l'impression
- Durabilité: l'imprimante peut garantir qu'elle n'imprimait pas avec des cartouches vides.
grands exemples d'imprimantes concis.
—
Lakesare
Bon exemple. Cependant, je ne comprends pas la partie «cohérence». Dans mon esprit, un meilleur exemple est «L'imprimante n'accepte pas de papier de plus de 10 pouces».
—
skeller88
EDIT - "papier plus large que 10 pouces."
—
skeller88
J'avoue que c'est un peu exagéré. Mais il est difficile de trouver de meilleurs exemples car la «cohérence» concerne les données et une imprimante n'est pas exactement un périphérique de données.
—
Erwin Smout
Eh bien, l'imprimante dispose d'une fonction qui l'empêche de commencer à imprimer si le nombre de pages d'un document est supérieur au nombre de feuilles actuellement connu pour être dans la réserve de papier. Vous voyez que c'est le problème avec beaucoup de gens qui commentent ici. Vous mentionnez «imprimante» et ils ne voient que le périphérique de streaming série stupide qu'ils ont sur leur bureau à domicile, pas le périphérique professionnel de haute qualité qui remplirait tout leur salon (et qui a souvent ce genre de fonctionnalités que j'ai mentionnées).
—
Erwin Smout
J'ai légèrement modifié l'exemple d'imprimante pour le rendre plus explicable
1 document contenant 2 pages a été envoyé à l'imprimante
Transaction - document envoyé à l'imprimante
- atomicité - l'imprimante imprime 2 pages d'un document ou aucune
- cohérence - l'imprimante imprime une demi-page et la page se bloque. L'imprimante redémarre et imprime 2 pages avec tout le contenu
- isolation - alors qu'il y avait trop d'impressions en cours - l'imprimante imprime le bon contenu du document
- durabilité - lors de l'impression, il y a eu une coupure de courant - l'imprimante imprime à nouveau les documents sans aucune erreur
J'espère que cela aidera quelqu'un à comprendre le concept d'ACID
Je ne sais pas ce que signifie «alors qu'il y avait trop d' impressions en cours» - c'est simplement «multiple» plutôt que «trop»?
—
icc97
Quelle est la relation entre ACID et la transaction de base de données?
Dans une base de données relationnelle, chaque instruction SQL doit s'exécuter dans le cadre d'une transaction.
Sans définir explicitement les limites des transactions, la base de données va utiliser une transaction implicite qui entoure chaque instruction individuelle.
La transaction implicite commence avant l'exécution de l'instruction et se termine (validation ou annulation) après l'exécution de l'instruction. Le mode de transaction implicite est généralement appelé autocommit.
Comme expliqué dans cet article , une transaction est une collection d'opérations de lecture / écriture réussissant uniquement si toutes les opérations contenues réussissent.
Une transaction est intrinsèquement caractérisée par quatre propriétés (communément appelées ACID):
- Atomicité
- Cohérence
- Isolement
- Durabilité
ACID donne-t-il une transaction de base de données ou est-ce la même chose?
Pour un système de base de données relationnelle, cela est vrai car le SQL Standard spécifie qu'une transaction doit fournir les garanties ACID:
Atomicité
L'atomicité prend des opérations individuelles et les transforme en une unité de travail tout ou rien, réussissant si et seulement si toutes les opérations contenues réussissent.
Une transaction peut encapsuler un changement d'état (sauf s'il s'agit d'une transaction en lecture seule). Une transaction doit toujours laisser le système dans un état cohérent, quel que soit le nombre de transactions simultanées entrelacées à un moment donné.
Cohérence
La cohérence signifie que les contraintes sont appliquées pour chaque transaction validée. Cela implique que toutes les clés, types de données, vérifications et déclencheurs sont réussis et qu'aucune violation de contrainte n'est déclenchée.
Isolement
Les transactions nécessitent des mécanismes de contrôle d'accès concurrentiel et garantissent l'exactitude même lorsqu'elles sont entrelacées. L'isolement nous apporte l'avantage de cacher les changements d'état non validés au monde extérieur, car les transactions échouées ne devraient jamais corrompre l'état du système. L'isolement est obtenu grâce au contrôle de la concurrence à l'aide de mécanismes de verrouillage pessimistes ou optimistes.
Durabilité
Une transaction réussie doit changer de façon permanente l'état d'un système et avant de le terminer, les changements d'état sont enregistrés dans un journal des transactions persistant. Si notre système est soudainement affecté par une panne système ou une panne de courant, toutes les transactions validées non terminées peuvent être rejouées.
Pour plus de détails sur la durabilité et le journal de rétablissement, consultez cet article .
Par «cohérence» - je vois «l'exactitude logique spécifique à l'application» comme l'explication dans de nombreux endroits. Supposons que si tel est le cas, DB ne peut pas connaître la logique de l'application. La "cohérence" ne peut donc pas être une propriété inhérente à une base de données. Donc, pour que l'application implémente son exactitude (ou «cohérence»), l'atomicité et l'isolation ne suffisent-elles pas?
—
user104309
La cohérence dans ACID signifie des contraintes d'intégrité de la base de données: contraintes PK, FK, UNIQUE. L'ACID est important, mais votre application peut avoir besoin de plus que cela, comme éviter la perte de mises à jour dans de longues conversations, ce qui nécessite un verrouillage optimiste au niveau de l'application.
—
Vlad Mihalcea le
Laisse-moi regarder. Mais avant cela, j'ai besoin d'une clarification de base. Commentaire de Brain Campbell dans la réponse acceptée "Avec les transactions, bien que les déclarations individuelles ne préservent pas la cohérence, la transaction dans son ensemble le fait". Comment est-ce possible ? Et comment les débits et crédits multiples sont-ils liés à la cohérence?
—
user104309
Consultez le chapitre Transactions de mon livre Persistance Java haute performance pour une réponse détaillée à toutes ces questions.
—
Vlad Mihalcea le
Les propriétés ACID sont un concept très ancien et important de la théorie des bases de données. Je sais que vous pouvez trouver de nombreux articles sur ce sujet, mais j'aimerais tout de même commencer à partager des réponses à ce sujet car c'est un sujet très important du SGBDR.
Le système de base de données joue avec de nombreux types de transactions où toutes les transactions ont certaines caractéristiques. Cette caractéristique est connue des propriétés ACID. ACID Properties prend bénéficiaire pour toutes les transactions de base de données pour accomplir toutes les tâches.
Atomicité: soit commettre tout ou rien.
Cohérence: faites un enregistrement cohérent en termes de validation de toutes les règles et contraintes de transaction.
Isolation: assurez-vous que deux transactions ne sont pas conscientes l'une de l'autre.
Durabilité: des données validées stockées pour toujours. Référence tirée de cet article:
Pour citer Wikipedia :
ACID (atomicité, cohérence, isolation, durabilité) est un ensemble de propriétés qui garantissent que les transactions de base de données sont traitées de manière fiable.
Un SGBD prenant en charge les transactions s'efforcera de prendre en charge toutes ces propriétés - tout SGBD commercial (ainsi que plusieurs SGBD open-source) fournissent un `` support '' ACID complet - bien qu'il soit souvent possible (par exemple, avec des niveaux d'isolement variables dans MSSQL) de diminuer l'ACIDité - perdant ainsi la garantie d'un comportement entièrement transactionnel.
[Gray] a introduit les propriétés ACD pour une transaction en 1981. En 1983, [Haerder] a ajouté la propriété Isolation. À mon avis, les propriétés ACD auraient un ensemble de propriétés plus utile à discuter. Une interprétation d'Atomicity (que la transaction devrait être atomique comme vue de n'importe quel client à tout moment) impliquerait en fait la propriété d'isolation. La propriété "isolation" est utile lorsque la transaction n'est pas isolée; lorsque la propriété d'isolation est assouplie. En ANSI SQL, parlez: si le niveau d'isolement est plus faible, SERIALIZABLE. Mais lorsque le niveau d'isolement est SERIALIZABLE, la propriété d'isolation n'est pas vraiment intéressante.
J'ai écrit plus à ce sujet dans un article de blog: "L'ACID n'a pas de sens".
http://blog.franslundberg.com/2013/12/acid-does-not-make-sense.html
[Gray] The Transaction Concept, Jim Gray, 1981. http://research.microsoft.com/en-us/um/people/gray/papers/theTransactionConcept.pdf
[Haerder] Principles of Transaction-Oriented Database Recovery, Haerder et Reuter, 1983. http://www.stanford.edu/class/cs340v/papers/recovery.pdf
La transaction peut être définie comme un ensemble de tâches considérées comme une unité de traitement minimale. Chaque unité de traitement minimale ne peut pas être divisée davantage.
Toute transaction doit contenir quatre propriétés communément appelées propriétés ACID. c.-à-d. ACID sont le groupe de propriétés de toute transaction.
- Atomicité:
- Cohérence
- Isolement
- Durabilité