Salut @ tous,

Je suis en train de faire un bench de comparaison de perfs sur diverses bases de données open source et commerciales, à partir du soft Java PolePosition, que je modifie et remets à jour pour l'occasion.

En lice:
PostgreSQL 8.3
OXE 10.2.0.1
HSQLDB 1.8.0.9
H2 1.0.7.1
db4o 6.4-38-10595
MySQL 5.0.51a

Les mesures sont réalisées pour le moment via JDBC et via une version d'Hibernate qu'il faut que je mette à jour car trop ancienne (une v2.1.7 alors qu'on en est à 3.4), avec le pool de connexions ehcache-1.2.3.
db4o, qui est une BDD objet est attaquée directement en Java sans JDBC.

Un bref test de charge montre que Derby ne tient pas la route au niveau perf pour le moment.
McKoi n'est pas retenue parce que plus maintenue depuis 2004, et elle est moins performante que les autres bases de donnée Java ci-dessus.

Environnement:
WinXP SP2,
Core2Duo, 2,13GHz, 2Go de RAM.
Firewall et antivirus désactivés (PC offline)

Nota:
Les serveurs Postgres, XE et MySQL sont lancés quand le test tourne. Ils occupent donc une certaine partie de la mémoire.
J'ai pas cherché pour le moment à optimiser les bases, elles sont toutes en config standard et attaquées par un seul user.
 
Les tests consistent un insertions, requêtes aléatoires et suppressions d'objets simples dans les bases (voir le site de PP pour plus de précisions), avec des structures diverses:
- enregistrements simples avec ou sans index,
- hiérarchie d'objets sur 5 niveaux,
- structure d'arbre réalisé dans une seule table avec 10, 12, 14 niveaux d'indirection.

Les tests portent sur des bases de 1000, 5000, 30 000, 200 000 et 500 000 éléments.
Il manque un test avec des jointures un peu sérieux et un autre avec triggers.

Les benchs étant ce qu'ils sont, il faut les prendre avec des pincettes, mais ils permettent de donner des indications sur les points forts et faibles des différents produits. Celui-ci est destiné à évoluer, au fur et à mesure de ma compréhension des problèmes, de leur optimisation, etc.
Evolutions possibles: ajouter les couches d'abstraction ORM JDO et Ibatis.
Bases à essayer: Grand Schtroumpf SQL S.....

Problème MySQL:

url=jdbc:mysql://localhost:3306/dbbench user=dbbench passwd=dbbench
java.sql.SQLException: Access denied for user 'dbbench'@'localhost' (using password: YES)

Remplacer avec le "MySQL Query Browser" la valeur '%' par 'localhost' dans le user dbbench créé et ça repart. Bizarre ce %. Le bench fonctionne maintenant avec MySQL. \o/

Problème Grand schtroumpf 2005:
 Échec de la connexion TCP/IP à l'hôte . java.net.ConnectException: Connection refused: connect
 
Solution:
 
http://www.commentcamarche.net/for [...] -sqlserver

Oui SQL server gère 3 modes de connexion (mémoire partagée, pipe, TCP/IP) mais le driver JDBC de MS n'utilise que le mode TCP/IP. Il faut donc s'assurer que SQL Server est bien configuré pour TCP/IP.

Bon, et là, j'ai encore un pb,
com.microsoft.sqlserver.jdbc.SQLServerException: Échec de l'ouverture de session de l'utilisateur 'dbbench'.

Quand à OXE, il me sort régulièrement un :
java.sql.SQLException: Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
sur certains tests (rapides) alors que sur d'autres, tout fonctionne normalement.... P-ê n'a-t'il pas le temps d'établir la connexion ?
edit: apparemment, c'est le cas, en rallongeant les tests, le listener "accroche"

Dans SQL server, as-tu choisi le mode d'authentification windows intégré (auquel cas, il faut ajouter integratedSecurity=true dans la chaîne de connexion et ajouter la DLL kivabien au path de ton exe java) ou bien le mode SQL Server ?
As tu créé le login correspondant dans SQL Server ?

J'ai mis les deux, je crois, mais j'ai pas créé de login windows dbbench. Par contre, j'ai une base et un user dbbench.

Pour l'instant, c'est pas du tout ce que je vois. Je vois des pertes de perf drastiques, d'un facteur parfois supérieur à 10, voire plus. (le test tourne avec Hibernate 2 avec ehcache, je compte le faire passer en Hibernate 3.2, et un autre pool de connexions, pour voir)

Par exemple, ici, 1000 selects retournant chacun un objet, les temps (en ms) sont quadruplés. Les bases de donnée Java embarquées (db4o, HSQLDB, H2) sortent grandes gagnantes sur la recherche de données indexées, que ce soit des entier ou des chaînes. Elles sont par contre moins performantes que les bases traditionnelles sur les données non indexées. H2 a un vrai point faible dans ce type de recherche alors qu'OXE reste performante sans index. HSQLDB est extrêmement rapide à peu près partout sauf sur les hiérarchies d'objets, où il montre une grosse faiblesse. Il devrait se montrer efficace sur les bases de données simples, du style forums, CMS, etc. Ainsi, si les données sont en RAM, 1000 select retournant chacun un objet simple ne prennent que 24 ms...

MySQL n'est pas dans ce tableau, mais disons que les perfs observées, pour une config standard, sont similaires à celles de PostgreSQL (config par défaut aussi).
A suivre...

et t'utilise pas ça plutôt :
 
The Open Source Database Benchmark (OSDB). A flexible database benchmarking utility for Unix platforms developed by a consortium of developers. http://osdb.sourceforge.net/
 
 
Le whitepaper Mysql indique ça mais bon qu'est-ce que ça vaut....

Je ne connaissais pas, mais ce bench est assez ancien. PolePosition est un peu plus récent, même s'il y a encore pas mal de boulot pour le compléter afin qu'il soit plus représentatif.

J'ai lancé un test avec Postgres, MySQL et OXE, sous Hibernate 2.1 et en JDBC pur, avec 1000, 5000, 30 000, 200 000 et 1 million d'enregistrements. J'ai été un peu ambitieux, je l'ai lancé ce matin à 8h40 et il n'est tjrs pas terminé...

Bon, je ne donne pas encore de résultats pour deux raisons:
1. je n'arrive pas à établir une connexion sous Grand Schtroumpf SQL S
2. OXE passe son temps à me chier dans les pattes là où les autres bases fonctionnent sans broncher. Avec 500 000 éléments ou plus, j'ai le droit à "ORA-30036: impossible d'étendre le segment par 8 dans le tablespace d'annulation 'UNDO'".
J'ai pourant dans le ini.ora:

###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_tablespace=UNDO

Le disque a qq Go de libres. Sur la doc, j'ai cru comprendre qu'en AUTO, il n'y avait pas à gérer l'espace soi-même. Or ça n'a pas l'air de fonctionner. Je suis d'ailleurs étonné que l'espace de 500Mo déjà alloué soit insuffisant pour 500 000
enregistrements avec 5 malheureuses colonnes.
Une vraie plaie, ce SGBD, pas étonnant qu'il faille un admin à plein temps à son chevet, il est franchement instable sans un monitoring quasi permanent.

Pour le problème 2, je tente un doublement de taille:
alter database datafile 'C:\ORACLEXE\ORADATA\XE\UNDO.DBF' resize 1000m;

http://www.dbmotive.com/oracle_err [...] 6&type=ORA

Tu penses aller voir les communautés des différentes DB pour vérifier si les scripts sembles corrects pour un utilisateur (quand t'attaques en SQL brut) et par la suite pour obtenir des infos sur une config correcte pour les dbs non autoconfigurées?

J'ai déjà commencé à bidouiller les fichiers  de config pour MySQL et Postgres, histoire d'éviter de gros bottlenecks. Je crois que j'ai un peu gagné. Pour OXE, c'est plus chiant. En lisant les pages sur l'optimisation d'OXE, j'ai l'impression qu'il n'y a finalement pas tellement de paramètres à bidouiller.
En fait, le genre de questions qu'on peut se poser, c'est si on s'autorise à utiliser certaines spécificités de certaines bases ou non.

Par ex, puis-je utiliser l'écriture différée ou devrais-je m'en tenir à une synchro après chaque commit (ce qui ralentit fortement les écritures) ?
Si on présente des résultats, il faut livrer les fichiers de configuration de la base avec. Pour OXE, je ne connais pas la config dans le détail, il est curieusement bcp (genre 50x) plus rapides que MySQL et Postgres en écriture/update alors qu'il est plutôt plus lent pour les requêtes. Est-ce qu'il fait réellement un commit ou est-ce qu'on peut perdre des données et si oui, combien ? Je ne sais pas.

Pour une hiérarchie d'objets, je pourrais utiliser la clause INHERITS de Postgres et d'OXE plutôt que de la simuler avec des références.
Est-ce que ce serait tricher par rapport aux bases qui n'implémentent pas cette clause ? Devrais-je développer un test supplémentaire pour tester les perfs de ces implémentations ?

Ce genre de tuning, c'est tentant, mais on peut facilement fausser un bench comme ça.

C'est bien pour ça que:
 
1. Il faut demander à des gens qui savent
2. Dans tous les cas, si tu as des implés "standard" et des implés "non standard", il faut le documenter (et dans l'idéal mettre les deux implés afin de montrer la différence)

C'est aussi à cause de ça que selon celui qui fait le bench "officiel", c'est tel ou tel SGBD qui arrive en tête, et toujours pour cette raison que Microsoft ou Oracle stipulent dans leur doc qu'on ne doit pas publier de bench comparatif de leurs produits sans leur autorisation : selon les tests, le paramétrage, et bien d'autres facteurs (dont certains parfois insoupçonnables) on obtient des résultats très différents.
 
Un bench ne peut servir qu'à des fins "informative" et aucune conclusion ne doit en être tirée quant aux performances globales de l'outils.
 
La seule conclusion qu'on puisse en tirer, c'est si le soft s'en tire bien pour une utilisation similaire au bench.
 
Par exemple, lorsque Microsoft à publié son bench MSSQL/Oracle/MySQL, et que MMSQL arrivait en tête, ils se sont basés sur une application bien précise (la boutique en ligne d'exemple "Pet Shop" de Microsoft). Etant du même éditeur, on se doute évidement que l'application exploite au maximum MSSQL, et que certains optimisations valables dans l'application peuvent s'avérer catastrophiques pour d'autres. Oracle avait publié un contre-bench se basant sur une application exemple de Sun, et ils reprenaient sans mal la première place... On sait que cette fois Sun et Oracle ont pour habitude de travailler ensemble
J'ai récemment lu un bench PostGre vs MySQL, fait par PostGre, et on s'appercevait que le bench portait principalement sur des features toujours au stade "alpha" dans le moteur de MySQL... Le résultat était sans surprise, mais pas forcément significatif (faut déjà avoir l'utilité des features en question, et voir que 6 à 12 mois plus tard, les features étaient en release dans MySQL, les performances seraient très différentes)

L'avantage principal que j'ai sur tous ces benchs, c'est que j'ai pas de pognon à gagner, moi. D'autre part, mon bench reflète une utilisation "standard", pas forcément optimisée aux petits oignons, mais c'est en réalité le cas d'une majorité de bases, d'après ce que je vois.

c'est justement là que le bench a sa plus grande limite : selon ton utilisation, tu t'orientes de facto vers un sgbd plutôt qu'un autre, et tu adaptes ton utilisation.
 
entre les méthodes de connection et les fonctionnalités, c'est pas du tout le même code que tu vas écrire : sans parler des procédures stockées et autres triggers, tu as vite fait d'utiliser un "not exists / not in / left join where null"... sauf que si chacune des 3 méthodes donne le même résultat, elles n'ont pas du tout les mêmes performances d'un sgbd à l'autre. donc on ne peut pas parler d'utilisation standard.
 
si en mysql tu dois faire des écritures/lectures à raison de 10 000 / secondes dans une table de petite taille, tu vas direct utiliser une table mémoire et pulvériser tous les autres sgbd du marché. si en revanche t'as besoin de faire des transactions imbriquées sur plusieurs serveurs à la fois avec différents sgbd (ou transactions déportées), mysql ne t'offre même pas de méthode pour le faire... à ce niveau, Oracle et SQL Server qui seront les plus lents dans le premier cas seront les seuls à te permettre d'arriver à tes fins (quoique postgre doit pouvoir le faire aussi je pense)
 
ceci dit, cela n'enlève en rien l'intérêt que peut avoir un bench, mais les résultats sont à prendre avec des pincettes

Il est toujours possible de passer le bench dans différents cas d'utilisation, par ex. une utilisation ACID où la sécurité des transactions est maximale, et un cas d'utilisation où l'on veut maximiser la rapidité de la base, en laissant les transactions se faire en mémoire, avec une écriture régulière sur disque en différé, mais où l'on risque en revanche de perdre des données. Cela fait deux benchs et non un seul. Et un bench avec une config standard, où seul la RAM allouée est augmentée par rapport à la config d'origine.

(Pour l'instant, les bases qui pulvérisent les autres en terme de perfs sont HSQLDB et H2.)

Ce qui est certains, c'est qu'avec Oracle, j'ai bcp plus de soucis pour faire fonctionner le bench correctement qu'avec les autres bases. En plus, elle occupe 630 Mo de RAM en permanence.

Pas étonnant si ce sont des memtables

Sur un "vrai" serveur de base de données, t'as un truc genre 32 Go de mémoire redondante, donc tu t'en bas un peu les *** que ton SGBD bouffe 2% de la mémoire au démarrage.
Par contre quand t'arrive à te bouffer un petit millier de transactions concurrentes sans faire un seul rowlock dans toute la base, je suis pas sûr que les concurrents d'Oracle arrivent à suivre
 
Il oublie d'ailleurs un peu ça ton bench : passe en multi-thread, et ouvre quelques 200 connexions concurrentes avec différents logins, afin d'avoir des indicateurs de performance un peu plus fiables... Parceque c'est pas du tout la même donne lorsque t'as un accès mono-utilisateur et de multiples accès multi-utilisateurs.
 
Genre avec un SGBD autre qu'Oracle ou Postgre, un petit update sur un champ d'une ligne, et c'est toute la ligne, la page ou même la table qui est lockée durant toute la transaction. C'est bien de faire un select en 1ms, mais si tu dois attendre que tous les utilisateurs reviennent de leur pause café pour que ta requête soit exécutée, tu va pas trop aimer la blague
 
Et c'est un point à ne pas sous-estimer : de nombreux logiciels posent un lock sur une ligne lorsque tu arrives sur une fiche produit en mode modification (pour que personne d'autre ne puisse la modifier en même temps). Et toi, tu peux très bien passer 30 minutes avec ton fournisseur avant de savoir quoi mettre dans un champ à l'écran. Si tous les utilisateurs qui veulent consulter le produit en question sont bloqué, c'est pas super
 
PS : Ceci dit, je ne vois pas quels problèmes tu as avec Oracle (??). Certes, c'est une bouse infâme en de nombreux points, mais une fois la base créée, ça roule tout seule normalement

Non Oracle, ça ne roule jamais tout seul. Sinon on ne paierait pas des DBA à prix d'or juste pour surveiller la base. Ca fait déjà deux fois que l'appli qu'on développe fonctionne parfaitement en qualif, en recette, et se plante en préprod. La première fois parce que le charset était différent, la 2e fois parce que les drops Oracle ne sont pas vraiment des drop mais sont simplement placés dans le recyclebin (qui bien sûr finit par se remplir si on ne le purge pas régulièrement). Alors ok, la DBA est assez nulle, mais tout de même, ce genre de blague m'a fait perdre quelques journées d'investigation.

Là, j'ai régulièreement des plantages divers et variés avec JDBC. Depuis le listener qui "n'accroche" pas si le test est trop rapide (!) à "resultset épuisé". Le même code fonctionne parfaitement avec les 6 autres bases testées (MySQL, Postgres, H2, HSQL, Derby, McKoi). Je ne sais pas si c'est le driver Oracle qui est pourri ou si c'est la base elle-même qui gonfle, mais la conclusion est qu'il ne faut pas faire du JDBC avec Oracle, il fait nettement plus suer que les autres bases.

Si 2 charset différents, y'a un DBA qui a mal fait son boulot : sans DBA, le charset aurait été le même sur les deux (foireux, peut-être, mais le même )
La poubelle d'Oracle DOIT se purger automatiquement. A nouveau, un DBA a désactivé la fonctionnalité.

Soit t'as un sérieux bug dans ton drivers JDBC, soit le client Oracle est particulièrement mal configuré. Autre chose : Oracle tourne-t-il sur la même machine que ton bench ? Si c'est le cas, évite, trouve un second PC.
 
Franchement, pour un bench, je n'ai aucune idée de comment tu peux rencontrer des problèmes. Quel es performances soient pourries, ça je veux bien, mais sorti de ça... Oracle est on ne peut plus stable...
 
Sauf si...
 
1/ Tu es sous Linux
2/ T'as voulu tout bidouiller au lieu de faire "next next next finish"
3/ T'utilises une vieille version
 
Pour nux, c'est pas une boutade... Notre admin réseau s'est prix la tête pendant 5 semaines pour installer un serveur Oracle sous Linux. Entre les packages d'install foireux ne contenant pas tout dans la version 64 bits, le module d'import qui corromp les dump, et le module d'import qui met 3 jours à importer une base de... 3 Go, moi je dis chapeau bas. Même version d'Oracle, même dump, ça s'installe en 2 heures sur un portable tout pourri avec XP Pro, et c'est du coup ce que mon équipe utilise pour développer depuis tout ce temps. Et même si le portable est en dhcp sur une borne wifi qui le déco toutes les 30 minutes, on n'a jamais eu besoin de le rebooter depuis tout ce temps... Et pourtant on y accède justement en JDBC depuis OC4J.
Donc je peux certifier que sous Windows tout du moins, Oracle tu suis le wizzard, tu crées ta base, et roule ma poule. Celui qui a des soucis, c'est soit qu'il les cherche, soit qu'il a vraiment pas de chance, soit... qu'il le fait exprès.
Au bout de 6 mois, je dis pas, mais pour une utilisation telle qu'un bench, où on a besoin que le serveur soit stable au plus pendant une heure, je maintiens, Oracle ne pose pas le moindre souci !

C'est Oracle XE dernière version téléchargée sur le site d'Oracle, install standard sous XP, sans modif, antivirus et firewall désactivés, driver officiel. Ben ça roule quand tu le stresses pas trop, mais si tu y vas franchement, il se met à merder. J'imagine qu'il y a une config particulière à réaliser, mais là, ça foire sur certains tests (à partir d'un certains niveau de stress, pas sur d'autres), et c'est systématique.  
Pour ce qui est du listener,
java.sql.SQLException: Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
ça m'étonnerait fort que ce soit le code JDBC qui soit en cause.
Tiens tiens,
http://www.developpez.net/forums/s [...] p?t=348161
 

http://www.jroller.com/bmoussaud/date/200603
 
Pour ce qui est d'utiliser 2(ou plus) machines, je suis d'accord, ce serait mieux.

la version complète d'oracle est gratuite à des fins de tests et développement.
je te conseille d'utiliser plutôt cette dernière.
 
pour jdbc, je sais pas, mais pour oledb, il ne faut pas utiliser les drivers d'oracle, mais ceux de microsoft, ceux d'oracle étant effectivement buggés jusqu'à la moële

Ouais, je pense aussi que XE n'est pas configuré pour des tests de charge. Ca me gavait un peu de télécharger des Go, sans parler de l'espace qu'il s'arroge sur le disque. J'hésite à tester la 11, qui s'autoconfigure bcp mieux que la 10g mais est moins répandue. L'inconvénient de mon bench, c'est que les tests se passent sur toutes les bases "en même temps", cad test 1 sur chacune des bases, puis test2 sur chacune des bases, etc. Ce qui nécessite d'avoir les différents serveurs en même temps en RAM, donc une RAM plus limitée pour chacun d'entre eux. Ainsi, sur 2Go, XE s'arroge déjà 630 Mo, un peu plus de 300Mo pour MySQL, et bcp moins pour Postgres (il semble gérer très bien la RAM). Quand aux bases Java, elles sont dans la JVM, et ça peut monter à plus de 1Go (vu que les MEMORY tables sont en RAM, bien que les changements de données soient écrits sur disque).

Alors hier, j'ai fait la petite modif ci-dessus, - j'ai mis le nombre de PROCESSES à 200 -, et ça roule (presque). J'en ai profité pour modifier la config de HSQLDB, de façon à ce que par défaut, les tables soient en CACHED et non en MEMORY. Autrement dit, les plus grosses tables ne sont plus entièrement en mémoire.  Du coup les perfs sont comparables, voire légèrement inférieures à H2, qui devient finalement plus intéressant. Elles restent plus rapides que les autres.