Auteur: Wonder , ingénieur senior de développement base de données cloud Ali

Le rôle du contrôle d'accès concurrentiel à la base de données

1.1 Le concept des affaires

Avant d'introduire le contrôle d'accès concurrentiel, vous devez d'abord comprendre les transactions. La base de données fournit plusieurs opérations de base telles que l'ajout, la suppression, la modification et la vérification. Les utilisateurs peuvent combiner ces opérations de manière flexible pour obtenir une sémantique complexe. Dans de nombreux scénarios, les utilisateurs souhaitent qu'un groupe d'opérations prenne effet ensemble dans son ensemble. Il s'agit d'une transaction. Une transaction est l'unité de base des changements d'état de la base de données et contient une ou plusieurs opérations (telles que plusieurs instructions SQL).

La transaction de transfert classique comprend trois opérations: (1) Vérifier si le solde d'un compte A est suffisant. (2) Si suffisant, déduisez 100 yuans de A. (3) Ajoutez 100 yuans au compte B.

La transaction a une caractéristique de base: ce groupe d'opérations prendra effet ensemble ou pas du tout . Si une erreur se produit pendant l'exécution de la transaction, toutes les opérations qui ont été effectuées doivent être retirées. Il s'agit de l' atomicité de la transaction .

Si après l'échec, des transactions partiellement efficaces ne peuvent pas être retirées, la base de données entre dans un état incohérent, ce qui est contraire aux faits réels. Par exemple, la transaction de transfert échoue après avoir déduit 100 yuans du compte A et le compte B n'a pas encore augmenté le montant. Si l'opération de déduction du compte A n'est pas retirée, le monde perdra inexplicablement 100 yuans. L'atomicité peut être obtenue en enregistrant (la valeur avant la modification), et certaines bases de données mettent en cache les opérations de transaction localement, et en cas d'échec, rejettent directement les opérations dans le cache.

Tant que la transaction est validée, ses résultats ne peuvent pas être modifiés. Même si le système est arrêté, l'état de la base de données après le redémarrage est le même qu'avant le temps d'arrêt. C'est la durabilité de la transaction .

Tant que les données sont stockées sur des supports de stockage non volatils, les temps d'arrêt n'entraîneront aucune perte de données. Par conséquent, la base de données peut utiliser les méthodes suivantes pour garantir la durabilité: (1) Avant la fin de la transaction, toutes les modifications sont garanties d'être stockées sur le disque. Ou (2) Avant la fin de la validation, les informations de modification de la transaction sont stockées sur le disque sous la forme d'un journal et l'état de la mémoire du système de base de données est restauré conformément au journal pendant le processus de redémarrage. De manière générale, la base de données choisira la méthode (2), la raison est laissée au lecteur de réfléchir.

Afin d'améliorer l'utilisation des ressources et l'efficacité d'exécution des transactions et de réduire le temps de réponse, la base de données permet aux transactions d'être exécutées simultanément. Cependant, si plusieurs transactions opèrent sur le même objet en même temps, il y aura inévitablement des conflits. L'état intermédiaire de la transaction peut être exposé à d'autres transactions, ce qui entraîne que certaines transactions écrivent la mauvaise valeur dans la base de données en fonction de l'état intermédiaire d'autres transactions. Il est nécessaire de fournir un mécanisme pour garantir que l'exécution des transactions ne soit pas affectée par des transactions simultanées, de sorte que les utilisateurs sentent que seules les transactions initiées par eux-mêmes sont actuellement exécutées, ce qui est l' isolement .

L'isolement permet aux utilisateurs de se concentrer sur la logique d'une seule transaction, quel que soit l'impact de l'exécution simultanée. La base de données garantit l'isolement grâce à un mécanisme de contrôle de concurrence. L'isolation nécessitant un ordre d'exécution des transactions plus élevé, de nombreuses bases de données offrent différentes options et les utilisateurs peuvent sacrifier une certaine isolation pour améliorer les performances du système. Ces différentes options sont des niveaux d'isolement des transactions .

La base de données reflète le monde réel. Il existe de nombreuses restrictions dans le monde réel. Par exemple: peu importe la façon dont le compte est transféré, le montant total ne changera pas et d'autres contraintes pratiques; l'âge ne peut pas être négatif et le sexe ne peut avoir que trois types: masculin, féminin et transgenre. Contraintes d'intégrité telles que les options. L'exécution de la transaction ne peut pas briser ces contraintes et garantir que la transaction est transférée d'un état correct à un autre état correct. C'est la cohérence .

