Discussion :

[meddebmourad]

Bonjour, j'ai besoin de votre aide,
SVP quel est le meilleur SGBD open source pour une application de fouille de données textuelles?
J'envisage créer une grosse base de données de plusieurs dizaines de Go (inférieur a 100 GO je pense).
D'apres les informations que j'ai collecté jusqu;a maintenant, les meilleurs possibilités sont H2 et Oracle Berkeley DB Java Edition, parce que:
- mon application est en Java, et je n'ai pas vraiment besoin de serveurs et des clients, sauf peut être dans le cas échéant 2 ou 3 connections simultanées a la base, il s'agit juste d'une interrogation simple de la base
- Oracle Berkeley DB Java Edition gère a priori les volumes géants
- H2 est très performant et rapide d'après ce que tout le monde dit
mais aussi:
- je ne sais rien par rapport au comportement de H2 avec les grosses volumétrie
- Oracle Berkeley DB Java Edition ne permet pas de connexion réseau a la base (accès par api seulement) ce qui peux être gênant

Je vous prie donc de me corriger les informations que j'ai si elles sont fausses, et si vous pensez qu'il y a de meilleures solutions je suis a votre écoute.
Je vous remercie beaucoup de votre aide, et j'espère lire vos éclaircissements.

[SQLpro]

Sans conteste PostGreSQL !

A +

[kedare]

+1 pour Postgresql

[Jester]

H2 étant gratuit, pourquoi ne pas le tester?

Je me demande en effet ce qu'il donne sur de grosses volumétries.

[meddebmourad]

H2 étant gratuit, pourquoi ne pas le tester?

Je me demande en effet ce qu'il donne sur de grosses volumétries.

