Hello,
Je suis à la recherche de benchmark, ou d'une étude sur les consommations ressources et temps de réponses des différents SGBD comme MySQL, Oracle, PostGreSql.
Savoir suivant la charge de la BDD (petite, moyenne, grosse) quels sont les temps d'accès, d'un insert,d'un select etc…
J'ai fouillé un peu sur internet, mais rien de bien m'est apparu si ce n'est les best-practices pour optimiser sa BDD.
Si vous avez vous-mêmes réalisé des tests, n'hésitez pas à me partager votre méthodologie et vos résultats.
Cordialement,
Bobmoutarde
# contexte ?
Posté par gaaaaaAab . Évalué à 3.
Chaque SGBD a ses forces et ses faiblesses. Je ne suis pas sûr qu'on puisse dégager un système qui poutre tous les autres pour tous les critères. Si je devais produire une étude comme ça, ça serait forcément dans le contexte d'un logiciel spécifique. Le contexte du logiciel devrait permettre d'identifier les critères importants pour ce cas d'usage. Ensuite, on peut analyser les SGBD existant en pondérant les différents critères pour le contexte (consommation de RAM, d'espace de stockage, temps de lecture/écritures sur majoritairement des gros/petits blocs, accès massivement parallèles ou plutôt séquentiels, scalabilité, outillages pour l'exploitation, coût des licences (genre pour Oracle), coûts de formation …).
[^] # Re: contexte ?
Posté par bobmoutarde . Évalué à 1.
Merci de ta réponse,
C'est ce que je recherche, j'entends ou plutôt je lis partout machin a ces avantages là, et ces inconvénient contrairement à untel.
Cependant aucune chiffre n'est fourni pour étayer ces conclusions comme l'exemple que MySQL est meilleur sur de petite base de données sur la lecture/écriture.
Je souhaiterai juste pour le même "projet" (exemple 50 tables, 100 000 rows) avoir le temps d'accès lecture/écriture de MySQL / Oracle / PostGre etc… ainsi que la conso RAM/CPU par exemple.
Je n'ai vraiment rien trouvé sur ce genre de benchmark..
[^] # Re: contexte ?
Posté par gaaaaaAab . Évalué à 3.
La structure et la volumétrie d'une DB de test ne suffirait pas à interpréter les résultats des benchmarks. Ce sont des informations statiques, mais la façon dont la DB est utilisée dynamiquement compte énormément pour les performances. Par exemple, une DB utilisée pour de l'authentification ne présentera pas du tout le même profil de performance qu'une DB utilisée pour de l'achivage.
En matière de performances, il faut éviter les suppositions et mesurer. Autrement dit, si tu trouvais un benchmark du genre, il te renseignerait sur le cas particulier testé, sans vraiment te donner autre chose qu'une vague intuition sur ce qui se passerait dans ton cas.
Si tu travailles sur un nouveau projet, concentre toi sur ce qui compte vraiment : la modélisation de la structure de la DB (en visant la plus haute forme normale possible). Dans un premier temps, utiliser un connecteur type jdbc pour se connecter à un SGBD quelconque permet de travailler en SQL standard, ce qui permet ne pas trop investir dans un SGBD particulier et donc de ne pas avoir besoin de choisir un SGBD tout de suite. Une fois que le projet a un peu vécu, il est possible d'identifier les éventuels besoins en performances, et voir si c'est intéressant d'investir sur un SGBD et de passer à des APIs natives, voire commencer à utiliser des fonctionnalités spécifiques à un SGBD.
Bref,
[^] # Re: contexte ?
Posté par Christophe B. (site web personnel) . Évalué à 2. Dernière modification le 17 décembre 2014 à 11:03.
Juste un truc et ce quelque soit la base de données :
50 tables / 100 000 lignes sur chaque (environ 5 millions de lignes)
taille moyenne de la ligne ? on prendra 1024 octets … donc avec 5 Go de RAM pour la base de données tout tient en mémoire. Prend un serveur avec 16 Go et cela doit rouler.
C'est un bon onduleur qu'il te faut :)
Après c'est le nombre d'utilisateurs et la gestion de la concurrence d'accès.
Si 1 utilisateur bloque l'accès à une donnée, alors tout les autres attendent.
et pourtant tu as la plus belle base et machine du monde.
Tout cela pour vous dire que en générale les problèmes de performances ont pour origine
5% : proviennent de l'OS
10 % : proviennent de la base de données (paramétrage allocation mémoire etc …)
le reste : Conception de la base et développement soit 85%
ce n'est pas péjoratif ce que je vais dire, mais sur de petit volume comme celui la, la performance ne devrait pas se poser en terme de base de données.
Honnêtement avec des disques SSD et 2 bon CPU, 16 Go ou plus de RAM sur ce volume je ne vois pas le problème même avec plusieurs centaines d'utilisateurs.
J'ai récemment testé des disques SSD capables de copier 30 Go / minutes, avec une base oracle de 250 millions de lignes (la table fait plusieurs Go) le CPU était au max AVANT les disques.
Par contre, si il s'agit de sortir par jour plusieurs milliers de documents (Etiquettes, Bon de livraisons etc …) il faut réfléchir à paralléliser avec un serveur de base de données et plusieurs serveurs de traitements etc …
L'architecture doit prendre en compte tout les paramètres : de l'utilisateur aux disques dur en passant par les devs, ceux qui signent les chèques, le réseau etc …
Et puis avant de faire une application de compét' penser aussi à la pérennité, la sauvegarde, la facilité de maintenance …
# interdit pour oracle
Posté par wismerhill . Évalué à 3.
La licence d'oracle interdit de publier des benchmark qui n'auraient pas été validés par eux, donc tu peux le faire toi-même, pour ton usage personnel, mais tu n'en trouvera probablement pas disponibles publiquement.
C'est la "clause Dewitt"
http://en.wikipedia.org/wiki/David_DeWitt#The_.22DeWitt_Clause.22
# premier bilan
Posté par bobmoutarde . Évalué à 1.
Très bien, merci pour vos premiers retours.
Donc on ne trouve pas ou très peu de benchmark de BDD sur le net car il est quasiment impossible de pouvoir les comparer autant pour leurs utilités que leurs spécificités.
Le meilleur moyen est, avec du temps, de tester son "projet" sur plusieurs SGBD et de se faire soi même sa propre idée ?
C'est assez surprenant dans le sens où en informatique, on aime les chiffres et en général il faut savoir justifier pleinement le choix d'une techno.
Mais quand on réfléchit, on ne choisit pas une BDD parce qu'elle est ultra-rapide mais parce que les fonctionnalités qu'elle fournit sont un plus que l'on ne peut pas négliger (comme les Fk) pour quelques ms de temps de réponse
[^] # Re: premier bilan
Posté par pifou . Évalué à 4.
Il faut aussi voir que la plupart des bases de données sont paramétrables de plein de façon différentes (taille des caches, outlines, moteur de requêtes, options diverses, flush, réplication …) afin de coller au mieux à tes contraintes (vitesse d'accès/vitesse d'écriture). De mon expérience que ce soit du MySQL/Oracle/PostgreSQL/Sybase (sur des bases ayant des tables dépassant les dizaines de millions de lignes) il a toujours été possible d'avoir des performances correctes (des fois il a quand même fallut revoir les requêtes dans les applis ou revoir complètement l'environnement technique).
[^] # Re: premier bilan
Posté par ze_lionix (site web personnel) . Évalué à 3.
J'abonde dans ton sens : le tuning de la base de donnée impacte fortement les résultats !
Il suffit de regarder les changements en jouant sur le keybuffer de mysql : tapper le cache en mémoire évite les I/O, et les accès disques ce n'est pas vraiment très rapide comparé à la RAM…
Même le choix du moteur sur mysql ( myisam vs inodb ) n'est pas anodin !
Le premier, "mono-thread", peux sembler moins intéressant de prime abord, mais pour certaines applications sa rapidité de chargement ( load into table ) peux être intéressante et justifier son choix ! Il n'y a pas de réponse toute faite, tout dépend du contexte applicatif.
Par ailleurs par expérience j'ai constaté que 90% des problèmes de performance sur les SGBD sont due au code : boucle de requêtes, jointure à droite ou gauche à la va-comme-je-te pousse, utilisation d'une librairie d'abstraction qui génère des requêtes pas du tout optimisées… etc….
Fuse : j'en Use et Abuse !
[^] # Re: premier bilan
Posté par NeoX . Évalué à 2.
100% d'accord avec toi,
et c'est pour cela qu'un bench n'est pas interessant en dehors de l'appli que l'utilisateur veut installer,
en effet seule son appli et la maniere dont elle est codée permettra de tester le moteur de la base de données.
[^] # Re: premier bilan
Posté par bobmoutarde . Évalué à 1.
Effectivement, de mon premier retour direct sur du SGBD. Le tuning des requêtes est extrêmement important.
Merci pour vos retours et vos partages. Je m'en vais donc tuner mes requêtes pour optimiser au maximum la BDD afin qu'elle "dépote"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: premier bilan
Posté par j_m . Évalué à 1.
Et aussi pour ne pas perdre ton temps sur n'importe quoi, il existe des outils qui affichent les requêtes les plus lourdes, sur lesquels il faut travailler. En oracle par exemple c'est Oracle Enterprise Manager.
Quand tu sais quelle requête pause problème tu peux aussi utiliser les outils d'analyse du plan de d'exécution: explain plan (oracle ou postgres)
Ca te dis les index utilisés par une requête, les jointures et l'importance estimée de chacune d'elles, et plein d'autres choses.
Et ça n'a pas beaucoup été dis, mais les index sont super important! Il faut les mettre sur les champs qui apparaissent dans ton where. Mais ils ralentissent les insert et les updates donc il ne faut pas en abuser non plus. Et plus tu mets de champs dans un index plus il grossi vite, et quand il ne rentre plus en cache il devient plus lent.
Ca c'est pour les BTree, c'est bon en général. Les autres c'est pour des besoins spécifiques, comme les bitmaps index pour les grosses tables.
[^] # Re: premier bilan
Posté par j_m . Évalué à 1.
Oups, grillé
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.