La différence et les trois premières propriétés sont entièrement garanties par l'implémentation de la base de données. La cohérence dépend non seulement de l'implémentation de la base de données (atomicité, durabilité, isolation est également pour assurer la cohérence), mais également de la logique de transaction écrite côté application.

1.2 Comment garantir l'isolement des transactions

Afin d'assurer l'isolement, une façon consiste à exécuter toutes les transactions en série afin que les transactions n'interfèrent pas entre elles. Cependant, l'efficacité d'exécution en série est très faible. Afin d'augmenter le débit et de réduire le temps de réponse, la base de données permet généralement d'exécuter simultanément plusieurs transactions. Par conséquent, le module de contrôle d'accès simultané doit garantir que l'effet de l'exécution simultanée des transactions est exactement le même que l'effet de l'exécution en série des transactions (sérialisabilité) afin de répondre aux exigences d'isolement.

Afin de faciliter la description de la façon dont le contrôle de concurrence garantit l'isolement, nous simplifions le modèle de transaction. Une transaction est composée d'une ou plusieurs opérations, et toutes les opérations peuvent éventuellement être divisées en une série de lectures et d'écritures. Un lot de transactions simultanées, toutes en ordre d'exécution en lecture et en écriture, est défini comme un planning, par exemple:

T1 et T2 sont exécutés en même temps, un planning possible:

T1.read (A), T2.read (B), T1.write (A), T1.read (B), T2.write (A)

Si l'effet de planification de l'exécution simultanée de transactions est équivalent à l'exécution en série (planification en série), la sérialisabilité peut être satisfaite. Un programme change continuellement l'ordre des opérations de lecture et d'écriture, et il deviendra toujours un programme sérialisable, mais certains échanges peuvent entraîner des résultats différents de l'exécution des transactions. Dans un planning, la position de deux opérations adjacentes modifie le résultat de la transaction, puis ces deux opérations sont en conflit . Le conflit doit remplir simultanément les conditions suivantes:

Ces deux opérations proviennent d'opérations différentes
L'une au moins est une opération d'écriture
Opérer de la même façon

Par conséquent, les conflits courants incluent:

Lire et écrire des conflits. La transaction A lit d'abord une ligne de données, la transaction B modifie la ligne de données et la transaction B modifie d'abord une ligne de transactions et la transaction A lit l'enregistrement de ligne. La transaction A lit différents résultats. Ce conflit peut entraîner une vision de lecture non reproductible et une vision de lecture sale.
Écrivez et lisez les conflits. La même raison que le conflit de lecture-écriture. Ce conflit peut conduire à une vision de lecture sale.
Écrivez le conflit. Deux opérations écrivent un objet en séquence et le résultat de cette dernière opération détermine le résultat final de l'écriture. Ce conflit peut entraîner une perte de vision des mises à jour.

Tant que la base de données garantit que le calendrier des transactions simultanées conserve inchangé l'ordre d'exécution des opérations en conflit, seules les opérations de non-conflit peuvent devenir un calendrier en série et peuvent être considérées comme équivalentes.

Cette méthode de jugement d'équivalence est appelée équivalent de conflit: la séquence conflictuelle des deux horaires est la même . Par exemple, dans l'exemple ci-dessous, l'écriture T1 (A) entre en conflit avec la lecture T3 (A) et T1 se produit avant T3. Conflit de lecture (B) et d'écriture (B) T1, et T2 précède T1, de sorte que le calendrier exécuté par la transaction de gauche est équivalent au calendrier série (à droite) exécuté par T2, T1 et T3. La séquence d'exécution dans la figure de gauche satisfait la sérialisation du conflit.

.png ")

Analysons un contre-exemple: T1 en lecture (A) entre en conflit avec T2 en écriture (A) et T1 précède T2, et T2 en écriture (A) entre en conflit avec T2 en écriture (A) et T2 précède T1. La planification suivante ne peut pas être équivalente à une planification série. Il s'agit d'une séquence d'exécution qui ne répond pas à la sérialisation du conflit et entraînera la perte de la mise à jour.

.png ")

En général, la sérialisation est une exigence relativement stricte. Afin d'améliorer les performances simultanées des systèmes de base de données, de nombreux utilisateurs sont prêts à réduire les exigences d'isolement pour rechercher de meilleures performances. Les systèmes de base de données implémentent souvent plusieurs niveaux d'isolement pour que les utilisateurs puissent choisir de manière flexible. Pour le niveau d'isolement des transactions, veuillez consulter cet article .

