MySQL est-il meilleur que PostgreSQL dans quelque chose?

8

Je sais que la question semble provocatrice, mais ce n'est vraiment pas le cas. Je trouve récemment MySQL limitant dans beaucoup de domaines et j'aime de plus en plus PostgreSQL. Il évolue beaucoup mieux et respecte beaucoup plus les standards SQL que MySQL.

Je suis encore nouveau dans le monde PostgreSQL et comme je suis prêt à m'éloigner de MySQL pour tous mes futurs projets, ce que je veux savoir, c'est: y a-t-il une caractéristique particulière de MySQL qui le fait mieux (comme dans plus performant ou plus convivial, etc.) que dans PostgreSQL?

Je me demande ce que je vais manquer de MySQL. J'ai déjà trouvé que les champs AUTO_INCREMENT dans MySQL sont plus pratiques que SEQUENCES dans PostgreSQL et le déploiement dans Windows était problématique dans le passé (plus de problème. Plus de problème pour moi).

Quoi d'autre?

mysql sql postgresql

— Massimiliano Torromeo
source

Voici une curiosité en quelque sorte: stackoverflow.com/questions/2221787/…

— Paul

4

wikivs.com/wiki/MySQL_vs_PostgreSQL

— Charles Stewart

Je déteste mysql, mais il fait MERGE / UPSERT plus facilement que PG, et je trouve les champs sensibles à la casse ennuyeux

— Neil McGuigan

3

Vous abordez clairement cela du point de vue du développeur, vous pouvez donc trouver des réponses plus utiles chez SO.

D'un point de vue administratif:
- Réplication (HA)
- Réplication (mise à l'échelle *)
- Réplication (sauvegardes)
- Support d'application
- Taille et profondeur de la communauté (Documentation, Support)
- Base d'installation existante / jobs disponibles

^{* Notez que vous avez postgresmieux mentionné la mise à l'échelle. la mise à l'échelle signifie quelque chose de différent pour tout le monde, mais en règle générale, les choses qui ont un moyen de répartir la charge sur plusieurs serveurs évoluent mieux que les autres.}

— cagenut
source

Je m'intéresse également aux aspects administratifs. Je ne savais pas où poster ceci. BTW vous avez raison sur la mise à l'échelle. Par échelles, je voulais vraiment dire, sur une seule machine, pas sur des clusters. MySQL a très peu de gain de performances sur les systèmes multicœurs et de nos jours le multicœur est la norme. J'ai également vu MySQL passer de bonnes performances à presque inutiles lorsque la charge de travail a augmenté, et l'impression était que postgresql aurait mieux géré la charge, mais je comprends que cela est discutable et qu'il convient de mieux s'enquérir. BTW, les arguments de réplication méritent d'être considérés.

— Massimiliano Torromeo

1

MySQL avait l'habitude d'avoir très peu de gain de performance sur le multicœur, mais si vous utilisez une version 5.0 bien corrigée, presque n'importe quelle version 5.1, une version innodb-plugin (/ xtradb), ou une version 5.4 ce n'est plus vrai. N'essayant pas d'être conflictuel, votre ralentissement anecdotique de mysql aurait presque certainement pu être résolu, et vos postgres "d'impression" l'auraient mieux géré est une supposition nue. Le point clé ici est que postgres vs mysql est quelque chose que vous pouvez beaucoup bavarder du point de vue du développement et de la sophistique, mais du point de vue opérationnel / commercial, le dossier a été fermé il y a des années.

— cagenut

Bien sûr, j'ai spécifié que c'était juste une impression parce que si je n'essaye pas de servir les mêmes données sous la même charge, je ne peux pas être sûr, et je sais que je ne prouve vraiment rien. Merci d'avoir clarifié les derniers gains de performances de MySQL.

— Massimiliano Torromeo

J'utilise toujours le type "serial" dans postgres, je le trouve plus pratique que "integer auto_increment". Ou pensiez-vous peut-être autre chose?

— ptman

3

COUNT (*) est également beaucoup plus lent avec PSQL. Vous êtes censé créer des déclencheurs pour ce type de fonctionnalité.

— EarthMind
source

1

Intéressant, mais pour autant que je l'ai compris, cela ne s'applique qu'aux COUNT (*) requêtes SANS la clause where sur le moteur MyISAM. En dehors de cela, il fonctionne de manière similaire. Ou est-ce que postgresql est encore plus lent comparé à InnoDB et MyISAM avec une clause where?

— Massimiliano Torromeo

Que veux-tu dire par là ? sélectionnez count ( ) dans foo; ne fonctionne pas dans pgsql? S'il est vrai que count ( ) est plus lent dans postgres par rapport à mysql, il y a une raison à cela et une solution de contournement. Un bon aperçu peut être trouvé sur wikivs.com/wiki/MySQL_vs_PostgreSQL

— Sibster

1

Il est plus lent pour la même raison que InnoDB de MySQL, en savoir plus ici: wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

— EarthMind

3

COUNT (*) est plus lent en raison de l'implémentation MVCC. Vous gagnez en termes de performances de lecture / écriture, mais comme les transactions peuvent être dans différents états, il devient difficile de déterminer le nombre "vrai".

— Avery Payne

2

Parce que Postgres effectue effectivement une copie sur écriture pour chaque mise à jour (afin qu'il puisse traiter les transactions), si vous n'avez pas besoin de transactions et que vous effectuez beaucoup d'écritures par rapport aux lectures, MySQL n'aura pas la surcharge que PostgreS volonté. (chaque enregistrement mis à jour doit en écrire davantage, mettre à jour les index, etc.)

— Joe H.
source

1

Je pense que vous devriez qualifier cela un tout petit peu. Oui, ce sera plus rapide, mais il n'y aura aucune garantie de cohérence dans vos données. Cela convient parfaitement à certaines situations (écriture de commentaires d'utilisateurs sur un site Web) mais peut poser des problèmes dans d'autres (prise de commande en ligne d'un "panier").

