Discussion :

[Fanfaron]

Namaste ! Je suis en train de lire un cours sur mysql.

Je viens de finir le chapitre sur l'isolation. Je pensais avoir compris la différence entre les niveaux repeatable read et read commited et pourtant en faisant des tests je n'obtiens aucune différence.

Ce que je pense avoir compris : En mode repeatable read (activé par défaut) je suis censé obtenir toujours le même résultat si je fais un select sur une ligne et qu'une autre session la modifie.

En mode committed read, je suis censé obtenir le dernier résultat committé.

J'ai donc fait des tests avec deux sessions sur mysql workbench, et en mode repeatable read j'obtiens le dernier résultat commité.

Exemple j'ouvre deux sessions en même temps et je suis en mode repeatable read:
table bateau:

id=5 nom='yacht'

Session 1: selectionne cette ligne j'obtiens ce résultat.

Session 2: start transaction; update bateau set nom='barque' where id=5; commit;

Session 1: je select à nouveau cette ligne et j'obtiens 'barque'.

Pourquoi est-ce que j'obtiens bien la nouvelle valeur et pas yacht ?

Si je me mets en mode committed read, j'obtiens évidemment la même chose et je ne vois donc aucune différence entre ces modes.

J'ai voulu essayer le mode uncommited read pour vérifier que le changement de niveau d'isolation est bien pris en compte. J'ai donc fais un test un updatant une valeur sans la commit, et j'obtiens bien la valeur non commit sur l'autre session quand je fais un select, donc il n'y a pas de problème à ce niveau.

J'ai fait un autre test en mode commited read: J'ai update une ligne sur la session 1 sans la commit. Et je l'ai selectionné sur la session 2 et ça me donne la valeur initiale. Logique donc puisque ça n'est pas commit, mais je pensais que comme ça cherchait les dernières valeurs, le query n'allait rien me retourner tant que je n'aurais pas commit sur la session 1, un peu comme lors d'un SELECT LOCK in SHARE MODE sur une ligne en update mais encore committ par une autre sessions. Mais non ça se comporte exactement de la même manière qu'en repeatable read.

Quelle est donc la différence entre ces deux niveaux d'isolation.

J'en profite pour poser une autre question purement théorique: sur un site web type réseau social qui aurait environ 5 millions de visiteurs quotidiens, et qui comporte des tables de plusieurs plusieurs millions de lignes, un SELECT LOCK in SHARE MODE ne risque il pas considérablement ralentir le traffic ? Par exemple si une célébrité qui a des centaines de milliers de followers édite un post sur son mur d'actualité (cela se ferait dans une transaction UPDATE) et qu'au même moment des centaines d'utilisateurs aterrissent sur sa page ou l'actualisent (Il y aurait donc un select lock in share mode) si pour une raison quelconque l'update du posts prends du temps alors il ne s'afficherait pas chez les utilisateurs. Ne vaudrait il pas mieux avoir le post initial plutôt que d'attendre. Ou pire la situation inverse: la célébrité veut éditer son posts au moment ou des millions d'autres sessions font un select lock in share mode dessus (ce qui interdit l'écriture tant que c'est pas commit), l'edit de son post risque de prendre beaucoup de temps s'il faut que des milliers de commit soient effectués avant, ça risque même de n'être jamais effectué à cause d'un timeout si la transaction est bloquée trop lontemps.

Quel est votre point de vue à ce sujet ?

Et enfin dernière question: Si une session Update une ligne avec transaction puis committ. Et qu'une autre sessions fait un SELECT classique (donc sans lock in share mode) exactement au moment du commit de l'update. Est il possible que le select renvoie une ligne composée des anciennes et des nouvelles données ?

Par exemple l'entrée initiale est id=3 animal='lapin' nom='bugs bunny' et l'update set animal='canard' nom='daffy duck'

Le SELECT pourrait il renvoyer id=3 animal='canard' nom='bugs bunny' ? La "photographie initiale" de la ligne est prise par quelle session, celle qui fait le SELECT ou celle qui fait l'update ? Si c'est celle qui fait le select comment peut elle photographier une ligne qui en cours de committ ?

Voilà désolé pour le pavé mais je me prends la tête avec ça depuis hier.

[SQLpro]

MySQL est une véritable merde farcie de bugs et tester l'isolation des transactions avec ce pseudo SGBD même pas relationnel ne devrait pas pouvoir vous permettre de comprendre grand chose... A lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux
Lisez le cours que j'ai écrit à ce sujet et testez cela avec SQL Server (la version express est gratuite) : http://sqlpro.developpez.com/isolation-transaction/