Les exigences du contrôle d'accès simultané sont claires, comment y parvenir? L'article suivant présente les méthodes d'implémentation courantes du contrôle d'accès concurrentiel une par une en fonction de l'optimisme de la détection des conflits.

Contrôle d'accès simultané basé sur un verrouillage en deux étapes

2.1
Puisque 2PL doit s'assurer que les opérations sont effectuées dans le bon ordre, la manière la plus simple de penser est de verrouiller et de protéger l'objet d'accès. Le module de gestion des verrous du système de base de données est spécifiquement responsable du verrouillage et de la libération des verrous pour accéder aux objets, garantissant que seule la transaction contenant le verrou peut faire fonctionner l'objet correspondant . Les verrous peuvent être divisés en deux catégories: S-Lock et X-Lock. S-Lock est un verrou partagé utilisé pour les demandes de lecture et X-Lock est un verrou exclusif utilisé pour les demandes d'écriture. Leur compatibilité est la suivante: fonctionnant sur le même objet, seules deux requêtes de lecture sont compatibles entre elles et peuvent être exécutées en même temps, et les opérations de lecture et d'écriture seront exécutées en série en raison de conflits de verrouillage. 2PL (verrouillage en deux phases) est le protocole de contrôle d'accès concurrentiel basé sur le verrouillage le plus courant pour les bases de données. Comme son nom l'indique, il contient deux phases:

Phase un: En croissance, la transaction demande tous les verrous dont elle a besoin au gestionnaire de verrouillage (il peut y avoir un échec de verrouillage).
Phase 2: rétrécissement, la transaction libère le verrou acquis dans la phase de croissance et aucun nouveau verrou n'est autorisé.