— Avery Payne

1

Je peux penser à une chose qui manque à PostgreSQL:

Collationner

Je pense qu'il y avait aussi quelque chose avec le blocage, l'insertion ou la mise à jour. Mais je n'arrive pas à me souvenir de ce que c'était réellement. : S

— Egon
source

1

Le champ auto_increment étant 'maniable' n'est pas très pertinent n'est-ce pas? Oracle a des séquences et est sans aucun doute la base de données commerciale la plus utilisée au monde.

C'est une énorme quantité d'informations à trouver sur la façon dont PostgreSQL est plus sûr et ainsi de suite. Je vais juste vous diriger vers cette page sur le wiki PostgreSQL (sans doute une opinion colorée, mais c'est ce que vous cherchez de toute façon).

Beaucoup de gens mentionnent sur cette page que MySQL est plus convivial pour les débutants. Donc? Expliquez-moi en quoi cela est important dans un environnement critique pour la mission.

— wzzrd
source

Étant des séquences, l'approche la plus utilisée ne rend pas les champs auto_increment moins «pratiques», et cela me concerne parce que je demande des différences entre les 2 dbms en question. Mais cela ne m'empêche pas de passer à pgsql, donc je conviens que ce n'est pas un vrai problème.

— Massimiliano Torromeo

1

MySQL est souvent appelé grep SQL . Quant à moi (maintenant au moment de l'écriture), il ressemble à peu près à PHP - assez maladroit, mais populaire.

Je me demande ce que je vais manquer de MySQL.

Essayez de renommer une base de données pour le tout début. ;) Ajoutez ensuite des indices conditionnels (manquants).

PS Je peux pointer au moins une bonne fonctionnalité incontestable de MySQL - il prend en charge plutôt des types de données économes en espace aussi petits que l'octet (non signé) par exemple. Cela pourrait économiser beaucoup de RAM et d'espace disque lorsqu'il est utilisé en conséquence. Mais il y a plutôt quelques goodies à mentionner en plus, hélas. Et la comparaison sur le lien qui vous a été donné est vraiment chouette.

— poige
source

0

auto_increment est pratique jusqu'à ce que vous réalisiez qu'ils craignent pour les tables avec une concurrence d'insertion extrêmement élevée, auquel cas ils deviennent un goulot d'étranglement et vous êtes obligé d'implémenter une séquence à l'aide d'une table MyISAM.

Quoi qu'il en soit, pour répondre à votre question, la plus grande chose que MySQL ait eue a été de configurer facilement la réplication qui permet de chaîner la réplication et de lire les esclaves. Cependant, Postgres aura cela dans la prochaine version, 9.0 (qui est déjà en état alpha).

— mage2k
source