Bonjour,
J'ai essayé H2 et de nombreux problèmes sont survenus:
- des 20 Go de données les requêtes deviennent insupportablement lentes même select (bien qu'ils disent que la limite théorique du volume supporté est de 256 Go)
- pour continuer a travailler il faut augmenter la mémoire pour la JVM
- même après cette augmentation il est impossible d'accéder a la base de données a partir de la console de H2 il affiche toujours
General error: java.lang.OutOfMemoryError: Java heap space [50000-79] HY000/50000
Maintenant je vais essayer le Postgres et j'espère bientôt vous donner les résultats.
A+

[Jester]

Déception pour H2. C'est pas encore demain qu'on aura une base de données java libre et qui tienne la volumétrie.

Bonne chance pour postgres.

[SQLpro]

Je me marre !!! En effet H2 à débuté en 2004. Sachant que pour écrire le noyau d'un SGBDR (moteur de stockage, moteur de requêtes et tout ce qui va avec...) il faut a peu près 200 années homme, je pense que d'ici 10 ans il sera peut être performant et le java probablement mort !

A +

[kedare]

Dans 10 ans, les base de données relationnel serons probablement morte et remplacées par les base de données objets ;d

[el muchacho]

Je me marre !!! En effet H2 à débuté en 2004. Sachant que pour écrire le noyau d'un SGBDR (moteur de stockage, moteur de requêtes et tout ce qui va avec...) il faut a peu près 200 années homme, je pense que d'ici 10 ans il sera peut être performant et le java probablement mort !

A +

J'ai testé un certains nombre de BD du marché sur une version que j'ai modifiée du programme poleposition (via JDBC et Hibernate). Donc des update, des select, des jointures, des delete, etc.
C'est loin d'être exhaustif, mais donne une bonne idée sur les opérations les plus courantes.

C'était sur une petite volumétrie (quelques centaines de Mo), et en monoposte.
il y avait MySQL 5.1 avec 300 Mo de RAM allouée, PostgreSQL 8.3 qui ne prend que 40 Mo de RAM, Oracle XE (10g) avec 630 Mo de RAM allouée, Derby, db4o, H2 et HSQLDB.

Derby est totalement inutilisable dans quelque domaine que ce soit.
H2 et HSQLDB sont de loin les plus rapides, que ce soit en RAM (alors là, c'est d'un facteur 100) ou non.
En RAM, HSQLDB est carrément impressionnant pour des requêtes minimales, mais ses perfs s'écroulent si on multiplie les jointures. En mode CACHED et non MEMORY (donc pas entièrement en RAM), HSQLDB est légèrement moins performant qu'H2, mais les 2 bases Java sont quand même loin devant les autres.
Ensuite db4o.
Ensuite, MySQL, Postgres et Oracle sont kif kif, avec un petit avantage pour MySQL sur les requêtes, un avantage pour Postgres sur les updates et un avantage pour Oracle sur les tables non indexées.

Avec tout le respect que je dois à un expert SQL, je pense qu'il n'y a pas de raison de se moquer, H2 et HSQLDB ont un vrai marché à eux, les composants SOA avec BD embarquée qui n'ont pas besoin de grosses volumétrie (typiquement une douzaine de tables de quelques dizaines de Mo maximum), mais de grande rapidité d'accès. Dans notre SSII, nous les utilisons dans plusieurs missions critiques avec succès, par exemple pour du monitoring. Leur facilité d'utilisation, de déploiement et leur flexibilité sont des avantages essentiels.
Il est bien évident que ces RDBS ne sont pas faites pour gérer de grosses volumétries ni des milliers de connexions simultanées. Mais dans les utilisations en tant que BD embarquée, elles sont vraiment pratiques.

[Jester]

J'ai aussi fait des tests dans une pseudo simulation de datamart (une table de fait avec 10 millions d'enregistrements [200Mo en MyIsam pour les données et 180Mo l'index] et 3 petites tables de dimensions). Le tout en JDBC.

J'ai commencé à tester plusieurs bases et les résultats sont très différents. Les différents buffer de mémoire sont tous mis à 20Mo (sauf oublis). Les bases java sont in process.

L'insertion consiste en 200 inserts contenant chacun 1000 lignes.

scanning : SELECT * from fact

Sum : SELECT sum(qty*unitPrice) from fact f, product p where f.productId = p.id

joinsum : SELECT c.country, c.city, sum(qty) FROM client c, fact f WHERE f.clientId = c.id GROUP BY country, city

join2G : SELECT d.yeard, c.country, c.city, sum(qty) FROM client c, fact f, date d WHERE f.clientId = c.id and f.dateId = d.id GROUP BY yeard, country, city

HSQLDB n'est pas dedans car il n'arrive pas à gérer les grosses requêtes (pour scanning il charge tout le resultset en mémoire, la jvm étant limitée à 100Mo)

H2 est lent pour toutes les opérations, pour scanning il recopie la table pour cacher le résultat ne gérant pas les curseurs sur le serveur.

Mysql 5.0 est rapide pour le scanning alors même que son driver ne supporte pas le fetchsize, via un hack il envoie une ligne à chaque fois tandis que les autres en envoient 1000 par 1000, étrange ... La différence entre les deux moteur est logique sur les tests sauf pour ceux avec les group by, je me demande pourquoi innodb va 2x plus vite. Mais dans les deux cas, la performance du group by est décevante. C'est peut-être optimisable.

Derby et postgres sont assez stables et très bon (préférence pour postgres).

Comme quoi selon les tests on ne retrouve pas les mêmes. il est bien sur évident que poleposition est mieux fait que mon programme.

[SQLpro]

Sur une volumétrie de bases de données inférieure à la RAM et avec une faible concurrence d'accès les tests ne veulent rien dire.

On commence des test avec des bases de données dont le volume est au moins 10 fois celui de la RAM.
On commence à voir les problèmes de concurrence réels à partir de quelques centaines de processus par processeur.

Là inutile de parler des pseudo SGBDR que sont HSQLDB et H2

Pour MySQL c'est la cata. il se vautre à quelques dizaines d'utilisateurs.

Pour PostGreSQL c'est beaucoup plus stable

A +

[Jester]

Je précise que la volumétrie (plus 200Mo) est supérieure à la RAM (20Mo environ comme indiqué) allouées aux bases de données. Peut-être que le cache des fichiers de l'OS joue, je n'en ai pas l'impression. Je ferais éventuellement des tests plus gros, c'est juste que le temps d'alimentation augmente et qu'il faut la place nécessaire.

Pour la concurrence, ça ne joue pas trop dans ma problématique, donc ce n'est pas du tout un critère important pour moi.

[SQLpro]

Pour la concurrence, ça ne joue pas trop dans ma problématique, donc ce n'est pas du tout un critère important pour moi.

C'est justement pour cela que les SGBD ont été créés : leur capacité à gérer une forte concurrence !

A +

[el muchacho]

Voici les données brutes d'un de mes tests. Bon c'est un peu indigeste mais ça donne une idée. J'ai fait aussi un test avec 500 000 enregistrements, mais c'est très long (> 12 heures), certaines bases ne se comportant pas bien sur certains tests.
Oracle est bcp plus pénible avec JDBC que les autres bases et a posé quelques petits soucis de mise au point là où les autres roulaient jeunesse.
Quand à SQL Server, j'ai jamais réussi à me logger.

Test réalisé sous WinXP Pro en monoposte.
Hibernate 2
PostgreSQL 8.3 100 Mo de RAM
OXE 10.2.0.1 640 Mo de RAM
HSQLDB 1.8.0.9 1 Go de RAM (pour la JVM)
H2 1.0.7.1 1 Go de RAM (pour la JVM)
db4o 6.4-38-10595 1 Go de RAM (pour la JVM)
MySQL 5.0.51a 300 Mo de RAM (absent ici, mais au comportement comparable à PostgreSQL)

Résultats à prendre avec les précautions habituelles.
Le bench poleposition est très limité: ces tests ne permettent pas d'extrapoler sur une très grosse base de plusieurs Go ou plus, ni même sur le comportement sous N requêtes simultanées (ici, toutes les requêtes sont sérialisées).

Structure d'arbre réalisée avec des clefs étrangères sur une même table
Circuit: Sepang
writes, reads and then deletes an object tree
Lap: write
t [time in ms] depth:10 depth:12 depth:14
db4o 287 351 832
Hibernate/oracle 796 2120 8420
Hibernate/postgresql 611 1932 7883
Hibernate/hsqldb 161 238 967
Hibernate/h2 168 220 932
JDBC/OracleXE 651 10830 52369
JDBC/PostgreSQL 248 1063 4080
JDBC/HSQLDB 21 86 325
JDBC/H2 25 91 417

Circuit: Sepang
Lap: read
t [time in ms] depth:10 depth:12 depth:14
db4o 52 42 175
Hibernate/oracle 399 1140 4610
Hibernate/postgresql 388 1461 5800
Hibernate/hsqldb 102 233 945
Hibernate/h2 135 262 1017
JDBC/OracleXE 316 113 133
JDBC/PostgreSQL 309 1169 4705
JDBC/HSQLDB 24 75 317
JDBC/H2 26 91 358

Circuit: Sepang
Lap: delete
t [time in ms] depth:10 depth:12 depth:14
db4o 205 335 798
Hibernate/oracle 791 3480 24141
Hibernate/postgresql 1084 6766 74819
Hibernate/hsqldb 116 354 1413
Hibernate/h2 155 427 1826
JDBC/OracleXE 366 418 235
JDBC/PostgreSQL 581 2401 9576
JDBC/HSQLDB 36 133 524
JDBC/H2 49 177 682

Table de données simples, enregistrements manipulés individuellement
Circuit: Bahrain
write, query, update and delete simple flat objects individually
Lap: write
t [time in ms]
selects:1000 objects:1000 updates:1000
selects:1000 objects:5000 updates:1000
selects:1000 objects:30000 updates:1000
selects:1000 objects:200000 updates:1000
db4o 184 1066 3439 28535
Hibernate/oracle 826 3321 21007 135120
Hibernate/postgre 473 2255 13629 104423
Hibernate/hsqldb 52 291 2576 16780
Hibernate/h2 50 275 1947 21524
JDBC/OracleXE 109 263 2601 9832
JDBC/PostgreSQL 119 534 3443 25622
JDBC/HSQLDB 7 41 285 2297
JDBC/H2 19 83 607 7663

Circuit: Bahrain
Lap: query_indexed_string
t [time in ms]
objects:1000 updates:1000 selects:1000
objects:5000 updates:1000 selects:1000
objects:30000 updates:1000 selects:1000
objects:200000 updates:1000 selects:1000
db4o 151 111 137 211
Hibernate/oracle 2378 3424 6234 5984
Hibernate/postgre 1027 1248 1328 1440
Hibernate/hsqldb 382 503 602 570
Hibernate/h2 395 498 707 855
JDBC/OracleXE 110 714 1458 1545
JDBC/PostgreSQL 358 329 339 348
JDBC/HSQLDB 17 20 21 24
JDBC/H2 22 25 41 120

Circuit: Bahrain
Lap: query_string
t [time in ms]
selects:1000 objects:1000 updates:1000
selects:1000 objects:5000 updates:1000
selects:1000 objects:30000 updates:1000
selects:1000 objects:200000 updates:1000
db4o 340 1817 12241 113012
Hibernate/oracle 2167 3604 8413 16028
Hibernate/postgre 1206 2386 7635 43167
Hibernate/hsqldb 567 1869 8841 55173
Hibernate/h2 737 3688 21379 1034404
JDBC/OracleXE 123 757 1878 4075
JDBC/PostgreSQL 494 1359 6530 39826
JDBC/HSQLDB 203 1250 8298 54084
JDBC/H2 549 4185 20595 995158

Lap: query_indexed_int
t [time in ms]
selects:1000 objects:1000 updates:1000
selects:1000 objects:5000 updates:1000
selects:1000 objects:30000 updates:1000
selects:1000 objects:200000 updates:1000
db4o 77 61 72 92
Hibernate/oracle 2219 3648 6147 5940
Hibernate/postgre 988 1202 1316 1420
Hibernate/hsqldb 383 487 534 536
Hibernate/h2 379 519 620 678
JDBC/OracleXE 114 808 1530 1553
JDBC/PostgreSQL 340 306 299 310
JDBC/HSQLDB 17 19 20 22
JDBC/H2 19 36 26 45

Lap: update
t [time in ms]
selects:1000 objects:1000 updates:1000
selects:1000 objects:5000 updates:1000
selects:1000 objects:30000 updates:1000
selects:1000 objects:200000 updates:1000
db4o 273 355 707 1598
Hibernate/oracle 648 624 640 629
Hibernate/postgre 632 634 647 865
Hibernate/hsqldb 77 81 90 162
Hibernate/h2 949 99 171 1175
JDBC/OracleXE 146 56 53 54 <-- plantage ?
JDBC/PostgreSQL 148 131 181 590
JDBC/HSQLDB 15 17 27 87
JDBC/H2 33 29 90 1153

Circuit: Bahrain

Lap: delete
t [time in ms] selects:1000
objects:1000 updates:1000 selects:1000
objects:5000 updates:1000 selects:1000
objects:30000 updates:1000 selects:1000
objects:200000 updates:1000 selects:1000
db4o 182 488 2182 34740
Hibernate/oracle 601 3287 20440 145489
Hibernate/postgre 551 2777 17295 115932
Hibernate/hsqldb 77 341 2160 14519
Hibernate/h2 86 476 3083 27183
JDBC/OracleXE 381 1576 5409 44916
JDBC/PostgreSQL 170 833 5148 35445
JDBC/HSQLDB 5 21 129 1016
JDBC/H2 22 78 716 7781

Manipulations de données en bulk mode
Circuit: Melbourne
writes, reads and deletes unstructured flat objects of one kind in bulk mode
Lap: write
t [time in ms]
objects:1000 updates:1000 selects:1000
objects:5000 updates:1000 selects:1000
objects:30000 updates:1000 selects:1000
objects:200000 updates:1000 selects:1000
db4o 222 1134 3613 27534
Hibernate/oracle 525 2577 15659 107169
Hibernate/postgre 450 2105 12591 88960
Hibernate/hsqldb 47 260 1658 14558
Hibernate/h2 58 230 1506 15048
JDBC/OracleXE 17 79 274 3002
JDBC/PostgreSQL 80 389 2374 15952
JDBC/HSQLDB 3 23 121 1023
JDBC/H2 12 36 303 4604

Circuit: Melbourne
Lap: read
t [time in ms]
objects:1000 updates:1000 selects:1000
objects:5000 updates:1000 selects:1000
objects:30000 updates:1000 selects:1000
objects:200000 updates:1000 selects:1000
db4o 7 39 261 2552
Hibernate/oracle 404 1959 11718 78539
Hibernate/postgre 360 1855 11123 74261
Hibernate/hsqldb 61 271 2317 11370
Hibernate/h2 58 304 1990 16571
JDBC/OracleXE 16 69 403 2672
JDBC/PostgreSQL 5 21 126 944
JDBC/HSQLDB 0 2 18 167
JDBC/H2 0 4 217 2649

Circuit: Melbourne
Lap: read_hot
t [time in ms]
selects:1000 objects:1000 updates:1000
selects:1000 objects:5000 updates:1000
selects:1000 objects:30000 updates:1000
selects:1000 objects:200000 updates:1000
db4o 1 8 107 2490
Hibernate/oracle 14 69 411 2762
Hibernate/postgre 3 42 80 580
Hibernate/hsqldb 1 10 58 416
Hibernate/h2 2 11 135 1826
JDBC/OracleXE 14 70 402 2662
JDBC/PostgreSQL 3 19 147 925
JDBC/HSQLDB 0 2 18 92
JDBC/H2 0 4 217 2175

Circuit: Melbourne
Lap: delete
t [time in ms]
selects:1000 objects:1000 updates:1000
selects:1000 objects:5000 updates:1000
selects:1000 objects:30000 updates:1000
selects:1000 objects:200000 updates:1000
db4o 182 1160 4076 53184
Hibernate/oracle 203 926 7713 40818
Hibernate/postgre 202 956 5515 43413
Hibernate/hsqldb 14 75 545 4093
Hibernate/h2 22 113 2869 11279
JDBC/OracleXE 38 99 978 18663
JDBC/PostgreSQL 4 15 84 2820
JDBC/HSQLDB 1 7 51 341
JDBC/H2 5 47 406 5408

Circuit: Imola
retrieves objects by native id
Lap: retrieve
t [time in ms]
selects:5000 objects:1000
selects:5000 objects:5000
selects:5000 objects:30000
selects:5000 objects:200000
db4o 24 62 47 43
Hibernate/oracle 395 1891 1892 1892
Hibernate/postgre 363 1823 1821 1876
Hibernate/hsqldb 81 272 274 282
Hibernate/h2 63 296 325 357
JDBC/OracleXE 201 779 765 770
JDBC/PostgreSQL 415 896 889 940
JDBC/HSQLDB 14 17 55 16
JDBC/H2 36 31 30 77

Tables accédées par jointures inner joins
Circuit: Barcelona
writes, reads, queries and deletes objects with a 5 level inheritance structure
Lap: write
t [time in ms]
selects:1000 objects:1000
objects:5000 selects:1000
objects:30000 selects:1000
objects:200000 selects:1000
db4o 231 440 1311 9115
Hibernate/oracle 13618 8223 51752 333126
Hibernate/postgre 1760 7989 49168 334405
Hibernate/hsqldb 137 687 4415 32966
Hibernate/h2 211 914 6758 58668
JDBC/OracleXE 1164 3392 12023 1035
JDBC/PostgreSQL 410 2055 12704 94086
JDBC/HSQLDB 21 121 930 7747
JDBC/H2 75 7745 3497 38510

Circuit: Barcelona
Lap: read
t [time in ms]
selects:1000 objects:1000
selects:1000 objects:5000
selects:1000 objects:30000
selects:1000 objects:200000
db4o 7 30 229 1938
Hibernate/oracle 727 2157 13099 87619
Hibernate/postgre 812 4070 25456 174391
Hibernate/hsqldb 99 526 3240 22099
Hibernate/h2 785 3804 25687 165350
JDBC/OracleXE 936 979 5593 666
JDBC/PostgreSQL 546 6397 65500 115619
JDBC/HSQLDB 9 52 345 2694
JDBC/H2 14 94 1769 11554

Circuit: Barcelona
Lap: query
t [time in ms]
selects:1000 objects:1000
selects:1000 objects:5000
selects:1000 objects:30000
selects:1000 objects:200000
db4o 40 57 71 87
Hibernate/oracle 47514 17947 1214 1291
Hibernate/postgre 5679 8607 4385 4825
Hibernate/hsqldb 3873 18645 120665 882874
Hibernate/h2 1959 1763 1836 1846
JDBC/OracleXE 386 184 185 194
JDBC/PostgreSQL 697 2267 276 288
JDBC/HSQLDB 3151 18192 122730 923131
JDBC/H2 13 19 49 53

Circuit: Barcelona
Lap: delete
t [time in ms]
selects:1000 objects:1000 selects:1000
objects:5000 selects:1000
objects:30000 selects:1000
objects:200000 selects:1000
db4o 187 457 1684 11790
Hibernate/oracle 2157 7812 47940 323750
Hibernate/postgre 2397 13485 79912 546569
Hibernate/hsqldb 201 1014 6261 44315
Hibernate/h2 899 4393 29464 206022
JDBC/OracleXE 3219 7042 33212 142392
JDBC/PostgreSQL 856 4304 25386 172301
JDBC/HSQLDB 21 103 647 4685
JDBC/H2 55 361 3560 33024

[scheu]

Un grand +1 pour Postgresql