Postgresql par rapport à MySQL: Comment leurs tailles de données se comparent les uns aux autres?

Question

Pour le même ensemble de données, avec des données de texte pour la plupart, comment les données (tableau + index) taille de Postgresql par rapport à celle de MySQL?

• Postgresql utilise MVCC, qui suggéreraient la taille des données serait plus grand

• Dans cette présentation, le plus grand site de blog au Japon ont parlé de leur migration de Postgresql à MySQL. Une de leurs raisons pour se éloigner de Postgresql était que la taille des données Postgresql était trop grand (p 41.): Migration de PostgreSQL vers MySQL à Cocolog, plus grande communauté de Blog du Japon

• Postgresql a compression de données, ce qui devrait rendre la taille des données plus petites. Mais MySQL Plugin a également la compression.

Est-ce que quelqu'un a une expérience réelle sur la façon dont les tailles de données Postgresql et MySQL comparer les uns aux autres?

Answer 1

• MySQL utilise MVCC aussi bien, il suffit de cocher InnoDB. Mais, dans PostgreSQL, vous pouvez changer le facteur de remplissage pour faire place pour les mises à jour futures. Avec cela, vous peut créer une base de données qui possède un espace pour les données actuelles, mais aussi pour certains futures mises à jour et les suppressions. Quand autovacuum et HOT font leurs choses à droite, la taille de votre base de données peut être stable.
• Le blog est sur les anciennes versions, beaucoup des choses ont changé et PostgreSQL fait un bien meilleur travail en compression comme dans l'ancien temps.
• La compression dépend du type de données, la configuration et la vitesse ainsi. Toi il faut tester pour voir comment il fonctionne pour vous la situation.

je l'ai fait quelques conversions de MySQL à PostgreSQL et dans tous ces cas, PostgreSQL était d'environ 10% plus petit (MySQL 5.0 => PostgreSQL 8.3 et 8.4). Cette 10% a été utilisé pour modifier le facteur de remplissage sur les tables les plus mises à jour, celles-ci ont été mis à un facteur de remplissage de 60 à 70. La vitesse était beaucoup mieux (pas plus de problèmes avec plus de 20 utilisateurs simultanés) et la taille des données est stable et, sans MVCC aller hors de contrôle ou à vide très loin derrière.

MySQL et PostgreSQL sont deux bêtes différentes, PostgreSQL est tout sur la fiabilité où MySQL est populair.

Answer 2

Les deux ont leurs besoins de stockage dans leur documentation respective:

MySQL: http://dev.mysql.com /doc/refman/5.1/en/storage-requirements.html
Postgres: http://www.postgresql.org/docs/current/interactive/ datatype.html

Une rapide comparaison des deux ne présentent pas de flagrant « ZOMG PostGres nécessite 2 méga-octets pour stocker un champ de bits » différences de type. Je suppose que Postgres pourrait avoir en tête de métadonnées plus élevé que MySQL, ou doit étendre ses fichiers de données en gros morceaux, mais je ne trouve rien évident que Postgres « déchets » espace pour lequel la migration vers MySQL est le remède.

Answer 3

Je voudrais ajouter que pour les grandes colonnes magasins, postgresql prend également l'avantage de les comprimer en utilisant un « membre assez simple et très rapide de la famille LZ des techniques de compression »

Pour en savoir plus sur ce sujet, consultez http: // www .postgresql.org / documents / 9,0 / statique / stockage toast.html

Il est plutôt faible niveau et probablement pas nécessaire de connaître, mais puisque vous utilisez un blog, vous pouvez bénéficier.

Answer 4

A propos des index,

stocke les données MySQL whithin l'indice qui les rend énormes. Postgres ne le font pas. Cela signifie que la taille de stockage d'un indice b-arbre dans Postgres ne dépend pas du nombre de la colonne, il couvre ou qui la colonne de type de données a.

Postgres supporte également des index partiels (par exemple où le statut = 0) qui est une fonctionnalité très puissante pour empêcher la construction d'index sur des millions de lignes quand seulement quelques centaines est nécessaire.

Puisque vous allez mettre beaucoup de données dans Postgres, vous trouverez probablement pratique pour être en mesure de créer des index whitout de verrouillage de la table.

Envoyé de mon iPhone. Désolé pour l'orthographe et la mauvaise absence de références