Pourquoi le verrouillage et le déverrouillage devraient-ils être clairement divisés en deux étapes? Le contrôle d'accès simultané 2PL a pour but de réaliser la sérialisation. Si le contrôle d'accès simultané n'applique pas tous les verrous requis à l'avance, mais après avoir relâché le verrou, il est autorisé à le demander à nouveau. Il peut y avoir deux opérations dans la transaction entre le même objet, d'autres transactions le modifient Un objet (comme illustré dans la figure ci-dessous), puis incapable d'atteindre le conflit sérialisable, il y a incohérence (l'exemple suivant est une mise à jour perdue). 2PL peut garantir la sérialisation des conflits, car la transaction doit obtenir tous les verrous requis pour s'exécuter. Par exemple , la transaction A en cours d'exécution entre en conflit avec la transaction B et la transaction B est déjà exécutée ou est toujours en attente. Par conséquent, l'ordre d'exécution de ces opérations en conflit est le même que l'ordre d'exécution des opérations en conflit lorsque BA ou AB est exécuté en série. Donc, tant que la base de données utilise 2PL pour assurer la cohérence et l'isolement? Jetons un œil à cet exemple: l' ordre d'exécution ci - dessus est conforme à 2PL, mais T2 lit les données non validées. Si T1 est annulé à ce moment, cela entraînera une annulation en cascade (les modifications T1 ne peuvent être vues par aucune transaction). Par conséquent, la base de données utilise souvent une version améliorée de S (trong) S (trict) 2PL, qui est un peu différente de 2PL: dans la phase de rétrécissement, le verrou ne peut être libéré qu'une fois la transaction terminée, éliminant complètement les données non validées de la transaction A été lu.

2.2 Gestion de l'impasse

Le verrouillage et la libération des verrous pour les transactions simultanées contournent inévitablement un blocage: la transaction 1 contient les verrous B tels que le verrou A, et la transaction 2 contient les verrous A tels que le verrou B. Il existe actuellement deux solutions au problème de blocage:

Détection de blocage:

Le système de base de données enregistre la relation d'attente de la transaction selon le graphique des attentes, où le point représente la transaction et le bord dirigé représente la transaction attend qu'une autre transaction libère le verrou. Lorsqu'un anneau apparaît dans le graphique des attentes, cela signifie qu'un blocage s'est produit. L'arrière-plan du système détectera périodiquement le graphique des attentes. Si une sonnerie est trouvée, une interruption de transaction appropriée doit être sélectionnée.

Prévention de l'impasse:

Lorsqu'une transaction demande un verrou qui est déjà retenu, le système de base de données tue l'une des transactions pour éviter les blocages (généralement plus la transaction dure, plus la priorité de réservation est élevée). Cette approche de précaution ne nécessite pas de graphiques d'attente, mais augmente le taux auquel les transactions sont tuées.

2.3 Verrouillage d'intention

S'il n'y a que des verrous de ligne, alors si une transaction doit mettre à jour 100 millions d'enregistrements, elle doit acquérir 100 millions de verrous de ligne, ce qui consommera beaucoup de ressources de mémoire. Nous savons que les verrous sont utilisés pour protéger les objets d'accès internes de la base de données. Ces objets peuvent être: Attribut, Tuple, Page, Table. Les verrous correspondants peuvent être divisés en verrous de ligne et en pages. Verrous, verrous de table (personne n'implémente de verrous d'attribut. Pour les bases de données OLTP, la plus petite unité d'opération est une ligne). Pour les transactions, il est bien sûr préférable d'obtenir le plus petit nombre de verrous, comme la mise à jour de 100 millions d'enregistrements, l'ajout d'un verrou de table est peut-être suffisant. Les verrous de niveau supérieur (tels que les verrous de table) peuvent réduire efficacement l'utilisation des ressources et réduire considérablement le nombre de vérifications de verrouillage, mais limiteront considérablement la concurrence. Les verrous de niveau inférieur (tels que les verrous de ligne) sont propices à l'exécution simultanée, mais dans le cas de nombreux objets de demande de transaction, un grand nombre de vérifications de verrouillage sont nécessaires. Afin de résoudre le problème de verrouillage de haut niveau limitant la concurrence, le système de base de données introduit le concept de verrouillage d'intention:

Intention partagée (IS): indique qu'un ou plusieurs objets qu'il contient sont protégés par S-Lock. Par exemple, si une table est ajoutée avec IS, au moins une ligne de la table est protégée par S-Lock.
Intention-Exclusive (IX): indique qu'un ou plusieurs objets qu'il contient sont protégés par X-Lock. Par exemple, une table plus IX, au moins une ligne de la table est protégée par X-Lock.
Shared + Intention-Exclusive (SIX): indique qu'au moins un objet à l'intérieur est protégé par X-Lock et lui-même est protégé par S-Lock. Par exemple, une opération nécessite une analyse complète de la table et modifie quelques lignes de la table, vous pouvez ajouter SIX à la table. Les lecteurs peuvent se demander pourquoi il n'y a pas de XIX ou XIS

La relation de compatibilité entre le verrou intentionnel et le verrou ordinaire est la suivante: L'avantage du verrou intentionnel est que lorsque la table est ajoutée avec IX, cela signifie qu'il y a une ligne dans la table qui est en cours de modification. (1) À ce stade, l'opération DDL est lancée sur la table et le verrou X de la table doit être demandé. Ensuite, lorsque la table contient IX, elle attend directement sans vérifier si les lignes de la table contiennent des verrous une par une, ce qui réduit efficacement les frais généraux d'inspection . (2) Pour le moment, il existe d'autres transactions de lecture et d'écriture. Comme la table est ajoutée IX au lieu de X, cela n'empêchera pas les demandes de lecture et d'écriture pour la ligne (ajoutez d'abord IX à la table, puis ajoutez S / X à l'enregistrement) Si la transaction n'implique pas la ligne verrouillée en X, elle peut être exécutée normalement, augmentant la simultanéité du système. 03

Contrôle d'accès simultané basé sur l'ordre de synchronisation (T / O)

Attribuez un horodatage à chaque transaction et utilisez-le pour déterminer l'ordre d'exécution des transactions. Lorsque l'horodatage de la transaction 1 est inférieur à la transaction 2, le système de base de données doit s'assurer que la transaction 1 est exécutée avant la transaction 2. Les méthodes de distribution d'horodatage comprennent: (1) l'horloge physique; (2) l'horloge logique; (3) l'horloge mixte.

3.1 T / O de base

Basé sur le contrôle de concurrence T / O, aucun verrou n'est requis pour la lecture et l'écriture, et chaque ligne d'enregistrement marque l' horodatage de la transaction qui a été modifiée et lue en dernier . Lorsque l'horodatage de la transaction est inférieur à l'horodatage enregistré (ne peut pas lire les données "futures"), il doit être abandonné et réexécuté. Supposons que l'enregistrement X soit marqué avec deux horodatages en lecture et en écriture: WTS (X) et RTS (X), l'horodatage de la transaction est TTS et le jugement de visibilité est le suivant: lire:

TTS <WTS (X): l'objet n'est pas visible pour la transaction, abandonner la transaction, prendre un nouvel horodatage et recommencer.
TTS> WTS (X): Cet objet est visible pour la transaction, mettre à jour RTS (X) = max (TTS, RTS (X)) Afin de satisfaire une lecture répétable, la valeur de X est copiée par la transaction.
Pour empêcher la lecture de données sales, des marques spéciales peuvent être apposées sur l'enregistrement. La demande de lecture doit attendre que la transaction soit soumise avant d'être lue.

Écrivez:

TTS <WTS (X) || TTS <RTS (X): abandonner la transaction, redémarrer.
TTS> WTS (X) && TTS> RTS (X): mise à jour de la transaction X, WTS (X) = TTS.

La raison pour laquelle TTS> RTS (X) est nécessaire ici est d'éviter la situation suivante: l'horodatage de la demande de lecture est rts, X a été lu et l'horodatage est défini sur RTS (X) = rts. ), Et la mise à jour réussit, la demande de lecture rts est relue pour voir les nouvelles modifications, ce qui viole la lecture répétable, afin d'éviter les conflits de lecture et d'écriture. La dernière heure de lecture et d'écriture est stockée dans l'enregistrement, ce qui garantit que le conflit sérialisable peut également éviter un biais d'écriture. Par exemple: l'état initial, les enregistrements X et Y, X = -3, Y = 5, X + Y> 0, RTS (X) = RTS (Y) = WTS (X) = WTS (Y) = 0. L'horodatage de la transaction T1 est TTS1 = 1 et l'horodatage de la transaction T2 est TTS2 = 2. .png ") Ses défauts incluent:

Les transactions longues sont sujettes à la famine, car l'horodatage des transactions longues est trop petit, et il y a une forte probabilité que les données mises à jour soient lues après une période d'exécution, entraînant un abandon.
Les opérations de lecture génèrent également des écritures (écriture RTS).

Contrôle d'accès simultané basé sur la validation (OCC)

Pendant le processus d'exécution, chaque transaction conserve sa propre opération d'écriture (Basic T / O écrit des données dans la base de données pendant l'exécution de la transaction) et le RTS / WTS correspondant, et juge si ses modifications et celles existantes dans la base de données sont soumises Conflits de données, écrivez dans la base de données s'il n'y a pas de conflit. OCC est divisé en trois étapes:

Phase de lecture et d'écriture: la phase de lecture et d'écriture, la transaction conserve les résultats de lecture et les modifications à venir, ainsi que les enregistrements écrits RTS et WTS.
Phase de validation: vérifiez si la transaction entre en conflit avec les données de la base de données.
Phase d'écriture: écriture sans conflit, conflit, abandon, redémarrage.

La phase de lecture et d'écriture est terminée et entrer dans la phase de validation équivaut à terminer la préparation de la transaction et à entrer dans la phase de validation. Le temps pour entrer dans la phase de validation est sélectionné comme horodatage de la ligne d'enregistrement à séquencer. La raison pour laquelle l'heure de début de la transaction n'est pas utilisée est la suivante: la durée d'exécution de la transaction peut être plus longue et la transaction qui démarre plus tard peut être soumise en premier, ce qui augmentera la probabilité de conflit de transaction. La transaction avec un horodatage plus petit sera écrite dans la base de données après la transaction.

Processus de validation

En supposant qu'il n'y a que deux transactions T1 et T2, et que la même ligne de données est modifiée, l'horodatage de T1 <l'horodatage de T2 (c'est-à-dire l'ordre de validation: T1 <T2, pour les utilisateurs, T1 apparaît d'abord dans T2), il y a Situation: (1) T1 est en phase de validation et T2 est toujours en phase de lecture et d'écriture. À ce moment, tant qu'il n'y a pas de conflit entre la lecture et l'écriture qui s'est produite en T1 et T2, vous pouvez soumettre.

Si WS (T1) ∩ (RS (T2) ∪ WS (T2)) = ∅, cela signifie qu'il n'y a pas de conflit entre les enregistrements écrits par T2 et T1, et la vérification peut être écrite.
Sinon, il y a un conflit de lecture-écriture ou un conflit d'écriture-écriture entre T2 et T1, et T1 doit être annulé. Conflits de lecture et d'écriture: T2 lit la version avant l'écriture de T1. Après la validation de T1, il peut lire la version écrite par T1, qui ne peut pas être lue de manière répétée. Conflits d'écriture et d'écriture: T2 peut être mis à jour sur la base de l'ancienne version et réécrit, entraînant la perte de la mise à jour de T1.

(2) T1 termine la phase de validation et entre dans la phase d'écriture jusqu'à ce que la soumission soit terminée, ce qui est déjà irréversible. La lecture et l'écriture de T2 avant que T1 n'entre dans la phase d'écriture ne doivent pas entrer en conflit avec le fonctionnement de T1 (car la validation T1 a réussi). Les opérations de lecture et d'écriture poursuivies après T2 peuvent entrer en conflit avec l'opération à soumettre par T1, donc T2 entre dans la phase de validation:

Si WS (T1) ∩ RS (T2) = ∅, cela signifie que T2 n'a pas lu l'enregistrement écrit par T1, la vérification est réussie et T2 peut écrire. (Pourquoi ne pas vérifier WS (T2)? WS (T1) a été soumis et son horodatage est inférieur à WS (T2). Il ne doit pas y avoir de conflit dans la partie précédente de WS (T2) et la partie suivante, car il n'a pas été lu. L'objet écrit par T1 est correct pour écrire, et n'écrasera pas l'écriture de WS (T1))
Sinon, il y a un conflit de lecture-écriture et un conflit d'écriture-écriture entre T2 et T1, et T2 doit être annulé. Conflits de lecture et d'écriture: T2 lit la version avant l'écriture de T1. Après la validation de T1, il peut lire la version écrite par T1, qui ne peut pas être lue de manière répétée. Conflits d'écriture et d'écriture: T2 peut être mis à jour sur la base de l'ancienne version et réécrit, entraînant la perte de la mise à jour de T1.

Contrôle d'accès simultané basé sur MVCC

La base de données gère plusieurs versions physiques d'un enregistrement. Lorsqu'une transaction est écrite, une nouvelle version des données écrites est créée et la demande de lecture obtient la dernière version des données qui existe déjà à ce moment sur la base des informations d'instantané au début de la transaction / instruction. Les avantages les plus directs qu'il apporte sont: l'écriture ne bloque pas la lecture, la lecture ne bloque pas l'écriture et les demandes de lecture n'échoueront jamais en raison de conflits (tels que la version unique T / O) ou d'attente (telles que la version unique 2PL). Pour les demandes de base de données, il y a souvent plus de demandes de lecture que de demandes d'écriture. Presque toutes les bases de données grand public utilisent cette technologie d'optimisation. MVCC est une technologie d'optimisation pour les demandes de lecture et d'écriture. Elle ne résout pas complètement le problème de concurrence de base de données. Elle doit être combinée avec les plusieurs technologies de contrôle de concurrence susmentionnées pour fournir des capacités complètes de contrôle de concurrence. Les types courants de technologies de contrôle d'accès simultané incluent: MV-2PL, MV-T / O et MV-OCC, leurs caractéristiques sont les suivantes: .png ") MVCC a également deux points clés à considérer: stockage de données multi-version et redondant Recyclage des données de version. Les méthodes de stockage de données multi-versions peuvent être grossièrement divisées en deux catégories: (1) Ajoutez uniquement la méthode, les anciennes et les nouvelles versions sont stockées dans le même espace table, comme le moteur de stockage basé sur LSM-Tree. (2) Espace table principal Enregistrez la dernière version des données, l'image précédente est enregistrée dans d'autres espaces table ou segments de données, tels que les informations multi-versions d'InnoDB sont enregistrées dans le journal d'annulation. La collecte de données multi-version est également connue sous le nom de garbage collection (GC), celles qui n'ont aucune chance d'être acquises par une demande de lecture les anciennes versions de dossiers, doivent être rapidement retirés. 06

Résumé

Cet article présente les transactions basées sur les verrous (prévention des conflits avant le début des transactions), les T / O (évaluation des conflits lors de l'exécution des transactions) et la validation (vérification des conflits lorsque les transactions sont validées) en fonction du calendrier de gestion des conflits (optimisme). Mécanisme de contrôle d'accès simultané. Différentes implémentations conviennent à différentes charges de travail, et les charges de travail avec de faibles conflits de concurrence sont certainement adaptées à des méthodes de contrôle de concurrence plus optimistes. MVCC peut résoudre le problème du blocage mutuel entre les transactions en lecture seule et les transactions en lecture-écriture, améliorer la lecture simultanée des transactions et est adopté par la plupart des systèmes de base de données traditionnels.