optimiser : désactiver les transactions et contraintes
2 réponses
Pif
Bonjour, j'ai des petites questions qui sont certainement tardives est
peut etre nulles ou évidentes :
J'ai utilisé MySQL parce que je n'utilise pas les transactions et pour
le coup il est très rapide... et surtout pour des contraintes externes
liées à ceux avec qui je travail... Je sais que le gain est important,
et que MySQL sans les transactions est bien plus rapide que PGSQL avec
les transactions activées... mais ce n'est en réalité qu'une partie de
la question, et j'en ai plusieurs autres :
1) Est il possible de désactiver les transactions dans Oracle ou PGSQL ?
Pour cela, utilisent ils d'autre structures de données ou formats de
fichiers et est-ce temporaire uniquement ? Obtient-on un gain notable de
performances ?
2) Les lock table et les désactivations de contraintes d'intégrité
permettent elles un gain notable de performances ?
3) comment se situe MySQL par rapport à Oracle et PGSql boostés
monoposte/monotache ?
Alors si vous avez des liens de benchmarks qui détaillent des résultats
concrets... je suis preneur !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pif
mordicus a écrit :
Je ne vois pas trop le rapport, autant je suis d'accord sur le fait que d ans bcp d'applications ne pas utiliser les transactions c'est dangereux autant je peux concevoir qu'une application peux ne pas avoir besoin de transactions. Quand au tuple d'un octet...
oui, idem, les propriétés des transactions sont fondamentales... dès lors qu'il existe une notion d'intégrité de la base... Moi j'utilise des données massive dans d'autres contexte... Imaginons la fouille des tickets de caisse des supermarchés d'un grand groupe de france...
Si le but est de trouver des motifs entre le chocolat noir et le café, c'est pas le crash d'un ticket de caisse qui va faire disparaitre le motif statistique... Si c'est une gestion de la comptabilité, la ca devient important pour avoir une balance juste...
Ben voilà, moi je suis dans le premier cas, et mon voisin pense que les SGBD ne s'adressent exclusivement qu'au second cas...
Avec ou sans transactions cela donne la même chose... on n'aurat jamais une moitié de données sauf biensur si la machine plante en pleins mil ieu de l'insert et que le fichier de la base est corrompue. Mais dans ce cas les serveurs de base de données refusent de démarrer et d'apres ce que j' ai compris du problème de pif, ce n'est pas un problème puisqu'il peut regenerer ces données.
tout a fait, je fais des sauvegarde régulières sur un 2° disque dur... si au pire je dois regénérer 3 jours de calcul, c'est pas dramatique... par contre, si je peux faire en sorte qu'un process prennent 5h au lieu de 5 jours, c'est bien prioritaire...
J'ai l'impression que c'est vous qui ne comprenez pas que l'on a pas forcement besoin de transactions lorsque les données ne sont pas critiques... Mais on peut vouloir quand même utiliser un SGBDR pour la simplicité d'utilisation.
merci, je me sens moins seul :)
> Ca dépend.
Ca c'est bien vrai...
oui, alors pour revenir a la question de base : si vous avez des benchmarks serieux, quels que soient les variables (logs, transaction, machines, etc.), vous m'envoyez, je ferais le tri ! :) mon meilleur ami (ou presque) google ne m'a pas donné grand chose de terrible...
Pour en revenir au problème de pif, non on ne peut pas desactiver les transaction dans PostgreSQL, ce que je fais generalement quand j'ai besoin d'enregistrer de grandes quantité de données le plus vite possible c' est que j'ouvre une transaction, je fais genre 10000 insert et je commit, puis je recommence. Évidement, si quelque chose plante après 24000 insert c'est un gros delete ou un truncate table et je recommence. Ce qui fait une transaction toutes les 10000 insert, pour 100000 insert c ela fait 10 transactions... le temps pris par la gestion de la transaction devient négligeable.
le problème est plutot que les transactions, contraintes d'intégrité (qui peuvent etre désactivées) reposent sur un système de fichier généralement nettement qui ne permet pas d'obtenir les meme performances ? c'est ca que je veux savoir... les benchmarks qui donnent mysql dix fois plus rapide masquent ils le fait qu'on n'a pas évité certaines fonctionnalités couteuse de PG ? qu'en est il chez oracle...
Autre chose à faire sous Pg pour aller le plus vite possible pendant les phases de chargement, c'est de desactiver le fsync sur les tables et les fichiers de logs (voir la doc). Cela boost pas mal les perfs.
oui, mais les benchs montrent que avec ou sans fsync, mysql reste plus rapide...
Question perfs comparé à MySql, après cela dépend de beaucoup de choses... Generalement l'optimizeur de Pg est plus performant que celui de MySQL, Pg permet aussi de préparer les requêtes a l'avance. Par exemple toute une série de select peuvent être préparer a l'ava nce et être exécutés en temps voulue ce qui évite de devoir "recompiler" a chaque fois la requête avant de l'éxecuter. Le gain n'est vraiment pas négligeable...
j'interface beaucoup avec java, du coup les procédures stockées et les PreparedStatements font l'équivalent..
Pg permet aussi de repartir les données et les index sur plusieurs disq ues, ce qui fais que la lecture (ou même l'écriture) sont souvent bcp plus rapides.
Etc.. etc.. les performances dépendes de bcp de choses et ceux qui dise nt qu'un MySQL est toujours plus rapide qu'un PostgreSQL ou un Oracle (qui l ui est capable de parallélisé une requête et de repartir sont exécut ion sur plusieur processeurs) n'ont souvent aucune idée de ce que les SGBD save nt faire aujourd'hui. Mais cela donne une idée de leur incompétence (je ne parle pas de toi pif)
ben, ce qu'il y a c'est qu'oracle est une immense usine, qui masque beaucoup de choses... mais par exemple; moi je peux pas paralléliser mes taches, et comme je fais beaucoup de petite requetes du type lire/ecrire/lire/ecrire, etc... le système ne peux pas trop jouer la dessus.... y'a un framework sympa pour faire du benchmark mes les résultats ne sont jamais clairs et publiques...
j'ai le meme problème en java sur la gestion des perfs en structures de données : l'utilisation des templates, de l'autoboxing, des structures de données liées à des librairires de calcul scientifique... rien n'est réellement précis pour dire ce qui est efficace...
Sinon, SQLite est bcp plus rapide que MySQL... :)
ah ? tu peux m'en dire plus ? que vallent les sgbdr qui peuvent etre embarqués en java genre ca pese 2 mo ?
une remarque sur les perfs : avec mysql, quand le cache est bon, ca va vite, mais dès fois on s'appercoit que le cache est dépassé, il faut soit meme découper la requete pour l'optimiser... pour oracle, je n'ose pas poser la question , mais PG est il puissant niveau cache ? bien géré ?
merci
mordicus a écrit :
Je ne vois pas trop le rapport, autant je suis d'accord sur le fait que d ans
bcp d'applications ne pas utiliser les transactions c'est dangereux autant
je peux concevoir qu'une application peux ne pas avoir besoin de
transactions. Quand au tuple d'un octet...
oui, idem, les propriétés des transactions sont fondamentales... dès
lors qu'il existe une notion d'intégrité de la base...
Moi j'utilise des données massive dans d'autres contexte...
Imaginons la fouille des tickets de caisse des supermarchés d'un grand
groupe de france...
Si le but est de trouver des motifs entre le chocolat noir et le café,
c'est pas le crash d'un ticket de caisse qui va faire disparaitre le
motif statistique... Si c'est une gestion de la comptabilité, la ca
devient important pour avoir une balance juste...
Ben voilà, moi je suis dans le premier cas, et mon voisin pense que
les SGBD ne s'adressent exclusivement qu'au second cas...
Avec ou sans transactions cela donne la même chose... on n'aurat jamais
une moitié de données sauf biensur si la machine plante en pleins mil ieu de
l'insert et que le fichier de la base est corrompue. Mais dans ce cas les
serveurs de base de données refusent de démarrer et d'apres ce que j' ai
compris du problème de pif, ce n'est pas un problème puisqu'il peut
regenerer ces données.
tout a fait, je fais des sauvegarde régulières sur un 2° disque
dur... si au pire je dois regénérer 3 jours de calcul, c'est pas
dramatique... par contre, si je peux faire en sorte qu'un process
prennent 5h au lieu de 5 jours, c'est bien prioritaire...
J'ai l'impression que c'est vous qui ne comprenez pas que l'on a pas
forcement besoin de transactions lorsque les données ne sont pas
critiques... Mais on peut vouloir quand même utiliser un SGBDR pour la
simplicité d'utilisation.
merci, je me sens moins seul :)
> Ca dépend.
Ca c'est bien vrai...
oui, alors pour revenir a la question de base : si vous avez des
benchmarks serieux, quels que soient les variables (logs, transaction,
machines, etc.), vous m'envoyez, je ferais le tri ! :)
mon meilleur ami (ou presque) google ne m'a pas donné grand chose de
terrible...
Pour en revenir au problème de pif, non on ne peut pas desactiver les
transaction dans PostgreSQL, ce que je fais generalement quand j'ai besoin
d'enregistrer de grandes quantité de données le plus vite possible c' est
que j'ouvre une transaction, je fais genre 10000 insert et je commit, puis
je recommence. Évidement, si quelque chose plante après 24000 insert c'est
un gros delete ou un truncate table et je recommence.
Ce qui fait une transaction toutes les 10000 insert, pour 100000 insert c ela
fait 10 transactions... le temps pris par la gestion de la transaction
devient négligeable.
le problème est plutot que les transactions, contraintes d'intégrité
(qui peuvent etre désactivées) reposent sur un système de fichier
généralement nettement qui ne permet pas d'obtenir les meme
performances ? c'est ca que je veux savoir... les benchmarks qui
donnent mysql dix fois plus rapide masquent ils le fait qu'on n'a pas
évité certaines fonctionnalités couteuse de PG ? qu'en est il chez
oracle...
Autre chose à faire sous Pg pour aller le plus vite possible pendant les
phases de chargement, c'est de desactiver le fsync sur les tables et les
fichiers de logs (voir la doc). Cela boost pas mal les perfs.
oui, mais les benchs montrent que avec ou sans fsync, mysql reste plus
rapide...
Question perfs comparé à MySql, après cela dépend de beaucoup de choses...
Generalement l'optimizeur de Pg est plus performant que celui de MySQL, Pg
permet aussi de préparer les requêtes a l'avance.
Par exemple toute une série de select peuvent être préparer a l'ava nce et
être exécutés en temps voulue ce qui évite de devoir "recompiler" a chaque
fois la requête avant de l'éxecuter. Le gain n'est vraiment pas
négligeable...
j'interface beaucoup avec java, du coup les procédures stockées et
les PreparedStatements font l'équivalent..
Pg permet aussi de repartir les données et les index sur plusieurs disq ues,
ce qui fais que la lecture (ou même l'écriture) sont souvent bcp plus
rapides.
Etc.. etc.. les performances dépendes de bcp de choses et ceux qui dise nt
qu'un MySQL est toujours plus rapide qu'un PostgreSQL ou un Oracle (qui l ui
est capable de parallélisé une requête et de repartir sont exécut ion sur
plusieur processeurs) n'ont souvent aucune idée de ce que les SGBD save nt
faire aujourd'hui. Mais cela donne une idée de leur incompétence (je ne
parle pas de toi pif)
ben, ce qu'il y a c'est qu'oracle est une immense usine, qui masque
beaucoup de choses... mais par exemple; moi je peux pas paralléliser
mes taches, et comme je fais beaucoup de petite requetes du type
lire/ecrire/lire/ecrire, etc... le système ne peux pas trop jouer la
dessus.... y'a un framework sympa pour faire du benchmark mes les
résultats ne sont jamais clairs et publiques...
j'ai le meme problème en java sur la gestion des perfs en structures
de données : l'utilisation des templates, de l'autoboxing, des
structures de données liées à des librairires de calcul
scientifique... rien n'est réellement précis pour dire ce qui est
efficace...
Sinon, SQLite est bcp plus rapide que MySQL... :)
ah ? tu peux m'en dire plus ?
que vallent les sgbdr qui peuvent etre embarqués en java genre ca pese
2 mo ?
une remarque sur les perfs : avec mysql, quand le cache est bon, ca va
vite, mais dès fois on s'appercoit que le cache est dépassé, il faut
soit meme découper la requete pour l'optimiser... pour oracle, je
n'ose pas poser la question , mais PG est il puissant niveau cache ?
bien géré ?
Je ne vois pas trop le rapport, autant je suis d'accord sur le fait que d ans bcp d'applications ne pas utiliser les transactions c'est dangereux autant je peux concevoir qu'une application peux ne pas avoir besoin de transactions. Quand au tuple d'un octet...
oui, idem, les propriétés des transactions sont fondamentales... dès lors qu'il existe une notion d'intégrité de la base... Moi j'utilise des données massive dans d'autres contexte... Imaginons la fouille des tickets de caisse des supermarchés d'un grand groupe de france...
Si le but est de trouver des motifs entre le chocolat noir et le café, c'est pas le crash d'un ticket de caisse qui va faire disparaitre le motif statistique... Si c'est une gestion de la comptabilité, la ca devient important pour avoir une balance juste...
Ben voilà, moi je suis dans le premier cas, et mon voisin pense que les SGBD ne s'adressent exclusivement qu'au second cas...
Avec ou sans transactions cela donne la même chose... on n'aurat jamais une moitié de données sauf biensur si la machine plante en pleins mil ieu de l'insert et que le fichier de la base est corrompue. Mais dans ce cas les serveurs de base de données refusent de démarrer et d'apres ce que j' ai compris du problème de pif, ce n'est pas un problème puisqu'il peut regenerer ces données.
tout a fait, je fais des sauvegarde régulières sur un 2° disque dur... si au pire je dois regénérer 3 jours de calcul, c'est pas dramatique... par contre, si je peux faire en sorte qu'un process prennent 5h au lieu de 5 jours, c'est bien prioritaire...
J'ai l'impression que c'est vous qui ne comprenez pas que l'on a pas forcement besoin de transactions lorsque les données ne sont pas critiques... Mais on peut vouloir quand même utiliser un SGBDR pour la simplicité d'utilisation.
merci, je me sens moins seul :)
> Ca dépend.
Ca c'est bien vrai...
oui, alors pour revenir a la question de base : si vous avez des benchmarks serieux, quels que soient les variables (logs, transaction, machines, etc.), vous m'envoyez, je ferais le tri ! :) mon meilleur ami (ou presque) google ne m'a pas donné grand chose de terrible...
Pour en revenir au problème de pif, non on ne peut pas desactiver les transaction dans PostgreSQL, ce que je fais generalement quand j'ai besoin d'enregistrer de grandes quantité de données le plus vite possible c' est que j'ouvre une transaction, je fais genre 10000 insert et je commit, puis je recommence. Évidement, si quelque chose plante après 24000 insert c'est un gros delete ou un truncate table et je recommence. Ce qui fait une transaction toutes les 10000 insert, pour 100000 insert c ela fait 10 transactions... le temps pris par la gestion de la transaction devient négligeable.
le problème est plutot que les transactions, contraintes d'intégrité (qui peuvent etre désactivées) reposent sur un système de fichier généralement nettement qui ne permet pas d'obtenir les meme performances ? c'est ca que je veux savoir... les benchmarks qui donnent mysql dix fois plus rapide masquent ils le fait qu'on n'a pas évité certaines fonctionnalités couteuse de PG ? qu'en est il chez oracle...
Autre chose à faire sous Pg pour aller le plus vite possible pendant les phases de chargement, c'est de desactiver le fsync sur les tables et les fichiers de logs (voir la doc). Cela boost pas mal les perfs.
oui, mais les benchs montrent que avec ou sans fsync, mysql reste plus rapide...
Question perfs comparé à MySql, après cela dépend de beaucoup de choses... Generalement l'optimizeur de Pg est plus performant que celui de MySQL, Pg permet aussi de préparer les requêtes a l'avance. Par exemple toute une série de select peuvent être préparer a l'ava nce et être exécutés en temps voulue ce qui évite de devoir "recompiler" a chaque fois la requête avant de l'éxecuter. Le gain n'est vraiment pas négligeable...
j'interface beaucoup avec java, du coup les procédures stockées et les PreparedStatements font l'équivalent..
Pg permet aussi de repartir les données et les index sur plusieurs disq ues, ce qui fais que la lecture (ou même l'écriture) sont souvent bcp plus rapides.
Etc.. etc.. les performances dépendes de bcp de choses et ceux qui dise nt qu'un MySQL est toujours plus rapide qu'un PostgreSQL ou un Oracle (qui l ui est capable de parallélisé une requête et de repartir sont exécut ion sur plusieur processeurs) n'ont souvent aucune idée de ce que les SGBD save nt faire aujourd'hui. Mais cela donne une idée de leur incompétence (je ne parle pas de toi pif)
ben, ce qu'il y a c'est qu'oracle est une immense usine, qui masque beaucoup de choses... mais par exemple; moi je peux pas paralléliser mes taches, et comme je fais beaucoup de petite requetes du type lire/ecrire/lire/ecrire, etc... le système ne peux pas trop jouer la dessus.... y'a un framework sympa pour faire du benchmark mes les résultats ne sont jamais clairs et publiques...
j'ai le meme problème en java sur la gestion des perfs en structures de données : l'utilisation des templates, de l'autoboxing, des structures de données liées à des librairires de calcul scientifique... rien n'est réellement précis pour dire ce qui est efficace...
Sinon, SQLite est bcp plus rapide que MySQL... :)
ah ? tu peux m'en dire plus ? que vallent les sgbdr qui peuvent etre embarqués en java genre ca pese 2 mo ?
une remarque sur les perfs : avec mysql, quand le cache est bon, ca va vite, mais dès fois on s'appercoit que le cache est dépassé, il faut soit meme découper la requete pour l'optimiser... pour oracle, je n'ose pas poser la question , mais PG est il puissant niveau cache ? bien géré ?
merci
Pif
Patrick Mevzek a écrit :
Le Tue, 21 Nov 2006 17:47:06 +0100, mordicus a écrit : Un SGBDR, sans transactions, sans jointures (cf autre thread) et encore sans je ne sais quoi d'autre, au final ca se termine à l'équivalent de planter un clou avec un tournevis : bref problème d'adéquation entre besoins et outils utilisé
il arrive souvant que les gens qui bricolent beaucoup se retrouvent avec un outil qui leur manque, alors au lieu de créer de recréer l'outil, il font avec un autre qui s'en rapproche d'un point de vue fonctionnel.. par exemple, je n'ai pas de maillet, et il m'est arrivé d'utiliser un marteau à la place, ou un tournenis au lieu d'un petit burin ou biseaux... quand on ne cherche pas a faire du travail de précision, et qu'on a pas d'outil adéquat sous le main, ca marche bien... il faut apprendre à accepter qu'il y a d'autre utilisation que la votre d'un outil.
Il y a plein d'autres choses à faire, bien plus pertinentes : supprimer les index, desactiver les contraintes, etc...
déjà fait ... et désactiver les index n'est pas toujours réalisable ni même efficace... ce n'est valable que quand on crée une table... quand tu as une table de 150 000 000 de tuples, que tu en ajoute 5 000 000 et que tu lance le recalcul de l'index, ca coute très cher... et si entre les deux tu veux vérifier que la valeur n'est pas déjà présente ou savoir l'anciene valeur,ben sans l'index, autant dire que t'es mal barré ..
Patrick Mevzek a écrit :
Le Tue, 21 Nov 2006 17:47:06 +0100, mordicus a écrit :
Un SGBDR, sans transactions, sans jointures (cf autre thread) et encore
sans je ne sais quoi d'autre, au final ca se termine à l'équivalent de
planter un clou avec un tournevis : bref problème d'adéquation entre
besoins et outils utilisé
il arrive souvant que les gens qui bricolent beaucoup se retrouvent
avec un outil qui leur manque, alors au lieu de créer de recréer
l'outil, il font avec un autre qui s'en rapproche d'un point de vue
fonctionnel.. par exemple, je n'ai pas de maillet, et il m'est arrivé
d'utiliser un marteau à la place, ou un tournenis au lieu d'un petit
burin ou biseaux... quand on ne cherche pas a faire du travail de
précision, et qu'on a pas d'outil adéquat sous le main, ca marche
bien...
il faut apprendre à accepter qu'il y a d'autre utilisation que la
votre d'un outil.
Il y a plein d'autres choses à faire, bien plus pertinentes : supprimer
les index, desactiver les contraintes, etc...
déjà fait ... et désactiver les index n'est pas toujours
réalisable ni même efficace... ce n'est valable que quand on crée
une table... quand tu as une table de 150 000 000 de tuples, que tu en
ajoute 5 000 000 et que tu lance le recalcul de l'index, ca coute très
cher... et si entre les deux tu veux vérifier que la valeur n'est pas
déjà présente ou savoir l'anciene valeur,ben sans l'index, autant
dire que t'es mal barré ..
Le Tue, 21 Nov 2006 17:47:06 +0100, mordicus a écrit : Un SGBDR, sans transactions, sans jointures (cf autre thread) et encore sans je ne sais quoi d'autre, au final ca se termine à l'équivalent de planter un clou avec un tournevis : bref problème d'adéquation entre besoins et outils utilisé
il arrive souvant que les gens qui bricolent beaucoup se retrouvent avec un outil qui leur manque, alors au lieu de créer de recréer l'outil, il font avec un autre qui s'en rapproche d'un point de vue fonctionnel.. par exemple, je n'ai pas de maillet, et il m'est arrivé d'utiliser un marteau à la place, ou un tournenis au lieu d'un petit burin ou biseaux... quand on ne cherche pas a faire du travail de précision, et qu'on a pas d'outil adéquat sous le main, ca marche bien... il faut apprendre à accepter qu'il y a d'autre utilisation que la votre d'un outil.
Il y a plein d'autres choses à faire, bien plus pertinentes : supprimer les index, desactiver les contraintes, etc...
déjà fait ... et désactiver les index n'est pas toujours réalisable ni même efficace... ce n'est valable que quand on crée une table... quand tu as une table de 150 000 000 de tuples, que tu en ajoute 5 000 000 et que tu lance le recalcul de l'index, ca coute très cher... et si entre les deux tu veux vérifier que la valeur n'est pas déjà présente ou savoir l'anciene valeur,ben sans l'index, autant dire que t'es mal barré ..