Enfin, verrouiller les tables à la main est le plus sur moyen de pourrir les performances de votre SGBDR... C'est au SGBDR de placer les bons verrous au bon moment en fonction du contexte (nature des commandes, étendue des éléments à verrouiller, concurrences...)

Et enfin dernière question: Si une session Update une ligne avec transaction puis committ. Et qu'une autre sessions fait un SELECT classique (donc sans lock in share mode) exactement au moment du commit de l'update. Est il possible que le select renvoie une ligne composée des anciennes et des nouvelles données ?

À partir du moment ou vous êtes au dessus du READ UNCOMMITTED, toutes les lectures sont consistantes...


A +

[skuatamad]

Vous devez explicitement démarrer une transaction dans la session 1 avant : Lecture cohérente non-bloquante

Si vous utilisez le niveau d'isolation REPEATABLE READ, alors les lectures cohérentes dans une même transaction liront le même bilan.

Pour l'exemple du mur de réseau sociaux, il ne faut évidemment pas utiliser un SELECT LOCK in SHARE MODE pour la consultation du mur.

tester l'isolation des transactions avec ce pseudo SGBD même pas relationnel ne devrait pas pouvoir vous permettre de comprendre grand chose...

La gestion des transactions étant différente sur l'ensemble des SGBD (même entre MVCC l'implémentation est différente et donc il peut y avoir quelques effets de bords), ce qui sera réellement inutile c'est de tester l'isolation des transactions sur sqlserver pour développer une appli avec mysql... (même si on peut contester le choix de mysql pour développer une appli surtout fortement transactionnelle)

[Fanfaron]

Salut skuatamad !

Vous devez explicitement démarrer une transaction dans la session 1 avant : Lecture cohérente non-bloquante

Je t'avoue ne pas avoir compris.
La lecture cohérente non-bloquante c'est bien repeatable read ? Elle est donc activé par défaut ? Pour être certain j'ai quand même fait un SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Ensuite j'ai démarré une transaction sur la session 1 (qui fait le select) , puis j'ai fait un update avec la session 2 (via transaction que je committ), puis je suis retourné sur la session, et j'ai fait le select que j'ai commit (la transaction avait donc déjà démarrée) et j'obtiens bien la dernière valeur. Et non pas les anciennes valeurs qui étaient présentes lorsque la session s'est connectée.

tester l'isolation des transactions avec ce pseudo SGBD même pas relationnel ne devrait pas pouvoir vous permettre de comprendre grand chose...
La gestion des transactions étant différente sur l'ensemble des SGBD (même entre MVCC l'implémentation est différente et donc il peut y avoir quelques effets de bords), ce qui sera réellement inutile c'est de tester l'isolation des transactions sur sqlserver pour développer une appli avec mysql... (même si on peut contester le choix de mysql pour développer une appli surtout fortement transactionnelle)

Là aussi je n'ai pas compris. Mysql n'est pas relationnel ? Pourtant j'ai lu qu'elle l'était depuis la version 3 avec le support d'innodb. Pourquoi mysql n'est pas adaptée pour le devéloppement d'une appli transactionnelle ? Pour des raisons de performance ? J'ai lu que que wikipedia l'a utilisé jusqu'en 2012 puis est passé à MariaDB qui est dans sa lignée et d'autre très gros sites comme yahoo et youtube l'utilisent aussi. Je ne peux malheureusement pas utiliser sql server j'ai un mac. Peut on l'installer sur un serveur dédié unix ? Je ne sais pas si j'ai bien compris mais j'ai lu que ça tournait que sous windows, est-ce donc adapté pour un site web avec serveur sous linux ?

[skuatamad]

Un exemple en utilisant le prompt mysql :
session 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
 
mysql> select * from t;
+------+------+
| id   | nom  |
+------+------+
|    5 | d    |
+------+------+
1 row in set (0.00 sec)

session 2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
 
mysql> update t set nom='e' where id=5;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
 
mysql> commit;
Query OK, 0 rows affected (0.03 sec)
 
mysql>

retour à la session 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
mysql> select * from t;
+------+------+
| id   | nom  |
+------+------+
|    5 | d    |
+------+------+
1 row in set (0.00 sec)
 
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
 
mysql> select * from t;
+------+------+
| id   | nom  |
+------+------+
|    5 | e    |
+------+------+
1 row in set (0.00 sec)
 
mysql>

Concernant vos autres questions, mysql est le moins évolué en terme de fonctionnalité (SQL, administration,...) des SGBDR du marché.
Ici c'est un forum sur les bases de données, nous sommes donc peu fan de l'outil le moins évolué (et sqlpro le déteste définitivement )

