Journal MySQL/Postgree

Posté par  .
Étiquettes : aucune
0
4
mar.
2003
Salut

Sans rentrer dans un gros troll, j'aimerais avoir votre avis concernant la dernière version de MySQL. J'ai mis en place il y a un bout de temps déjà une base MySQL 3.22.32 qui est vite devenue énorme et qui m'a demandé beaucoup de boulot en optimisation afin d'avoir des perfs respectables. Plus je travaillais dessus et plus je me demandais s'il ne valait pas mieux tout migrer en Postgree, car pas mal de monde m'en disait du bien. Il y a quelque temps, la nouvelle version de MySQL est sortie, semblant avoir refait son retard sur Postgree. Qu'en est-il vraiment ? Quelqu'un a-t-il déjà comparé les deux solutions avec des grosses charges de données/trafic ?

  • # Re: MySQL/Postgree

    Posté par  (site web personnel) . Évalué à 1.

    Si j'ai bien compris le bidule, MySQL s'en sort mieux avec beaucoup de lecture. Postgree mieux lors de requète complexe et avec beaucoup d'écriture par rapport au lecture.

    "La première sécurité est la liberté"

    • [^] # Re: MySQL/Postgree

      Posté par  . Évalué à 5.

      Il n'y a pratiquement pas de benchmarks correctement spécifiés qui aient été publiés (autre que les articles trollesques du genre "d'après mes essais, TrucSQL c'est tellement pourri caca que mon serveur s'est mis à fumer").

      Une exception intéressante, à prendre avec son lot de pincettes : http://www.sqlite.org/speed.html(...)
      Une chose qu'oublient trop souvent ceux qui font ce genre de mesures, c'est que MySQL n'utilise pas les transactions par défaut (il faut paramétrer les tables spécialement). Donc quand tu lances une séquence de requêtes du type BEGIN; 25000 INSERTs; COMMIT, en réalité MySQL va écrire chacune des 25000 insertions séparément, tandis qu'un moteur transactionnel les écrira en une seule fois : pour que la comparaison soit plus juste, il faudrait par exemple enlever le "BEGIN..COMMIT" en réglant le AUTOCOMMIT à 1, de façon à ce que les moteurs transactionnels se comportent de la même façon ; ou alors au contraire fusionner les INSERTs par paquets de 50 ou 100, afin d'aider MySQL.

      Sur des écritures bien pensées (INSERTs groupés par exemple), MySQL peut être très très rapide. Son principal handicap en termes de performance (il y a aussi le SQL moins puissant que celui des autres de SGBD) est en cas d'accès concurrents multiples. Avec le type de tables par défaut, une écriture en cours verrouille (i.e. fait attendre) les lectures et vice-versa : si tu as de très longues écritures sur une base qui doit être consultable en permanence, cela peut être rhédibitoire. Il paraît qu'utiliser le type de tables InnoDB résout le problème

      Dernière chose : MySQL 4 (utilisable en production) inclut un cache de requêtes SQL, dont l'efficacité peut être redoutable dans certains types de situation : notamment si ta base est consultée très régulièrement mais qu'elle n'est mise à jour que de façon ponctuelle (cas typique d'un site Web "dynamique" n'ayant pas lui-même de système de cache).

  • # Re: MySQL/Postgree

    Posté par  . Évalué à 3.

    MySQL 4 en version stable va sortir d'ici peu (dans le mois).
    Regarde si ça peut te convenir.
    MySQL est plus rapide mais ça a un prix forcément. Donc ça dépend de ton utilisation.

  • # Re: MySQL/Postgree

    Posté par  (site web personnel) . Évalué à 2.

    Je ne peux pas te renseigner sur les différences de vitesse, n'ayant pas fait de vrais tests entre les 2. Par contre, il est clair que les requêtes complexes sont plus facile avec PostGreSQL, qui respecte la norme SQL...

    la nouvelle version de MySQL est sortie, semblant avoir refait son retard sur Postgree

    Juste un petit détail : on peut dire qu'ils ont rajouté une partie des fonctionnalités qui manquaient et qui sont présentes sous PostGre, mais je ne pense pas que l'expression "rattrapper le retard" soit valable. Ces nouvelles fonctions de MySQL sont, justement, nouvelles, alors que sous PostGre, elles sont là depuis plus longtemps, donc éprouvés, donc plus sûr.
    De manière générale, un soft plus vieux est plus mûr, et devrait moins souffrir de bug de jeunesse!

  • # Re: MySQL/Postgree

    Posté par  . Évalué à 6.

    Les deux SGBDR tournent aussi vite globalement. Ce n'est pas une migration rapide sous PostgreSQL qui va te faire gagner beaucoup, si jamais tu gagnes en perfo.
    Par contre PostgreSQL offre beaucoup de moyen pour gagner en vitesse. Entre autre, les requêtes complexes sous PostgreSQL peut nécessité 2 à 3 requêtes sous MySQL. Là il y a gain. De même PostgreSQL offre une grosse souplesse dans le vérouillage des tables. Tu peux initialiser une transaction alors que les tables sont modifiées par d'autres programmes. Sous Mysql, lorsque tu fais une transaction, les autres requêtes sont stoppées. De plus sous Mysql il y a le support de transaction mais que pour une table à la fois.

    Donc si tu envisages de passer sous PostgreSQL, lis la doc, prend un café, réfléchis un bon moment sur les gains possibles. Si finalement une migration vers PostgreSQL avec optimisation peut prendre beaucoup de temps, considère qu'il est peut-être plus interressant de changer de hardware ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.