Annuaire d'articles
Transactions et ACID
Lorsque nous en apprenons sur les bases de données, nous voyons souvent les termes transaction et ACID.
Qu'est-ce qu'une opération ?
Dans un système de base de données, une transaction fait référence à un processus logique complet composé d'une série d'opérations de base de données.
Par exemple, virement bancaire :
1. Déduisez le montant du compte d'origine ;
2. Ajoutez le montant au compte cible.
La somme de ces deux opérations de base de données constitue un processus logique complet qui ne peut pas être divisé. Ce processus s'appelle une transaction et possède des propriétés ACID.
Alors, qu'est-ce que l'ACIDE ?
La définition d'ACID sur Wikipédia est la suivante :
ACID fait référence aux quatre caractéristiques qu'un système de gestion de base de données (SGBD) doit avoir afin de garantir que les transactions sont correctes et fiables dans le processus d'écriture ou de mise à jour des données : atomicité (atomicité ou indivisibilité), cohérence (cohérence), isolation ( isolement, également connu sous le nom d'indépendance), persistance (durabilité).
- Atomique (Atomic) : Dans le même processus métier, une transaction garantit que plusieurs modifications de données réussissent en même temps ou sont révoquées ensemble. Par exemple, transfert, soit le transfert est réussi, soit le transfert échoue, et il n'y a pas de moitié du transfert.
- Isolement : dans différents processus métier, les transactions garantissent que les données lues et écrites par chaque entreprise sont indépendantes les unes des autres et ne s'affecteront pas les unes les autres. Les bases de données ont généralement quatre niveaux d'isolation : lecture non validée, lecture validée, lecture répétable et sérialisable.
- Durabilité : la transaction doit garantir que toutes les modifications de données soumises avec succès peuvent être correctement conservées, c'est-à-dire enregistrées sur le disque sans perte de données.
- Cohérence : assurez-vous que les données du système sont correctes, qu'il n'y aura pas de contradictions entre les différentes données et que les résultats sont cohérents.
En fait, le but ultime de l'atomicité, de l'isolement et de la persistance est la cohérence des données.
Comment atteindre l'atomicité et la persistance
L'atomicité garantit que plusieurs opérations dans une transaction réussissent ou échouent, et qu'il n'y a pas de demi-succès. La persistance garantit qu'une fois qu'une transaction prend effet, les données ne seront pas modifiées ou perdues pour quelque raison que ce soit.
Et si l'atomicité et la persistance pouvaient être atteintes ?
On peut facilement y penser, ne suffirait-il pas que la base de données écrive les données sur le disque ?
Oui, c'est la bonne méthode, mais le problème est que l'opération "écrire sur le disque" n'est pas atomique, et l'opération d'écriture peut avoir le statut d'écriture, d'écriture, d'écriture réussie et même d'échec d'écriture.
Et une transaction comprend souvent plusieurs opérations.Par exemple, lorsque nous passons une commande en ligne, il s'agit généralement de ces opérations : débiter de l'argent de notre compte, ajouter de l'argent sur le compte du marchand, soustraire l'inventaire du produit, etc. Ces opérations sont dans une transaction, c'est-à-dire qu'elles réussissent toutes ou échouent toutes.
reprise sur incident
Si 100 yuans sont déduits de notre compte, cette opération est écrite avec succès sur le disque, et lorsque nous ajoutons 100 yuans au marchand, le système plante (pas de chance ?), ou il y a une panne de courant (n'est-ce pas ?) , entraînant l'échec de l'écriture de la connexion (n'est-ce pas courant ?).
Afin d'éviter que cela ne se produise, la base de données doit trouver un moyen de savoir à quoi ressemblait l'opération complète avant que le système ne plante, de sorte qu'après la récupération du serveur, la base de données réécrira la partie des données qui n'a pas eu le temps de être écrit sur le disque et donner au marchand Ajouter 100 yuans au compte pour terminer l'affaire inachevée.
La question est donc de savoir comment la base de données connaît-elle toutes les informations sur les transactions précédentes après la restauration du système ?
Une bonne mémoire n'est pas aussi bonne qu'un mauvais stylo, pourquoi ne pas simplement l'écrire d'abord ?
Rétablir le journal
Cela nécessite que la base de données enregistre toutes les opérations de la transaction avant d'écrire sur le disque, telles que les données modifiées, la page de mémoire et le bloc de disque dans lesquels les données se trouvent physiquement, quelle valeur est changée en quelle valeur, etc. formulaire est d'abord écrit sur le disque.
Ce n'est qu'après que tous les enregistrements de journal sont placés en toute sécurité sur le disque, puis que j'écris "Commit Record" à la fin, cela signifie que j'ai fini d'écrire tous les enregistrements d'opération.
À ce moment, la base de données modifiera les données réelles en fonction des informations contenues dans le journal. Une fois la modification terminée, un "enregistrement de fin" sera ajouté au journal, indiquant que j'ai terminé toutes les étapes du journal, et le travail de la persistance des transactions C'est tout.
Cette méthode d'implémentation de transaction est appelée "Commit Logging".
Les principes de cette méthode pour obtenir la persistance et l'atomicité des données sont les suivants :
Tout d'abord, une fois que le journal est écrit avec succès dans l'enregistrement de validation, cela signifie que toutes les informations relatives à la transaction ont été écrites dans le journal. Si le système plante pendant le processus de modification des données, après le redémarrage, il suffit de ré-opérer selon au contenu du log. , ce qui garantit la persistance.
Deuxièmement, si le système tombe en panne avant la fin du journal, après le redémarrage du système, la base de données voit qu'il n'y a pas d'enregistrement de validation dans le journal, ce qui signifie que le journal est incomplet et n'a pas été écrit, puis marquez cette partie du journal en état de restauration, la totalité de la transaction est annulée, ce qui garantit l'atomicité.
En d'autres termes, j'enregistre d'abord les choses que je veux changer dans le journal, puis je les écris sur le disque en fonction du journal. Au cas où je m'évanouirais pendant le processus d'écriture sur le disque, quand je me réveillerai, je vérifierai l'intégrité du journal en premier.
Si le journal est complet et qu'il contient un enregistrement de validation, je le referai en fonction du journal, et cela réussira à la fin. Si le journal est incomplet et qu'il ne contient aucun enregistrement de validation, j'annule simplement l'intégralité de la transaction et ne fais rien.
Ce journal est appelé Redo Log, c'est-à-dire "redo log". Pour une base de données qui plante à mi-chemin, la transaction est refaite en fonction de ce journal.
Annuler le journal
Cependant, il y a un problème avec Redo Log, c'est-à-dire que l'efficacité est trop lente.
Parce que toutes les modifications réelles apportées aux données par la base de données doivent se produire après la validation de la transaction, et uniquement après l'écriture du journal dans l'enregistrement de validation.
Même si les E/S du disque sont suffisamment libres avant que la transaction ne soit validée, même si la quantité de données modifiées par une certaine transaction est très importante et occupe une grande quantité de mémoire tampon, quelle qu'en soit la raison, cela n'est jamais autorisé commencer à modifier les données sur le disque avant que la transaction ne soit validée. En cas de plantage du système, qui est responsable du déplacement des données ?
Mais lorsque la quantité de données dans une transaction est particulièrement importante, attendez que toutes les modifications soient écrites dans le journal de rétablissement, puis écrivez-les uniformément sur le disque, de sorte que les performances ne seront pas très bonnes, ce sera très lent et le le patron sera mécontent.
Pouvez-vous secrètement écrire des données sur le disque avant que la transaction ne soit validée (se faufiler) ?
La réponse est oui, c'est la stratégie STEAL, mais voici le problème. Si vous écrivez des données secrètement, au cas où la transaction doit être annulée ou que le système tombe en panne, les données écrites à l'avance deviendront des données sales et vous doit trouver un moyen de le restaurer.
Cela nécessite l'introduction du journal d'annulation (journal d'annulation). Avant d'écrire secrètement des données, vous devez d'abord enregistrer dans le journal d'annulation les données qui ont été écrites et ce qui a été modifié. Lorsque la transaction est annulée, suivez le journal d'annulation, un par on revenait à son aspect d'origine, comme s'il n'avait pas été modifié.
Le journal d'annulation a également une autre fonction, qui consiste à implémenter le contrôle de version de plusieurs lignes (MVCC). Lorsqu'une ligne lue est verrouillée par d'autres transactions, il peut obtenir les données précédentes de l'enregistrement de ligne à partir du journal d'annulation, fournissant ainsi les informations de version de ligne pour utilisateurs à lire.
Résumer
La différence entre Undo Log (redo log) et Redo Log (rollback log) n'est pas si profonde, nous avons juste besoin de la comprendre littéralement.
Redo Log (redo log) est utilisé pour restaurer les données après un plantage du système, permettant à la base de données de refaire les choses qui n'ont pas été bien faites selon le journal. Avec Redo Log, vous pouvez vous assurer que même si la base de données tombe en panne et redémarre, les enregistrements précédemment soumis ne seront pas perdus. Cette fonctionnalité est appelée crash-safe.
Le journal d'annulation (journal de restauration) est destiné à la restauration. Commencez à écrire des données avant que la transaction ne soit validée. Si la transaction ne prévoit pas d'être validée à la fin et doit être annulée, ou si le système tombe en panne, les données écrites à l'avance deviendront des données modifiées. À ce stade, Annuler le journal doit être utilisé pour restaurer.
Cette façon d'écrire le journal avant d'écrire sur le disque s'appelle : Write-Ahead Logging (WAL). WAL améliore les performances, mais en même temps c'est plus compliqué. Bien que ce soit plus compliqué, l'effet est très bon. Mysql, sqlite, Postgresql, sql server et d'autres bases de données ont implémenté le mécanisme WAL.