Re: SQL, transactions et isolation

Bonsoir,

Je n'ai quasiment aucune expérience directe des autres SGBD (uniquement pour
la durée d'une migration, et c'est tant mieux), mais j'ai eu l'occasion de
parler un peu du sujet et voilà ce que j'en ai retenu:

Le mercredi 10 décembre 2008, Stephane Bortzmeyer a écrit :
> <http://www.postgresql.org/docs/current/interactive/mvcc.html> et
[...]
> Ce comportement de "snapshot" de PostgreSQL est-il imposé par la norme
> SQL ? Pas sûr, on peut sans doute être compatible avec la norme en
> mettant des simples verrous qui bloquent la transaction de lecture
> tant que des écritures sont en cours. Si ce n'est pas standard, quel
> SGBD a les mêmes capacités que PostgreSQL ? Tous ? Aucun ?

Le standard impose quatre modes de transactions, et PG n'en supporte que deux,
comme indiqué dans la Table 13-1. SQL Transaction Isolation Levels.

Le fait de ne pas vérouiller est du à MVCC, fait pour résoudre le soucis. Les
concurrents ont tous plus ou moins MVCC, mais avec des implémentation
différentes.

Pour PostgreSQL chaque ligne enregistrée dans la base est "visible" entre son
xmin et son xmax, et chaque ordre SQL doit s'assurer de voir la bonne version
(les transactions aussi ont une notion de xmin et xmax).
Les avantage c'est qu'on peut avoir beaucoup de transaction en parallèle avec
chacune son snapshot, que pg_dump garanti à chaud une vision cohérente de
l'ensemble de la base, les COMMIT et ROLLBACK sont très rapides, etc.
Les inconvénients c'est VACUUM, le bloat, l'absence de covering indexes, etc.
Notons que la version 8.4 va bien améliorer la situation avec la Visibility
Map, et que par la suite (pas en 8.4) on devrait voir les covering indexes
arriver dans PG ;)

http://www.postgresql.org/docs/8.3/interactive/ddl-system-columns.html
http://www.postgresql.org/docs/8.3/interactive/functions-info.html#FUNCTIONS-TXID-SNAPSHOT

C'est là que je vais sûrement raconter n'importe quoi (déjà que pour ce qui
est dit avant c'est mieux de vérifier...) :

MySQL fait du MVCC à base de verrous sur la table en MyISAM, et en InnoDB je
ne sais pas trop. Oracle fait du MVCC à base de redo logs, il ne souffre pas
des soucis vacuum mais le rollback rempli les logs, et il me semble que les
anciennes versions de lignes sont à aller chercher dans les redo logs aussi.
Je sais pas trop.
Le MVCC dans DB2 ressemble à celui de PostgreSQL au niveau des idées, il me
semble avoir compris, quant à Informix et Sybase et MS SQL, je n'en sais
rien. Et Firebird et Ingres, aucune idée non plus.

Bref, pour faire de l'isolation de transactions (requis par ACID, c'est le I)
de manière efficace, il faut implémenter MVCC. D'une manière ou d'une
autre ;)

En espérant que ça aide plus que ça ne rend tout flou,
--
Dimitri Fontaine, DBA PostgreSQL, Architecte