Base mysql innoDB et lock

12 réponses

Auteur	Message
vincir \| Membre Inscrit le : 26/10/2007	# Le 27/07/2013 à 18:18 Bonjour, Je suis confronté au problème suivant : - je lis une donnée dans une table (select), la traite, et fait un update si la nouvelle donnée n'est pas négative (update) - Plusieurs scripts faisant ces opérations peuvent être lancé en parallèle. Il faut donc que si le premier script fait un traitement et passe la valeur à 0, le suivant travail avec cette nouvelle valeur et non pas avec la valeur initiale - Jusqu'à maintenant, j'utilisais un lock et un unlock, donc tout fonctionnait correctement. Mais je dois passer mes tables en innoDB, et j'ai lu que dans ce cas il est conseillé de ne pas utiliser les locks mais les transactions. Mais le résultat n'est pas le même, la transaction ne met pas de verrou sur ma table, et la valeur passe donc en négatif si deux scripts tournent en même temps. Est-ce qu'il y a un autre moyen de procédé avec les transactions, ou est-ce que je peux utiliser sans risque les lock avec des tables innoDB ? Merci d'avance pour votre aide Vincent http://www.vrdeveloppement.com : réalisation de sites web et de logiciels personnalisés.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/07/2013 à 18:35 Hello, disons que le «lock table» bloque toute la table, et donc tu perds terriblement en performances oui. Avec InnoDB tu as des verrous par ligne, ce qui permet de faire beaucoup d'accès concurrents (sauf si tous les process travaillent sur la même ligne quoi...). et donc, ta solution, le SELECT ... FOR UPDATE : * start transaction * select XXX for update * update XXX * commit daevel : infogérance et conseil \|\| moi
vincir \| Vincent Membre Inscrit le : 26/10/2007	# Le 27/07/2013 à 18:47 Merci pour la réponse. Donc si mon select me ramène une ligne, tout select suivant qui devrait ramener cette même ligne sera mis en attente jusqu'à ce que un commit soit fait dans le premier process, c'est bien ça ? C'est comme un lock, sauf que si une autre requête lit des valeurs dans la table qui n'ont rien à voir, elle ne sera pas bloqué, c'est bien cela ? http://www.vrdeveloppement.com : réalisation de sites web et de logiciels personnalisés.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/07/2013 à 18:48 Oui & oui. daevel : infogérance et conseil \|\| moi
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 27/07/2013 à 18:57 Je confirme ce que dit Olivier les transactions sont faites pour ça. Par contre effectivement si tes scripts parallélisés attaquent les mêmes lignes, ça va forcément bloquer... Feu d'artifice Paris
vincir \| Vincent Membre Inscrit le : 26/10/2007	# Le 27/07/2013 à 23:55 Et dernière question : faut il aujourd'hui privilégier innoDB à myISAM, ou est-ce un choix à faire en fonction de projet (pour moi chaque format a ses avantages et ses inconvénients, mais j'ai un client qui me soutient que myISAM est dépassé, et qu'il faut obligatoirement utiliser innoDB). http://www.vrdeveloppement.com : réalisation de sites web et de logiciels personnalisés.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 28/07/2013 à 09:40 Dans certains cas MyISAM peut s'avérer utile oui, mais il faut reconnaître que c'est de moins en moins fréquent. Du full InnoDB me choque moins que du full MyISAM. Typiquement dans les versions récentes de MySQL & MariaDB, InnoDB est le moteur par défaut, on n'utilise MyISAM qu'en connaissance de cause. Après pour ma part vu sa faible tolérance aux pannes, j'ai tendance à utilise MyISAM le moins possible. Je n'irais pas jusqu'à dire que MyISAM est dépassé, mais je fais comme s'il l'était daevel : infogérance et conseil \|\| moi
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 28/07/2013 à 22:24 Perso, j'ai le discours totalement inverse d'Olivier. Toujours su récupérer des données en Myisam même après de lourdes corruptions ou problème de disque. Par contre, en innoDB, les statistiques parlent d'elles même : 100 % de perte totale des données. Chacun son expérience comme on dit ... FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 28/07/2013 à 23:41 N'importe quoi caaptusss... on parle quand même des données de sociétés là, va pas jouer avec. InnoDB est ACID, et inclus un contrôle de checksum. MyISAM est très très loin de la sécurité apportée par InnoDB, n'importe quel professionnel te le dira. Et puisqu'on est sur la sécurité des données, pensez à activer l'option «innodb_file_per_table» dès le début ; en cas de crash (drop database par erreur...), cette option permettra aux sociétés spécialisées (Percona, SkySQL, etc) d'intervenir plus facilement. Et de manière plus générale cette option facilite la maintenance. daevel : infogérance et conseil \|\| moi
francois10 \| Francois Membre Inscrit le : 14/05/2006	# Le 28/07/2013 à 23:45 Pour en avoir fait l'expérience, Bool a tout à fait raison sur l'innodb_file_per_table, qui, suite à une erreur et à l'intervention de Percona nous a permis de récupérer des dizaines de Go de data, compressées et partitionnées. Du MyISAM sous très forte charge, je sais pas trop ce que ça donne, mais ça dois pas être le délire... (Message édité le 28-07-2013 à 23h52 par francois10)
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 28/07/2013 à 23:51 Ha bah Myisam sous forte charge, c'est dégueulasse, c'est clair. Bref, je ferme ma gueule puisque mon avis n’intéresse pas... FirstHeberg.com
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 29/07/2013 à 00:46 Je suis full MyIsam personnellement Ça fait ce que je lui demande et ça me va. Chambres d'hote tavel Séjours en provence Forum mariage
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 29/07/2013 à 10:01 De mon experience, pour forumconstruire.com, myisam ne suivait plus et le passage a innodb a tout reglé. http://www.webworkerclub.com/forum/topic,112994,0.... JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes

