Reprise du message précédent :

comme tu veux... c'était juste pour info
 
Effectivement Arjuna, j'ai vu le même mais j'suis pas foutu de le retrouver
 
Il y a la question de reprise sur incident qui doit être prise en compte aussi... MySQL n'a pas l'artillerie de SQL Server ou Oracle

 
Un bench de serveur non configuré? Autant bencher du hardware en utilisant des pilotes génériques.
 

 
Taratata. Si on est sérieux, on prend un spécialiste pour chaque sgbd.

 
Houla... bah non... tu fais une appli, t'a toutes les chances que les requêtes sur les écrans soient exécuter un bon millier de fois dans la journée
Genre l'écran des commandes, t'es sûr que la requête mouline à longueur de journée... c'est tout l'intérêt du cache
 

 
Evidemment... c'est pas quand tu es arrivé à bon port ou que t'es sur la route que tu regardes par où tu passes
 
En fait, je pense que tous les SGBD marchent de la même manière : parse, execute et fetch
 
parsing : vérification syntaxique, traduction et constitution du plan
execute : lancement de la commanden, collecte des données sur les disques ou en mémoire (ou dans le UNDO pour Oracle)
fetch : restitution du résultat

du moment que les conditions sont les mêmes entre chaque test, les résultats sont valides. Et on s'en fout des conditions, normalement, si les produits sont "comparables" ils doivent l'être sur tout type de configuration (sans entrer dans les trucs débiles, genre autant MySQL tourne très bien sur un P100 avec 32 Mo de RAM, autant Oracle ne démarre même pas.

C'est vrai que les transaction log c'est chiant parceque ça grossi tout le temps et ça relenti tout, mais restaurer une base de données à la milli-seconde près après une grosse connerie, c'est pratique

 
Ben voyons... Bencher un sgbd, c'est tout un art et balancer ce genre de conneries, ce n'est pas digne d'un dba. En procédant à base de "youpitroulala, on se fout des conditions du bench", ce que vous benchez, c'est votre pseudo-environnement de bench, ni plus, ni moins, et certainement pas le sgbd.

tu te fourvoies largement. ce qui est révélent dans un bench, c'est que chacun soit fait dans les mêmes conditions, pas les petits trucs que t'as pu faire pour améliorer les résutlats.
 
bencher un outils sans optimisation, c'est aussi important que de le bencher avec. pour la simple et bonne raison que tu ne pourras jamais optimiser au maximum tous les cas possible, il est donc impératif que l'outils soit capable de s'en sortir tout seul dans des cas peu évidents.
 
ce qui m'intéresse quand j'achète une machine à laver, c'est pas qu'elle sera capable de faire une lessive en 5 minutes en utilisant 2 litres d'eau. ce que je regarde en premier, c'est si elle a des sécurités suffisantes pour ne pas crâmer mon linge ou inonder la maison si le fitre est bouché ou la résistance entartrée. c'est justement la capacité à sortir son épingle du jeu dans les cas difficile qui fait la différence entre un bon et un mauvais produit.
 
exemple des index : t'as 25 requêtes qui tapent dans la même table, chacune nécessite un index différent. t'as le choix entre créer 25 index et rendre tout mouvement dans la table complètement catastrophique, ou créer 5 index pour les requêtes les plus lourdes, et confier au moteur les 20 requêtes suivantes sans index. trop d'optimisation tue l'optimisation, tout DBA le sait. par conséquent, à vouloir trop optimiser, on se retrouve avec des benchs pas du tout représentatifs de la réalité.
 
quant tu testes une carte graphique avec 3DMark, c'est pareil. tu te fous de savoir si le jeu a été optimisé pour telle ou telle carte, il ne l'est d'ailleurs pas. par contre, tu fais tourner le même bench sur des configs identiques avec juste la carte graphique qui change.
 
et pour ta gouverne, un bench avec une install "de base" est très important : quand les "drivers mis à jour" plantent, t'es bien content que les drivers de base soient pas trop pourris. C'est la même chose avec mon exemple des 25 index sur une seule table : bah ça marche pas, c'est donc bien que le sgbd puisse s'en tirer sans indedx.

En tout cas, un truc qui est bien avec SQL Server, c'est les table hints.
Sous Oracle, ils existent aussi, mais je ne les trouve pas clairs du tout.
 
Sous SQL Server, c'est limpide
 

 
J'avais une requête quelque peut complexe, et l'optimiseur partait dans les choux, faisant un fullscan sur la table la plus grosse de la base (forcément, c'est pas terrible).
 
Avec cette jolie optimisation, le "with(index())", j'ai divisé par 3 le temps d'exécution, et logiquement, n'importe qui devrait être capable de le relire
 
J'aime bien la mise en garde dans la doc :

sous Oracle le hint index existe aussi
 

 
C'est pas plus compliqué
 
pour info : http://orafrance.free.fr/tuning_hints.htm

J'ai pas dit qu'il exitait pas, au contraire, mais il me semble qu'il ne reconnais pas les alias.
 
Du coup, si t'as deux fois la même table, je ne sais pas comment ça marche, il fait comment ?
 
Genre :
 

 
Sinon, y'a grossomodo les mêmes hints possible, avec :
 
Hints d'index
Hints de lock
Hints de jointure
Hints de vue

Je viens de tester et on peut utiliser des alias à la place des noms de tables
 
Exemple (réel sur une base de prod ) :
 

 
Qu'entendez-vous par les mêmes conditions?

C'est à dire que si tu décides d'installer ton SGBD comme un porc sur le même disque que le swap, laisser les fichiers de données sur un disque fragmenté et rien optimiser, ça ne doit pas changer les conclusions du bench, à condition qu'on fasse la même chose pour chaque produit.
Idem quant aux requêtes et aux volumes tester.
 
Genre faut pas s'amuser à mettre des index sur des champs de type "CHAR(x)" sur une base, et pas d'index sur des "nvarchar(x)" sur une autre pase, et lancer la même requête dedans. C'est notamment là que c'est très difficile de faire des tests "portables" d'un SGBD à l'autre, parcequ'on se trouve sans arrêt limité par ce genre de trucs, et on peut notamment rarement tester les fonctionalités avancées parcequ'elles ne sont pas les mêmes d'un produit à l'autre.

OK. Il me semble que j'avais été confronté à un problème avec les alias sur une ancienne version (ou un paramètre qui n'allait pas, je sais pas), mais en tout cas, j'avais pas pu m'en servir comme je voulais, j'avais du passer par des vues afin de mettre mes table-hints sur mes différents alias.

 
C'est bien ce que je voulais lire: à savoir que les conditions identiques, c'est un non-sens. Retour à la case départ: si on prétend faire une comparaison des sgbd en terme de vitesse, on optimise la config de chaque sgbd au mieux pour le bench et on regarde le résultat. Sinon, autant organiser un 100 mètres en prenant un champion Allemand qui vient de se gaver de choucroute, un champion Marocain qui a fumé ses trois pétards, un Américain gavé de coke, un Chinois en train de se réveiller, un Indien en plein jeûne, un Français qui a passé la nuit à copuler, ... : le résultat n'aura aucun sens.

 
je dirais même qu'il faut mettre l'alias

pas forcément, tu peux mettre le nom de la table si elle apparait une seule fois ...

oui bien sûr

Ben non, justement, c'est là que t'es à côté de la plaque.
 
Mon test, c'est comme si tu leur demande à tous de fumer avant, ou de bouffer une choucroute.
 
Ainsi, même s'ils ne font pas les meilleurs perfs, tu pourras au moins déduire ceux qui courrent le mieu le vendre plein ou le cerveau enbrumé.
 
Si tu les dopes tous, ben ton indiens sera laisé, parcequ'il n'a pas assez d'argent pour s'acheter la même quantité d'EPO.

En fait, en optimisant n'importe comment comme tu le préconises, on se retrouve avec des résultats dignes du Tour de France : c'est plus le sportif que tu benches, mais le laboratoire qui produit ses dopants.
 
Là, j'en ai rien à foutre de savoir que le DBA d'Oracle est plus compétent que celui de SQL Server.

 
 
+1 Je suis tout à fait d'accord avec toi

 
Rien à voir. On utilise un sgbd pour des applications à ce que je sache et on le tune pour ces applications. Pour les benches, c'est pareil et on sait que le résultat du bench ne signifie rien d'autre que vis-à-vis de ce que l'on voulait tester. Pour prendre un exemple qui vous parlera plus, Sybase est longtemps resté avec un lock par défaut en mode page. Allez donc faire un test select+update là-dessus et me soutenir que c'est significatif avec un sgbd en face qui va avoir par défaut un rowlevel locking. Tout ce que le résultat du bench va pouvoir dire, c'est que la config par défaut est pourrie pour cette configuration de bench et rien de plus. Encore une fois, ce que vous testez, ce sont vos environnements de bench, et non pas les sgbd.
 
Edit: et encore en d'autres termes, le résultat de la course va signifier qu'il vaut mieux prendre de la coke avant de courir que manger de la choucroute, pas grand-chose quant aux coureurs.

 
ok pour moi un SGBD qui ne gère pas ces features ne doit pas être traité de bouse infâme comme vous le faites.
J'en ai rien à taper, comme 98% des utilisateurs, de ces fonctionnalités.
 
Pour moi et pour eux, la majorité des utilisateurs de bases de données qui peuvent avoir des besoisn très poussés (sans pour autant vouloir intéragir avec d'autres sgbd ou compenser les faiblesses de leur système en faisant de la liaison multi-base (je trouve cette idée dangereuse)), MySQL est parfait.
 
Je ne suis pas convaincu par vos arguments, sauf celui qui dit que mysql ne tient pas la charge quand on a 10000 requêtes simultanées SANS cluster (avec ça donne quoi ? Vous avez des benchs de moins d'1 an qui auront , eux, une certaine crédibilité ?)

Parceque les transactions impriquées (et distribuées) c'est pas important ? Ben franchement, moi j'ai pas envie de bosser avec un outil qui ne les supporte pas...
 
Sinon, vais tâcher de te trouver un bench d'une source un peu plus sûr que "www.i-love-linux.com"

heu c'est pas n'importe qui qui dev MySQL, seul des gars embauché pour bosser dessus ont le droit de faire des modifs dessus.
Qui plus est y a un système de testsuite assez au point mis en place, qui permet justement d'éviter le problème qui tu as décrit.
Et dire que sur une appli commerciale ce genre de problème n'existe pas, fait moi rire
 

En tout cas, DocMaboul, à vouloir optimiser à fond ta base, tu dénigre totalement l'équipe de MySQL.
 
Issu de la doc de MySQL :
 

 
Ils repprochent à Oracle de ne pas être présent dans le bench parcequ'ils veulent optimiser eux-même... L'équipe de MySQL se lève contre cette idée en spécifiant que leur test n'est valable qu'en installation "de base".
 
Je ne publie pas le test en question, car :
- On n'a pas les versions des produits testés
- L'architecture choisie, NT 4.0, n'est clairement pas à l'avantage de SQL Server 2000 (et c'est certainement pas le seul) qui utilise les pipe internes de Windows, qui ne sont pas du tout bons pour SQL Server. Il est même spécifié dans la doc de ce dernier qu'il est non recommandé de l'installer sur NT4
- A part MySQL qui est testé "en natif", tous les autres sont testés via ODBC
- Les tests se résument à lire des données brutes (select *) et insérer des données en masse, deux domaines où MySQL excèle, et qui ne sont pas du tout représentatifs de l'utilisation d'un SGBD (autant lire et écrire dans un fichier, ce sera encore plus rapide)

Sinon, cet article parle de Oracle et MySQL (pas de chiffres, mais j'aime bien la petite phrase de Michel Allaire, DSI chez TF1).

C'est balo, le seul bench récent que je trouve ne parle pas de MySQL. Et niveau optimisation, ça l'est, puisque ce sont des installations de SAP qui sont benchés :
 
http://www.microsoft.com/sql/evalu [...] Sales.mspx
 
A noter d'ailleurs que ce petit bench utilisant SAP confirmerait bien les rumeurs sur le rapprochement de SAP vers Microsoft, afin de remplacer leur outils "navision" par un SAP "lite".

On voit d'ailleurs que DB2 sort son épingule du jeu, puisqu'il arrive deux fois avant Oracle surle détail du "bench".
 
http://www50.sap.com/benchmarkdata/sd3tier.asp
 
Seul hic, ce ne sont pas réellement des benchs, mais des cartification de montée en charge pour une configuration donnée, donc on peut imaginer qu'à chaque nouveau serveur sur le marché, chaque éditeur s'empresse de sur-enchérir.

 
Hum. J'ai failli le dire dans un message précédent: ça m'a fait doucement ricaner de les voir faire des benchmarks avec des installations de base sans aucun tuning derrière. J'ai longtemps travaillé avec Sybase et c'est un parfait non-sens car la config par défaut est parfaitement pourrie. Si ma mémoire est bonne, il arrivait d'ailleurs bon dernier. C'est du même niveau de ce bench qu'il me semble avoir vu passer sur ce topic où mysql ne s'en sort pas avec dix ou cent connexions concurrents en select/update contre postgres. Forcément, si on prend le type de table où il ne sait faire que du table-level locking, ce n'est pas bien difficile que de l'envoyer au tapis et de généraliser derrière avec des "mysql? mais c'est une belle daube mon bon monsieur..."
 
Mais bon, contrairement à certains, je ne suis qu'un pauvre développeur avec un cap d'informatique: faut pas m'en vouloir si je n'ai aucune méthodologie...

 
Où mysql excelle? Même sur sql server, je suis sûr qu'un coup de bulk-copy est dix fois plus rapide...

Arjuna tu me fais marrer, tu critiques les benchs (nanana i-love-linux et les seules endroits ou tu trouves tes benchs, c'est sur la MSDN ou sur microsoft.com !   )
 
bref, si personne édite de bench intéressant tant pis, mais je suis maintenant encore plus convaincu de la puissance de MySQL dans le domaine.
Et je vais maintenant complètement mépriser les gens qui n'ont rien de mieux à dire que "c'est de la bouse infâme".
 
 
 
ps : je précise que pour les besoins que j'ai, et qui sont communs à 99% des utilisateurs de bases de données, on se tape complet des benchs qui testent les performances en présence de 100000 utilisateurs par jour ou 10000 à la seconde. Dans ces cas effectivement ça vaut peut être le coup de débourser 10000€  

 
J'ai relu la discussion histoire de vérifier que c'était bien ici que j'avais vu passer ce bench et lire ça un peu plus attentivement histoire de vérifier si ma supposition était bonne. Du coup, à mes yeux ce passage incarne à merveille toute la malhonnêteté intellectuelle qu'on peut trouver dans le milieu des sgbd. L'auteur du bench, quant à lui, était un peu plus honnête (à peine):
 

(http://www.phpbuilder.com/columns/ [...] hp3?page=3)
 
Là, il nous dit clairement qu'il voulait faire un bench pour mettre mysql à genoux mais au moins, il le dit. Après, ce n'est pas bien difficile de faire ce genre de bench. Maintenant, il faut aussi dire à sa décharge qu'à l'époque, le moteur InnoDB n'était pas encore supporté (ce bench date manifestement de 5 ans, version 3.23.26 beta alors que InnoDB n'apparaît qu'en version 3.23.34). L'article de développez date d'avril 2004. Là, il n'y a plus d'excuse. C'est juste, au mieux, de la malhonnêteté intellectuelle de bas étage et au pire, une belle preuve d'incompétence de Frédéric Brouard (l'auteur sur développez, expert SQL, décoré honoris causa par krosoft et tutti quanti): on prend un bench antédiluvien qui ne teste qu'un des moteurs de mysql (MyIsam), on oublie BerkeleyDB et InnoDB, et on généralise abusivement sur "mysql" dans son ensemble. Dans tous les cas, c'est pitoyable et tellement symptômatique de ce qu'on trouve bien trop souvent dans le milieu des sgbd...
 
Au fait, j'ai aussi vérifié: on peut aussi faire des sauvegardes à chaud sur mysql via le moteur InnoDB et un outil externe (mais payant).

 
Nous parlons bien de SGBD professionnel où ces options sont bien plus utilisés que tu ne le penses. La majorité des utilisateurs... sur les sites web peut-être mais pas ailleurs

 
tu te fourres le doigt dans l'oeil, la majorité des utilisateurs sont les entreprises qui aiment bien voir ce que va donner leur SGBD à 30000€ la license et plusieurs M€ d'installation... tout le monde ne se choisis pas des SGBD gratos au support technique inexistant

 
c'est bien précisé :
 

 
Il remet bien en cause son analyse avec l'arrivée des nouvelles versions
 
Et ensuite, il ne fait que comparer 2 SGBD gratuit et là on ne peut être que d'accord, PostgreSQL est plus performant que MySQL

 
Son analyse? Un dba qui fait des "analyses" de ce genre, je l'enverrais volontiers analyser l'anpe En plus, InnoDB était supporté par MySQL en 2002 et pas en version beta. A mon avis, c'est et de la malhonnêteté et de l'incompétence. Pour finir, il a manifestement écrit son article en 2002 et celui-ci a été reposté en 2004 sans la moindre mise à jour. Et après, il y a des gus dans votre genre qui viennent les citer dans des discussions comme celle-ci...
 

 
Ca dépend comment on bench, comme toujours.

 
Il ne fait qu'interpréter les résultats d'un bench qu'il n'a pas fait lui-même et pondère ses propos par ce que j'ai cité... je ne vois pas ce qu'il y a de si incompétent dans cette analyse

tu parles de MySQL
Parce que si c'est le cas les revenus de MySQL se font justement principalement sur le support technique, donc bon
 

Euh...
1/ C'est quoi la différence entre un bulk/copy et des insertions de masse ?
2/ T'en fait souvent dans ton code ? J'aimerais pas le voir
 
Un SGBD, c'est pas fait pour coller des millions de lignes juste pour le plaisir et les relire brute de fondrie juste pour le fun.
Fait-mois une requête joingnant 20 tables dont la moitié en OUTER, avec des regroupements sur différents niveau - avec des count(distinct champ)) par exemple - et des critères conditionnels "si champ1 = x alors je prends champ2 sinon je prends champ3".
 
Après on en reparle.
Un application classique n'utilise que ce type de requêtes, et là, y'a pas photo, MySQL en chie grave là où ça passe comment dans du beurre avec SQL Server ou Oracle.

Ben méprise-moi alors, avec un peu de pot tu ne m'adresseras plus la parole, et même mieu, tu ne viendra plus.
 
Si seul Microsoft fait des benchs "dignes de ce nom", c'est peut-être parceque c'est les seuls à pouvoir s'en venter... Je dis ça moi, je dis rien hein, c'est comme tu le sens.