Bonjour.
J'ai récemment eu une discussion avec un informaticien bien plus expérimenté que moi, il m'a expliqué ce qu'il codait etc. et dit qu'il utilisait MySQL. Comme ce qu'il codait était censé être utilisé avec des bases de données assez énormes, je lui ai demandé pourquoi il n'utilisait pas PostgreSQL qui, d'après ce que j'avais compris était plus performant pour de grosses bases. Il m'a confirmé ce fait mais m'a dit qu'il ne l'avais pas choisi parce qu'il ne savait pas si le projet allait perdurer car les 3 fondateurs l'avaient quitté
J'ai cherché sur Google des faits mais je n'ai pas pu trouver...
Est-ce que quelqu'un peut confirmer ou infirmer ?
Merci d'avance.
PostgreSQL est beaucoup plus ancien que MySQL. MySQL est paru en 1995 tandis que PostgreSQL, en 1985. C'est un peu normal qu'après 25 ans, les fondateurs le quittent. J'aurais beaucoup plus de soucis à me faire par rapport à MySQL et son rachat par Oracle. D'ailleurs, les fondateurs de MySQL ont eux aussi quitté leur projet (le fondateur a créé MariaDB par exemple).
Bref, dire sans preuves que PostgreSQL va couler parce que 3 personnes sont parties, ça me paraît un peu abusé.
Edit: Édition de l'intervalle de temps comme punkka l'a dit
Pour MySQL, malgré le rachat de Sun par Oracle, ils ont annoncé leur volonté de faire perdurer le projet. Ca a été dit par justement un des fondateurs de MySQL : le laisser libre et gratuit. Et même essayer de lui faire bénéficier de certaines fonctionnalités supplémentaires qu'Oracle a...
PostgreSQL a fait un énorme bon en avant ces dernières années.
- Langage procédural très complet
- fonctions de fenêtrage
- CTE
- CTE récursives
- Supporte très bien la concurrence (plusieurs 100aines d'utilisateurs simultanément)
- Complètement libre et gratuit (contrairement à MySQL).
Il ridiculise totalement MySQL.
De plus en plus, PostgreSQL est considéré comme une alternative, ou un très sérieux concurrent de SQL Server.
C'est une valeur sûr maintenant, il n'est pas prêt de disparaître.
C'est aussi ridicule de dire que PostgreSQL va disparaître que de dire que MySQL va disparaître. Toujours est-il que ces bases de données évoluent de façon totalement différentes : il n'y a pas d'entreprise derrière PostgreSQL (un peu comme Debian pour Linux) tandis que MySQL appartient à Oracle que l'on peut plus ou moins considérer comme un concurrent (à quelques centaines de fonctionnalités près).
Ne paniquez pas par rapport aux oiseaux de mauvais augure, ce SGBD est largement utilisé notamment par de grandes boîtes françaises (des milliers de To de bdd de Météo France sont sous PostgreSQL si ma mémoire est bonne), ce n'est pas juste un "petit projet dans un garage" à l'avenir incertain.
Mysql est certe rapide pour des petits volumes de données, mais dès que ça devient important, y'a plus personne!
Il y a peu j'ai testé une requête effectuant une jointure entre deux alias de la même table qui contenait 400 000 entrées, j'ai eu le droit à un beau "Mysql Server has gone away".
Bilan, myslq ne peut pas remplace PostgreSQL dans toute les situations!
J'ai une question supplémentaire sur ce sujet, les serveurs mutualisés proposent tous une BDD sous MySQL, mais d'après ce que j'ai vu, aucun ne propose une base postgre (dans des prix équivalents). Ceci n'est-il pas une limite aux BDD postgre ?
PS : Existe-il des serveurs gratuits équipés de posgre ?
Merci pour ce lien même si : "Espace disque : 10 Mo".
Cela confirme bien ce que je pense, MySQL reste la base de données pour les utilisateurs les plus modestes mais également les plus nombreux.
Merci pour ce lien même si : "Espace disque : 10 Mo".
Cela confirme bien ce que je pense, MySQL reste la base de données pour les utilisateurs les plus modestes mais également les plus nombreux.
Parce que c'est le plus populaire. Si la demande pour PostgreSQL est grandissante, je suis certain qu'on le verra apparaître de plus en plus.
@LoupSolitaire : Je ne comprends pas ce que vient faire ton lien dans cette histoire.
Mon lien montre que MySQL peut supporter de gros volumes de données, et que si jamais les perfs s'écroulent sur des grosses tables, il est possible de contourner le problème assez facilement
Mon lien montre que MySQL peut supporter de gros volumes de données, et que si jamais les perfs s'écroulent sur des grosses tables, il est possible de contourner le problème assez facilement
Si tu veux comparer le nombre d'inserts par secondes.
Pour Oracle ça peut monter à plusieurs centaines de milliers de lignes par secondes.
Le but c'est pas de jouer à celui qui a le plus grand nombre d'inserts par secondes, car ça dépend pas seulement du SGBDR, mais aussi du hardware (j'ai un peu l'impression d'enfoncer une grande porte ouverte, mais visiblement c'est pas évident pour tout le monde).
Le but de mon lien était juste de montrer qu'effectivement les perfs de Mysql s'écroulent à un moment, mais que ça se contourne...
Le lien n'a aucun rapport avec ce qui a été dit dans le topic, il parle d'une table dans laquelle on ajoute rapidement des données. Il n'y a aucun accès concurrent, aucun accès aux données.
Et surtout, le lien ne concerne pas seulement MySQL : ça serait logiquement plus rapide avec n'importe quel SGBDR.
Bref, peut-être as-tu vu quelque chose que nous n'avons pas vu, si c'est le cas ce serait bien que tu le mentionnes. Jusqu'à présent, je continue à croire que ce lien n'a rien à faire dans ce topic.
Moi j'ai compris hein... L'autre dit que MySQL ne tient pas sur des grosses tables, son lien montre le contraire. Je ne vois pas ce qu'il vous faut de plus...
Tu n'as donc pas compris toi non plus. Son lien indique seulement que MySQL est capable de tenir jusqu'à un certain point 1200 nouvelles lignes par seconde, pas qu'il tient sur des grosses tables.
Ce qu'il faut de plus, c'est le nombre de temps que ça prend sur une table (genre quelques millions de ligne) pour faire telle ou telle requête. Il faut évidemment que le SGBDR soit en mesure de gérer l'intégrité référentielle, ce que MyISAM ne sait pas faire (on évite de comparer des pommes et des oranges...). On pourrait aussi comparer avec X utilisateurs sur la table. Avec le même environnement.
Ça, ça pourrait être un comparatif intéressant entre deux SGBDR, parce que le lien ne prouve rien du tout. Que MySQL soit capable d'avoir des tables de plusieurs Gio, c'est pas une nouvelle.
J'ai pas prétendu faire un comparatif exhaustif hein, je donne un lien avec un exemple en réponse à un commentaire sur un aspect particulier (et un seul) de MySQL.
Rien à foutre de comparer avec Oracle ou whatever, mais si vous tenez vraiment à avoir un comparatif exhautif, faites le vous même, mais ne me prêtez pas cette intention lorsque je poste juste un lien et un commentaire débile de 4 caractères.
EDIT :
Citation : Fayden
Ce qu'il faut de plus, c'est le nombre de temps que ça prend sur une table (genre quelques millions de ligne) pour faire telle ou telle requête.
Tiens au fait, si tu as un nombre de répétitions d'une action par seconde, tu peux en déduire immédiatement le temps pris par une action
Il faut aussi arrêter la masturbation intellectuelle sur un point : ce n'est pas avec vos petits projets persos que vous arriverez à la limite de capacité de MySQL. Surtout si vous apprenez à le configurer.
Dans ma boîte on utilise principalement MySQL (et un peu Oracle quand le client fait chier) (et pas PostgreSQL parce qu'à mon avis quand le produit a été conçu, personne ne connaissait / n'avait envie d'y toucher mais je pense pas que ce soit compliqué de l'adapter).
On a pas un seul client qui a eu des problèmes de perfs ; pour donner une idée on a des projets avec des bases de plusieurs To avec des milliers d'enregistrements par seconde, et ça tourne nickel.
Alors effectivement ça pourrait être plus optimisé avec un autre SGBD (on a pas de gros volume sur les clients Oracle, assez bizarrement) ; mais ce que je veux dire par là c'est que y'a tout un tas de bonnes raisons pour choisir PostgreSQL sur un projet perso. Les performances n'en sont pas une.
PS :
Citation : LoupSolitaire
Citation : Fayden
Ce qu'il faut de plus, c'est le nombre de temps que ça prend sur une table (genre quelques millions de ligne) pour faire telle ou telle requête.
Tiens au fait, si tu as un nombre de répétitions d'une action par seconde, tu peux en déduire immédiatement le temps pris par une action
Attention, on ne peut pas interpoler des performances de BDD avec ce genre d'info : il faut faire de vrais tests.
C'est fréquent d'avoir :
- Une requête longue (genre 1s) avec 1 utilisateur mais pas beaucoup plus longue (1.1 s) avec 100 utilisateurs.
- Une requête courte avec 1000 utilisateurs qui va devenir super longue avec 1010 utilisateurs, parce que tu vas péter la capacité du serveur. Idem avec une requête qui marche nickel au temps t puis qui pète 10 minutes après parce qu'une table est devenue trop grosse.
C'est très visible sur le lien de LoupSolitaire : de 0 à 9.5 Menregistrements, on a des performances identiques (environ 1300 inserts / s, que ce soit avec 1 ou 9 000 000 enregistrement). Après on explose les capacités du disque, le disque gratte et les performances s'effondrent.
De toutes façons, hautes performances et gestion relationnelle ne vont pas ensemble. Quand on cherche les performances, on dénormalise les données (= on vire les clés étrangères), on ne cherche plus une cohérence forte entre les données et on ne fait aucun trigger.
Pour moi, pgSQL est bien pour ceux qui veulent "s'instruire" en SQL et faire quelques choses plus poussées qu'avec MySQL, mais le remplacer n'est pas une fin en soi.
Il faut aussi arrêter la masturbation intellectuelle sur un point : ce n'est pas avec vos petits projets persos que vous arriverez à la limite de capacité de MySQL. Surtout si vous apprenez à le configurer.
Perso si j'utilise pg c'est surtout pour les features (procs stockées, géométrie, fulltext, etc), la puissance, la rigueur, la simplicité d'utilisation, et le fait qu'il me fait pas chier. Les performances ça joue aussi, mais c'est secondaire. Ceci dit, au niveau perfs, la plupart du temps, c'est pareil sur des requêtes simples, et sur des requêtes compliquées, y'a pas photo.
Citation : SpaceFox
on a pas de gros volume sur les clients Oracle, assez bizarrement
C'est bizarrement assez souvent le cas, les mecs paient (cher) pour avoir oracle parce qu'un commercial les a baratinés, alors que ça aurait très bien tourné avec une BDD opensource...
Citation : SpaceFox
C'est très visible sur le lien de LoupSolitaire : de 0 à 9.5 Menregistrements, on a des performances identiques (environ 1300 inserts / s, que ce soit avec 1 ou 9 000 000 enregistrement). Après on explose les capacités du disque, le disque gratte et les performances s'effondrent.
En fait ce lien c'est du grand n'importe quoi puisque :
- le mec s'étonne qu'en groupant les INSERTS dans une transaction ça va plus vite (lol), par contre il ne s'étonne pas qu'avec 1 INSERT par transaction il puisse faire plus de 150 INSERT/s sans passer en mode innodb_flush_log_at_trx_commit=2, en fait il en fait plus de 1000, ce qui signifie que soit il a un RAID BBU très lent, soit il a mal configuré ses disques et le fsync() est ignoré, et donc risque de corruption.
- pour ce genre de scénario tu load tes données en gros paquets d'après un fichier (COPY sous pg et LOAD DATA INFILE sous MySQL) dans une partition et tu ne fais surtout pas d'INSERTs individuels. Dans ce cas sur un desktop de base en configurant bien le truc tu vas tourner vers 1M rows/s donc 1000x plus.
- le mec vire ses duplicatas (1) avec un INSERT ON DUPLICATE KEY UPDATE donc forcément c'est lent.
- le mec démarre son bench à froid sur des buffers vides et il s'étonne que ça ralentit quand les buffers sont pleins (on benchmark normalement l'état stationnaire, pas la transitoire)
- le mec dit "primary key derived from data" donc je suppose que sa clé primaire est plus ou moins aléatoire ou en tout cas pas dans un ordre séquentiel style AUTO_INCREMENT ; il a pas l'air d'être au courant que (2) les tables InnoDB sont structurées en forme de btree sur la clé primaire... donc des insertions avec des PK dans le désordre amènent à construire le dit btree de la façon la moins optimale possible. (la façon la plus optimale étant d'insérer les données dans l'ordre de la PK).
(1) et (2) amènent à la conclusion logique que le working set est la table complète donc dès que la table + index dépasse les buffers ça s'écroule, c'est le résultat de ses mesures mais il n'explique pas pourquoi (bizarre !!! alors que c'est extrêmement simple puisque je viens de vous l'expliquer entre 2 bières).
En conclusion ce lien est un excellent exemple pour montrer qu'une BDD mal configurée ça rame grave.
C'est bizarrement assez souvent le cas, les mecs paient (cher) pour avoir oracle parce qu'un commercial les a baratinés, alors que ça aurait très bien tourné avec une BDD opensource...
Et quand tu leur prouve par A + B que ça tourne très bien avec de l'OpenSource, ils refusent quand même, parce que "on a toujours fait comme ça" et "c'est gratuit, donc ça peut pas être mieux".
En fait, le développement web serait vachement simplifié sans les clients (ou avec des clients intelligents, mais ça j'ai encore jamais vu). Mais on gagnerais moins de sous ^^'
PS : J'ai pas lu l'article en question, juste le graphique qui montrait un cas que j'ai vu déjà trop souvent dans ma courte expérience professionnelle
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
If you'd like to join us, read "How do we work at OpenClassrooms"! :)
Blond, bouclé, toujours le sourire aux lèvres...
Blond, bouclé, toujours le sourire aux lèvres...
Blond, bouclé, toujours le sourire aux lèvres...
Blond, bouclé, toujours le sourire aux lèvres...