Postgres 9.1 vs Mysql 5.6 InnoDB ?

Question

Simple question - ce qui serait mieux pour une moyenne/grande taille de la base de données avec l'exigence de compatibilité avec l'ACIDE en 2012.

J'ai lu tout ça (et bien plus) à propos de mySQL vs pgSQL mais la plupart de ces postes se rapportent à la version 4,5.1 et 7,8, respectivement, et sont assez anciennes (2008,2009). Ses presque 2012 maintenant donc je suppose que nous pourrions essayer et de prendre un regard nouveau sur la question.

Fondamentalement, je voudrais savoir si il y a quelque chose dans PostgreSQL que le poids de la facilité d'utilisation, la disponibilité et le plus grand développeur/de la base de connaissances de MySQL.

Est MySQL optimiseur de requête encore stupide? Est-il encore super très lent sur les requêtes compliquées?

M'a frappé! :)

PS. Et ne m'envoyez pas de lunettes de protection ou un wiki. Je suis à la recherche de quelques points particuliers pas une vue d'ensemble + j'ai confiance StackOverflow plus que quelques page au hasard avec des "smart guy" de briller sa lumière.

Addendum

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

Mieux: être dans l'avenir et flexible quand il s'agit à la croissance et à l'évolution des besoins. La Performance est également important de maintenir les coûts bas en service de matériel. Également la disponibilité de la main-d'œuvre qualifiée serait un facteur.

OLTP ou OLAP: OLTP

Answer 1

PostgreSQL est beaucoup plus avancé quand il s'agit de fonctions SQL.

Choses que MySQL ne fonctionne toujours pas (et PostgreSQL a):

• deferrable contraintes
• vérifier les contraintes
• jointure externe complète
  MySQL silencieusement utilise une jointure interne avec quelques variantes de syntaxe: http://sqlfiddle.com/#!2/88ff95/1
  Le SQLFiddle a été créé à l'aide de MySQL 5.5.32
• les expressions régulières ne fonctionnent pas avec l'encodage UTF-8
• les fonctions de table ( select * from my_function() )
• les expressions de table communes
• requêtes récursives (à l'aide d'expressions de table communes)
• les fonctions de fenêtrage
• la fonction d'index de base
• index partiel
• texte intégral de recherche sur les opérations de tables (MySQL 5.6 prend en charge ce maintenant)
• SIG sur les tables transactionnelles
• MOINS ou se CROISENT opérateur
• vous ne pouvez pas utiliser une table temporaire deux fois dans la même instruction select
• vous ne pouvez pas utiliser la table en cours de modification (update/delete/insert) dans une sous-sélection
• transactionnelle DDL
• rôles (groupes) afin de gérer les privilèges des utilisateurs

Pas sûr de ce que vous appelez la "facilité d'utilisation", mais il y a plusieurs fonctions SQL que je ne veux pas manquer (d'expressions de table communes, les fonctions de fenêtrage) qui permettrait de définir la "facilité d'utilisation" pour moi.

Maintenant, PostgreSQL n'est pas parfait, et probablement le plus odieux chose peut être, pour accorder le redoutable processus de mise sous VIDE d'une grosse base de données en écriture.

Answer 2

Est MySQL optimiseur de requête encore stupide? Est-il encore super lent sur très requêtes compliquées?

Tous les optimiseurs de requêtes sont stupides de temps en temps. PostgreSQL est moins stupide dans la plupart des cas. Certains de PostgreSQL est plus récente fonctions SQL (fenêtrage fonctions récursives AVEC les requêtes, etc) sont très puissantes mais si vous avez un muet ORM ils pourraient ne pas être utilisable.

Taille du projet: Dire un système de commande avec environ 10-100 les commandes/jour et par compte, quelques milliers de comptes, finalement, chaque peut avoir plusieurs centaines à plusieurs milliers d'utilisateurs.

N'est pas grande à la portée d'une grosse boîte.

Mieux: être dans l'avenir et flexible quand il s'agit de croissance et de l'évolution des exigences.

PostgreSQL dispose d'une forte équipe de développeurs, avec une large communauté de contributeurs. La libération politique est stricte, avec des corrections de bogues-seulement au point de rejet. Toujours suivre la dernière version de 9.1.x pour les corrections de bugs.

MySQL a eu un peu plus de l'attitude détendue à des numéros de version dans le passé. Ce qui peut changer avec Oracle en charge. Je ne suis pas familier avec les politiques des différents forks.

La Performance est également important de maintenir les coûts bas en service de matériel.

Je serais surpris si le matériel s'est avéré être un élément majeur dans un projet de cette taille.

Également la disponibilité de la main-d'œuvre qualifiée serait un facteur.

C'est votre clé de décideur. Si vous avez une équipe expérimentée de Perl + PostgreSQL, les pirates se sont assis autour d'inactivité, utilisez-le. Si vos gens savent Lisp et MySQL ensuite l'utiliser.

OLTP ou OLAP: OLTP

PostgreSQL a toujours été forte sur OLTP.

De mon point de vue personnel est que PostgreSQL liste de diffusion complète de poli, serviable, des personnes bien informées. Vous êtes en contact direct avec les usagers au Téraoctet de bases de données et les pirates informatiques qui ont construit de grandes parties du code. La qualité de la prise en charge est vraiment excellent.

Answer 3

Comme un ajout à l' @a_horse_with_no_name réponse, je veux nommer quelques traits qui me plaît tant dans PostgreSQL:

• les matrices de type de données;
• hstore extension très utile pour stocker key->value données, possible de créer des index sur les colonnes de ce type;
• différentes extensions de langage - je trouver Python très utile quand il s'agit de données non structurées de manutention;
• distinct on de la syntaxe je pense que cela devrait être la norme ANSI SQL, il semble très naturel pour moi (contrairement à MySQL groupe par la syntaxe);
• types de composé;
• les types d'enregistrement;
• l'héritage;
• La Version 9.3 caractéristiques:
  • latérale joint - une chose qui me manque de SQL Server (où il est appelé à l'extérieur/croix s'appliquent);
  • natif de support JSON;
  • Les déclencheurs DDL;
  • récursive, matérialisé, pouvant être mis à jour points de vue;

Answer 4

Voici quelques points de repère utilisant ces versions exactes:

http://posulliv.github.io/2012/06/29/mysql-postgres-bench/

Mon opinion était que MySQL était environ 30% plus rapide pour les tâches simples et 500% plus lente pour les requêtes plus complexes, probablement en raison de l'optimiseur de requêtes.

Answer 5

PostgreSQL est une base de données plus mature, son historique est plus long, il est davantage compatible ANSI SQL, son optimiseur de requêtes est bien meilleur. MySQL a différents moteurs de stockage tels que MyISAM, InnoDB, en mémoire. Tous sont incompatibles, en ce sens qu'une requête SQL exécutée sur un moteur peut générer une erreur de syntaxe lorsqu'elle est exécutée sur un autre moteur. Les procédures stockées sont meilleures dans PostgreSQL.