Contrôle des accès concurrents dans PostgreSQL (Multi version concurrency Control, MVCC ou MCC) 12 Mai 2023 par Robert Gravelle

Alors que la plupart des systèmes de bases de données utilisent des verrous pour la gestion des accès simultanés, PostgreSQL fait les choses un peu différemment : il maintient la cohérence des données en utilisant un modèle multi-version, également connu sous le nom de contrôle des accès concurrents (Multi version concurrency control ou MVCC en abrégé). Par conséquent, lors de l’interrogation d’une base de données, chaque transaction voit un instantané des données telles qu’elles étaient quelque temps auparavant, quel que soit l’état actuel des données sous-jacentes. Cela empêche la transaction d'afficher des données incohérentes qui pourraient être provoquées par d'autres mises à jour de transactions simultanées sur les mêmes données. Cela fournit une isolation des transactions pour chaque session de base de données. Cet article du blog fournira un bref aperçu du fonctionnement du protocole MVCC et couvrira certains des avantages et des inconvénients de l'approche MVCC.

Explication de la méthode MVCC

La principale différence entre les modèles de verrouillage et MVCC est que ce dernier garantit que la lecture ne bloque jamais l'écriture et que l'écriture ne bloque jamais la lecture.

Avec MVCC, chaque transaction a un marqueur temporel, une estampille (timestamp en anglais) qui indique (a) quand elle a démarré et (b) quand une transaction met à jour un élément, tel qu'un champ, un enregistrement ou une table. Une nouvelle version de cet élément est créée tout en conservant l'ancienne version. Chaque version est fournie avec :

un timestamp d'écriture pour indiquer l'heure à laquelle la transaction a été créé
un timestamp de lecture pour indiquer quand la dernière transaction de lecture a eu lieu

L'idée de base du protocole MVCC est que le gestionnaire de transactions n'autorise les opérations que si elles sont cohérentes avec toutes les transactions exécutées dans leur intégralité au moment de leur horodatage (timestamping). C’est ce qu’on appelle l’ordre d’exécution présumé. Jan Hidders, chercheur en bases de données, explique comment le gestionnaire de transactions y parvient :

Si une transaction souhaite lire un élément, elle a accès à la version qu'elle aurait lue dans l'ordre d'exécution présumé. Ce sera celui avec le dernier timestamp d'écriture juste avant son propre horodatage. Par exemple, s'il existe des versions avec les estampilles d'écriture 5, 12 et 20 et que l’estampille de la transaction est 14, alors la version avec le timestamp d'écriture 12 est celle lue par cette transaction dans l'ordre d'exécution présumé.

Si une transaction veut écrire un élément, on vérifie s'il n'y a pas une opération de lecture qui a été autorisée plus tôt et qui, dans l'ordre d'exécution présumé, lirait la nouvelle version provoquée par l'opération d'écriture demandée, mais lorsqu'elle a été autorisée, elle lit une autre version. Par exemple, supposons à nouveau que nous ayons des versions avec des estampilles d'écriture 5, 10 et 16. Supposons également que les horodatages de lecture de ces versions soient respectivement 8, 12 et 20. Si une transaction avec l’estampille 11 veut mettre à jour l'élément, il y a un problème, car la version avec l'horodatage d'écriture 10 a été lue par une transaction avec l'horodatage 12. Ainsi, si une version avec l'horodatage 11 est créée, la transaction avec l'horodatage 12 n'aurait pas vu, dans l'ordre d'exécution présumé, la version créée par la transaction avec l'horodatage 10, mais celle qui est maintenant sur le point d'être créée avec l'horodatage 11. Si, par contre, une transaction avec l'horodatage 14 veut écrire l'élément, c'est très bien, car pour autant que nous le sachions, après t=12 dans l'ordre d'exécution présumé, l'élément n'a été lu par aucune transaction jusqu'au moment où il a été mis à jour à t=16.

Avantages et inconvénients de MVCC

Avantages:

Comme vous pouvez le constater dans la description ci-dessus, toutes les opérations de lecture seront toujours autorisées immédiatement. Ce n'est généralement pas le cas dans une approche basée sur les verrous, dans laquelle les accès en lecture peuvent être refusés en raison de verrous en écriture existants.
Cela tend également à permettre l'exécution immédiate d'un plus grand nombre d'opérations d'écriture que les approches basées sur le verrouillage ne le font habituellement.

Inconvénients:

Si une opération d'écriture est refusée, il n'y a pas d'autre alternative que d'annuler ou de redémarrer la transaction : une fois la mise à jour refusée, elle le sera également si nous la réessayons plus tard. Cela diffère des approches basées sur le verrouillage, dans lesquelles nous pouvons généralement attendre que le verrou soit disponible. C'est pour cette raison que MVCC est classé comme un protocole optimiste : il est très efficace s'il n'y a pas de conflits, mais une fois qu'il y en a un, vous devrez peut-être annuler beaucoup de travail.
Les nombreuses versions d'un élément peuvent nécessiter beaucoup plus d'espace de stockage. Dans les approches basées sur le verrouillage, seule une version doit être stockée.
La suppression de versions qui ne sont plus nécessaires peut entraîner une certaine surcharge.