A titre personnel je lui reproche principalement :
- l'absence des fonctions de fenêtrage
- l'absence des contraintes CHECK (syntaxe acceptée mais non vérifiée...)
- Son laxisme sur le GROUP BY (en configuration par défaut) qui autorise le développeur à coder des requêtes fausses (on en voit ici tous les jours !)

Sqlserver ne s'installe que sur windows, dans le gratuit open source installable sur linux vous avez postgresql plus complet et robuste. Après de gros site utilise mysql (DVP également il me semble) mais dans les sites que vous décrivez il y a peu d'écritures concurrentes.

Le plus important dans mon intervention précédente était :
Il faut tester en profondeur la gestion des transactions et de la concurrence d'accès sur l'outil que vous allez utiliser pour votre appli.
Ne croyez pas que ce que vous savez vrai chez un éditeur le sera chez un autre.

Si vous avez opté pour mysql, les tests que vous menez actuellement sur mysql sont donc primordiaux (et d'ailleurs trop rarement effectués par les développeurs).

[Fanfaron]

Tout d'abord un grand merci pour les exemples !

Je commitais mes transactions dans la session lors du select j'ai enfin compris

Le plus important dans mon intervention précédente était :
Il faut tester en profondeur la gestion des transactions et de la concurrence d'accès sur l'outil que vous allez utiliser pour votre appli.
Ne croyez pas que ce que vous savez vrai chez un éditeur le sera chez un autre.

Si vous avez opté pour mysql, les tests que vous menez actuellement sur mysql sont donc primordiaux (et d'ailleurs trop rarement effectués par les développeurs).

En fait je suis encore dans la phase apprentissage donc j'en profite pour tester presque tout ce que j'apprends en même temps. Je réalise que j'ai du mal à me faire une idée de l'importance que doit prendre la gestion des transactions et de la concurrence dans mes futurs projets. Je pensais naivement apprendre à m'en servir sur mysql grâce au tuto que je lis et appliquer ça bêtement en imaginant que je n'aurais aucun problème si je m'en servais bien.

Sqlserver ne s'installe que sur windows, dans le gratuit open source installable sur linux vous avez postgresql plus complet et robuste.

Je vais me renseigner sur postgresql. L'utilisation de SGBDR ne me servirait que pour la création de sites web donc je peux déjà exclure sqlserver. J'utilise du php en combinaison.

Après de gros site utilise mysql (DVP également il me semble) mais dans les sites que vous décrivez il y a peu d'écritures concurrentes.

Sur wikipedia pourtant n'y a il pas potentiellement beaucoup d'écriture concurrentes sur les pages les plus consultées et donc éditées ? J'ai du mal à imaginer une échelle importante d'écriture concurrente de sites web très fréquentés. Auriez-vous des exemples de site ?

[SQLpro]

PostGreSQL gère aussi très mal les transactions.

Si vous voulez avoir un vrai aperçu de toutes les problématiques utilisez SQL Server. C'est le seul capable de vous montrer clairement ce qu'il en est.

Ce n'est que la 3e fois qu'on vous le dit.
mais vous avez le droit de rester borné !

A +

[Fanfaron]

Oups je suis désolé SQLpro je n'avais pas vu votre premier message, je dois être aveugle !

Pour SQL Server le problème c'est que j'ai un mac et je n'ai pas vraiment envie d'installer windows dessus donc ça me parait difficile pour moi de le tester.

J'ai lu l'article "MySQL ? Un SGBDR poudre aux yeux !" qui m'a un peu refroidi surtout quand vous dites que mysql est 1000 fois moins rapide que PostGreSQL lorsque plus de 5 utilisateurs l'utilisent.

Je suis aussi intrigué par "Car en choisissant l’option GPL, soit disant gratuite, cela contamine le code de votre application".
J'ai fais une petite recherche google et je n'ai absolument rien compris. Quand et comment cette contamination peut elle survenir ? J'ai cru comprendre que cela variait selon les clients mais c'est tout. Et qu'est ce que cette contamination implique ? Je planifiais d'utiliser mysql uniquement comme base de données pour sites web commerciaux, ou petites applications mobiles.

[Rei Ichido]

Autant je suis persuadé qu'il vaut mieux, pour des raisons d'intégrité relationnelle, ne pas choisir MySQL, autant pour ce qui est de la performance, il faut être honnête, il y a de très grosses entreprises qui utilisent MySQL.

[SQLpro]

Hélas souvent contraints et forcé parce qu'on leur a vendu un logiciel qui ne fonctionne qu'avec ça !

Sinon MySQSL est souvent utilisé comme couche de persistance, mais pas de manipulation, car à ce niveau il est vraiment plus que poussif en perf...

A +