Réponse.

Contexte historique

Le concept de multi-version (MVCC, Multi-Version Concurrency Control) est né comme une alternative aux verrouillages stricts, afin d'assurer le bon fonctionnement simultané d'un grand nombre de transactions. Cela était important pour réduire les conflits et les blocages lors de l'accès simultané aux données, ce qui est particulièrement critique dans les systèmes OLTP.

Problématique

Les approches traditionnelles de verrouillage (comme le verrouillage au niveau des lignes) peuvent ralentir les applications en cas de forte concurrence. La tâche de MVCC est de permettre aux transactions de lire des instantanés cohérents des données, même si des opérations d'écriture sont exécutées en parallèle, garantissant ainsi l'isolation et l'accès simultané.

Solution

MVCC est implémenté dans des SGBD populaires (PostgreSQL, Oracle, MySQL/InnoDB) grâce au stockage d'histoires de versions de lignes. Lors de la lecture, chaque transaction ne voit que les lignes qui ont été validées avant son démarrage, et les insertions/mises à jour créent de nouvelles versions de lignes sans suppression immédiate.

Exemple de requête (PostgreSQL) :

BEGIN TRANSACTION;
SELECT * FROM orders WHERE status = 'processing';
UPDATE orders SET status = 'completed' WHERE id = 42;
COMMIT;

Tant que la transaction n'est pas terminée, les autres utilisateurs verront la version précédente de la ligne, et ce n'est qu'après le commit que les modifications seront accessibles aux nouvelles transactions.

Caractéristiques clés :

MVCC prévient les blocages lors de la lecture (les lecteurs ne bloquent pas les écrivains, les écrivains ne bloquent pas les lecteurs).
Il est facile de réaliser des "instantanés" (snapshots) des données pour l'analyse.
Les anciennes versions des lignes nécessitent un nettoyage périodique (VACUUM/garbage collection).

Questions pièges.

MVCC peut-il éliminer complètement tous les types de verrouillage et de conflits ?

Non, dans MVCC, des conflits restent possibles lors de mises à jour simultanées des mêmes lignes — par exemple, avec des UPDATE simultanés, il y a un conflit de commit (write-write conflict), et le SGBD renvoie une erreur ou annule l'une des transactions.

Quand les anciennes versions des lignes sont-elles supprimées dans MVCC et cela peut-il entraîner des fuites de mémoire ?

Dans la plupart des SGBD, les anciennes versions des lignes sont supprimées par des processus spéciaux (VACUUM dans PostgreSQL). Si ces processus ne sont pas lancés, la base "gonfle" et la performance diminue.

Les "select for update" fonctionnent-elles correctement dans un environnement MVCC, et pourquoi un verrouillage est-il nécessaire ?

Oui, les requêtes SELECT FOR UPDATE bloquent les lignes pour éviter les conflits lors de modifications parallèles, sinon des "lost updates" pourraient survenir.

Exemple :

BEGIN;
SELECT * FROM products WHERE id = 123 FOR UPDATE;
UPDATE products SET quantity = quantity - 1 WHERE id = 123;
COMMIT;

Erreurs typiques et anti-patterns

Ne pas tenir compte de la nécessité de nettoyer les lignes "mortes", ce qui entraîne une augmentation de la base et une diminution des performances.
Ignorer les conflits write/write — se fier uniquement à MVCC sans vérifier les erreurs de commit.
Mélanger différents niveaux d'isolation des transactions sans comprendre leur impact sur la cohérence.

Exemple de la vie réelle

Cas négatif

Dans un grand site de commerce électronique, un schéma a été mis en place avec des UPDATE fréquents des commandes sans configuration de VACUUM. Au bout d'un mois, la base a augmenté de 10 fois, et les requêtes ont considérablement ralenti.

Avantages :

Haute parallélisme au début, mise en œuvre rapide.

Inconvénients :

Occupation d'espace disque, panne du système à fort volume.

Cas positif

Un autovacuum régulier a été mis en œuvre, un contrôle des write-conflicts a été utilisé, l'isolation au niveau READ COMMITTED uniquement pour les requêtes critiques.