Auteur

Message

Inscrit le : 26/10/2007

# Le 27/07/2013 à 18:18

Bonjour,

Je suis confronté au problème suivant :

- je lis une donnée dans une table (select), la traite, et fait un update si la nouvelle donnée n'est pas négative (update)

- Plusieurs scripts faisant ces opérations peuvent être lancé en parallèle. Il faut donc que si le premier script fait un traitement et passe la valeur à 0, le suivant travail avec cette nouvelle valeur et non pas avec la valeur initiale

- Jusqu'à maintenant, j'utilisais un lock et un unlock, donc tout fonctionnait correctement. Mais je dois passer mes tables en innoDB, et j'ai lu que dans ce cas il est conseillé de ne pas utiliser les locks mais les transactions. Mais le résultat n'est pas le même, la transaction ne met pas de verrou sur ma table, et la valeur passe donc en négatif si deux scripts tournent en même temps.

Est-ce qu'il y a un autre moyen de procédé avec les transactions, ou est-ce que je peux utiliser sans risque les lock avec des tables innoDB ?

Merci d'avance pour votre aide

Vincent

http://www.vrdeveloppement.com : réalisation de sites web et de logiciels personnalisés.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/07/2013 à 18:35

Hello,

disons que le «lock table» bloque toute la table, et donc tu perds terriblement en performances oui. Avec InnoDB tu as des verrous par ligne, ce qui permet de faire beaucoup d'accès concurrents (sauf si tous les process travaillent sur la même ligne quoi...).

et donc, ta solution, le SELECT ... FOR UPDATE :

* start transaction
* select XXX for update
* update XXX
* commit

daevel : infogérance et conseil || moi

vincir | Vincent
Membre

Inscrit le : 26/10/2007

# Le 27/07/2013 à 18:47

Merci pour la réponse.

