Postgres 9.1 contre Mysql 5.6 InnoDB?

Question

Question simple - quoi de mieux pour une base de données de taille moyenne/grande avec une exigence de compatibilité avec ACID en 2012.

J'ai tout lu (enfin la plupart) sur mySQL vs pgSQL mais la plupart de ces articles concernent respectivement les versions 4,5,1 et 7,8 et sont assez datés (2008,2009). C'est presque 2012 maintenant, donc je suppose que nous pourrions essayer de jeter un nouveau regard sur la question.

En gros, je voudrais savoir s'il y a quelque chose dans PostgreSQL qui dépasse la facilité d'utilisation, la disponibilité et une plus grande base de développeurs/connaissances de MySQL.

L'optimiseur de requêtes de MySQL est-il toujours stupide? Est-il toujours super lent sur des requêtes très compliquées?

Frappez-Moi! :)

PS. Et ne m'envoyez pas de lunettes ni de wiki. Je suis à la recherche de quelques points spécifiques et non d'un aperçu + Je fais plus confiance à StackOverflow qu'à une page aléatoire avec un "gars intelligent" qui brille de sa lumière.

Addendum

Taille du projet : Supposons un système de commande avec environ 10-100 commandes/jour par compte, quelques milliers de comptes, éventuellement, chacun peut avoir plusieurs centaines à plusieurs milliers d'utilisateurs.

Mieux à : être à l'épreuve du temps et flexible en ce qui concerne les exigences croissantes et changeantes. Les performances sont également importantes pour maintenir les coûts bas dans le département du matériel. La disponibilité d'une main-d'œuvre qualifiée serait également un facteur.

OLTP ou OLAP : OLTP

Answer 1

L'optimiseur de requêtes de MySQL est-il toujours stupide? Est-il toujours super lent sur des requêtes très compliquées?

Tous les optimiseurs de requête sont parfois stupides. PostgreSQL est moins stupide dans la plupart des cas. Certaines des fonctionnalités SQL les plus récentes de PostgreSQL (fonctions de fenêtrage, requêtes récursives AVEC, etc.) sont très puissantes mais si vous avez un ORM stupide, elles pourraient ne pas être utilisables.

Taille du projet: disons un système de commande avec environ 10 à 100 commandes/jour par compte, quelques milliers de comptes, éventuellement, chacun peut avoir plusieurs centaines à plusieurs milliers d'utilisateurs.

Ne sonne pas si grand - bien à portée d'une grande boîte.

Mieux: être évolutif et flexible en ce qui concerne les exigences croissantes et changeantes.

PostgreSQL dispose d'une solide équipe de développeurs, avec une communauté étendue de contributeurs. Politique de publication est strict, avec des corrections de bugs uniquement dans les versions ponctuelles. Suivez toujours la dernière version de 9.1.x pour les corrections de bogues.

Dans le passé, MySQL a eu une attitude un peu plus détendue vis-à-vis des numéros de version. Cela pourrait changer avec Oracle en charge. Je ne connais pas les politiques des différentes fourches.

Les performances sont également importantes pour maintenir les coûts bas dans le département du matériel.

Je serais surpris si le matériel s'avérait être un composant majeur dans un projet de cette taille.

La disponibilité d'une main-d'œuvre qualifiée serait également un facteur.

C'est votre décision clé. Si vous avez une équipe de pirates expérimentés Perl + PostgreSQL assis au ralenti, utilisez-le. Si vos gens connaissent LISP et MySQL, utilisez-le.

OLTP ou OLAP: OLTP

PostgreSQL a toujours été fort sur OLTP.

Mon point de vue personnel est que la liste de diffusion PostgreSQL est remplie de personnes polies, serviables et compétentes. Vous avez un contact direct avec les utilisateurs des bases de données Terabyte et les pirates qui ont construit des parties majeures du code. La qualité du support est vraiment excellente.

Answer 2

PostgreSQL est beaucoup plus avancé en ce qui concerne les fonctionnalités SQL.

Choses que MySQL n'a toujours pas (et PostgreSQL a):

• contraintes reportables
• vérifier les contraintes (MySQL 8.0. 16 les a ajoutés, MariaDB 10.2 les a)

• jointure externe complète
  MySQL utilise silencieusement une jointure interne avec quelques variantes de syntaxe:
  https://rextester.com/ADME4379
  

• jointures latérales

• expressions régulières ne fonctionne pas avec UTF-8 (Corrigé avec MySQL 8. )
• les expressions régulières ne prennent pas en charge le remplacement ou la sous-chaîne (Introduit avec MySQL 8. )
• fonctions de table (select * from my_function())
• expressions de table communes (Introduit avec MySQL 8. )
• requêtes récursives (Introduit avec MySQL 8. )
• cTE inscriptibles
• fonctions de fenêtre (Introduit avec MySQL 8. )
• index basé sur la fonction
• index partiel
• statistiques multi-colonnes
• recherche plein texte sur les tables transactionnelles (MySQL 5.6 prend en charge cela)
• Fonctionnalités SIG sur les tables transactionnelles
• Opérateur EXCEPT ou INTERSECT
• vous ne pouvez pas utiliser deux fois une table temporaire dans la même instruction select
• vous ne pouvez pas utiliser la table en cours de modification (mise à jour/suppression/insertion) dans une sous-sélection

• vous ne pouvez pas créer une vue qui utilise une table dérivée(Possible depuis MySQL 8.0)

   create view x as select * from (select * from y);
  

• cohérence de lecture au niveau de l'instruction. Nécessaire pour par exemple:
  update foo set x = y, y = x ou
  update foo set a = b, a = a + 100
• dDL transactionnel
• déclencheurs DDL
• contraintes d'exclusion
• magasin de clés/valeurs
• Indexation de documents JSON complets
• types de plages
• domaines
• tableaux (y compris les index sur les tableaux)
• rôles (groupes) pour gérer les privilèges des utilisateurs (MariaDB les a , Introduit avec MySQL 8. )
• requêtes parallèles (depuis Postgres 9.6 )
• types de données définis par l'utilisateur (y compris les contraintes de vérification)
• vues matérialisées
• agrégats personnalisés
• fonctions de fenêtre personnalisées
• type de données boolean approprié
  _{(traiter toute expression qui peut être convertie en un nombre non nul comme "vrai" n'est pas un type booléen approprié)}

En ce qui concerne les fonctionnalités spatiales/SIG, Postgres avec PostGIS est également beaucoup plus performant. Ici est une belle comparaison.

Je ne sais pas ce que vous appelez "facilité d'utilisation" mais il y a plusieurs fonctionnalités SQL modernes que je ne voudrais pas manquer (CTE, fonctions de fenêtrage) qui définiraient pour moi "facilité d'utilisation".

Maintenant, PostgreSQL n'est pas parfait et probablement la chose la plus désagréable peut être, pour régler le processus VACUUM redouté pour une base de données d'écriture lourde.

Answer 3

En plus de @ a_horse_with_no_name answer , je veux nommer quelques fonctionnalités que j'aime tant dans PostgreSQL:

• type de données de tableaux ;
• extension hstore - très utile pour stocker key->value données, possible de créer un index sur des colonnes de ce type;
• diverses extensions de langage - Je trouve Python très utile en ce qui concerne la gestion des données non structurées;
• distinct on syntaxe - Je pense que celle-ci devrait être une fonctionnalité SQL ANSI, elle me semble très naturelle (par opposition au groupe MySQL par syntaxe);
• types composites;
• types d'enregistrement;
• héritage ;
• Caractéristiques de la version 9.3:
  • jointures latérales - une chose qui me manque de SQL Server (où il a appelé externe/croix appliquer );
  • support JSON natif ;
  • déclencheurs DDL ;
  • récursif , matérialisé , modifiable vues;

Answer 4

PostgreSQL est une base de données plus mature, elle a un historique plus long, elle est plus conforme à ANSI SQL, son optimiseur de requêtes est nettement meilleur. MySQL a différents moteurs de stockage comme MyISAM, InnoDB, en mémoire, tous sont incompatibles dans le sens où une requête SQL qui s'exécute sur un moteur peut produire une erreur de syntaxe lorsqu'elle est exécutée sur un autre moteur. Les procédures stockées sont meilleures dans PostgreSQL.