Donc si mon select me ramène une ligne, tout select suivant qui devrait ramener cette même ligne sera mis en attente jusqu'à ce que un commit soit fait dans le premier process, c'est bien ça ?
C'est comme un lock, sauf que si une autre requête lit des valeurs dans la table qui n'ont rien à voir, elle ne sera pas bloqué, c'est bien cela ?

http://www.vrdeveloppement.com : réalisation de sites web et de logiciels personnalisés.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/07/2013 à 18:48

Oui & oui.

daevel : infogérance et conseil || moi

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 27/07/2013 à 18:57

Je confirme ce que dit Olivier les transactions sont faites pour ça.
Par contre effectivement si tes scripts parallélisés attaquent les mêmes lignes, ça va forcément bloquer...

Feu d'artifice Paris

vincir | Vincent
Membre

Inscrit le : 26/10/2007

# Le 27/07/2013 à 23:55

Et dernière question : faut il aujourd'hui privilégier innoDB à myISAM, ou est-ce un choix à faire en fonction de projet (pour moi chaque format a ses avantages et ses inconvénients, mais j'ai un client qui me soutient que myISAM est dépassé, et qu'il faut obligatoirement utiliser innoDB).

http://www.vrdeveloppement.com : réalisation de sites web et de logiciels personnalisés.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 28/07/2013 à 09:40

Dans certains cas MyISAM peut s'avérer utile oui, mais il faut reconnaître que c'est de moins en moins fréquent. Du full InnoDB me choque moins que du full MyISAM. Typiquement dans les versions récentes de MySQL & MariaDB, InnoDB est le moteur par défaut, on n'utilise MyISAM qu'en connaissance de cause.

Après pour ma part vu sa faible tolérance aux pannes, j'ai tendance à utilise MyISAM le moins possible. Je n'irais pas jusqu'à dire que MyISAM est dépassé, mais je fais comme s'il l'était

daevel : infogérance et conseil || moi

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 28/07/2013 à 22:24

Perso, j'ai le discours totalement inverse d'Olivier.
Toujours su récupérer des données en Myisam même après de lourdes corruptions ou problème de disque.
Par contre, en innoDB, les statistiques parlent d'elles même : 100 % de perte totale des données.

Chacun son expérience comme on dit ...

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 28/07/2013 à 23:41

N'importe quoi caaptusss... on parle quand même des données de sociétés là, va pas jouer avec. InnoDB est ACID, et inclus un contrôle de checksum. MyISAM est très très loin de la sécurité apportée par InnoDB, n'importe quel professionnel te le dira.

Et puisqu'on est sur la sécurité des données, pensez à activer l'option «innodb_file_per_table» dès le début ; en cas de crash (drop database par erreur...), cette option permettra aux sociétés spécialisées (Percona, SkySQL, etc) d'intervenir plus facilement. Et de manière plus générale cette option facilite la maintenance.

daevel : infogérance et conseil || moi

francois10 | Francois
Membre

Inscrit le : 14/05/2006

# Le 28/07/2013 à 23:45

Pour en avoir fait l'expérience, Bool a tout à fait raison sur l'innodb_file_per_table, qui, suite à une erreur et à l'intervention de Percona nous a permis de récupérer des dizaines de Go de data, compressées et partitionnées.

Du MyISAM sous très forte charge, je sais pas trop ce que ça donne, mais ça dois pas être le délire...

(Message édité le 28-07-2013 à 23h52 par francois10)

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 28/07/2013 à 23:51

Ha bah Myisam sous forte charge, c'est dégueulasse, c'est clair.
Bref, je ferme ma gueule puisque mon avis n’intéresse pas...

FirstHeberg.com

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 29/07/2013 à 00:46

Je suis full MyIsam personnellement
Ça fait ce que je lui demande et ça me va.

Chambres d'hote tavel
Séjours en provence
Forum mariage

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 29/07/2013 à 10:01

De mon experience, pour forumconstruire.com, myisam ne suivait plus et le passage a innodb a tout reglé.
http://www.webworkerclub.com/forum/topic,112994,0....

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.