Vous n'êtes pas identifié(e).
Bonjour,
Pour information, ce petit benchmark concernant un besoin d'extraction de données.
La question est simple... Partant d'une table de période de temps, agréger les périodes recouvrantes par item, pour n'en avoir plus que l'essentiel... (packing d'intervalles).
Tests effectuées sur MySQL version 5.5, PostGreSQL version 8.4 et MS SQL Server version 2008 R2 avec des jeux d'essais allant de 1 000 à 3 000 000 de lignes.
Résultats :
* PotsGreSQL est entre 3 et 13 fois moins rapide que SQL Server
* MySQL est entre 59 et 5 947 fois moins rapide que SQL Server
...en fonction de la montée en charge.
Bref, une excellente surprise pour PostGreSQL qui confirme grandes fonctionnalités, qualités et performances dans le monde des SGBDR libre !
Tous les détails, les conditions et les scripts SQL pour rejouer ce benchmark chez vous sur : http://blog.developpez.com/sqlpro/p9826 … -avec-sql/
A +
Dernière modification par SQLpro (21/03/2011 19:45:58)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pourquoi le choix de PostgreSQL 8.4 ? La version 9.0 aurait probablement donné de meilleures performances...
Par ailleurs vous n'indiquez pas le profile matériel et OS de la plateforme de test. J'imagine que vous avez utilisé Windows ?
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Étant donné le test, difficile de dire ce qui fait la différence. Je présume (j'ai regardé très vite l'exemple) que c'est avant tout l'acquisition de verrous sur les enregistrements de cette table de compteur qui dure longtemps sur le test ?
Marc.
Hors ligne
Pourquoi le choix de PostgreSQL 8.4 ? La version 9.0 aurait probablement donné de meilleures performances...
Bonne remarque. Mais j'attends en général toujours 1 an avant de prendre la version suivante par soucis de sécurité. Cependant, dès que j'ai le temps je vais refaire des tests avec la version 9.
Par ailleurs vous n'indiquez pas le profile matériel et OS de la plateforme de test. J'imagine que vous avez utilisé Windows ?
Si toutes les plateformes sont mentionnées (voir paragraphe CONDITION DES TESTS). Les tests comparatif ont été effectué sur Windows, évidemment, car SQL Server n'est pas disponible sous Linux.
Ceci dit, cela ne change rien à mon sens. Je dirais même qu'il y aurait un léger désavantage, car les formats de page de données étant plus petits un extra overhead va s'ajouter sur les parcours.
De plus il faudrait formater la même machine sous Linux et Windows pour que le test soit équitable... Si quelqu'un veut le faire, je prête mon HP Proliant DL 385 G2 pour ce faire !!!!
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Étant donné le test, difficile de dire ce qui fait la différence. Je présume (j'ai regardé très vite l'exemple) que c'est avant tout l'acquisition de verrous sur les enregistrements de cette table de compteur qui dure longtemps sur le test ?
S'agissant de lectures, cela influe peu...
Non je dirais ce qui fait la différence avec MS SQL Server c'est l'utilisation de l'opérateur CROSS APPLY. Microsoft à proposé sa normalisation au comité. SQL...
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Ok, je comprends mieux, ce n'est pas le bon article qui est pointé dans le post.
Marc.
Hors ligne
Effectivement, l'absence de CROSS APPLY doit faire une bonne partie de la différence.
Par contre, pour information, un module aurait certainement permis de gratter un peu plus de performances sur PostgreSQL: l'utilisation du type «temporal», disponible en 9.0 (avec les opérateurs d'union d'intervalles déjà tout écrits, et le fait que les index sont utilisables pour détecter les intervalles en intersection avec d'autres, par exemple). Enfin, c'est un module à ajouter, mais ça se fait assez facilement.
http://temporal.projects.postgresql.org/reference.html
Pour ce qui est des performances de PostgreSQL sous Windows, il y a un coût, qui dépend des types de requêtes et d'usage, mais est souvent mesuré à 20 à 30%, par rapport aux performances de la même machine sous Linux. Tout simplement parce que PostgreSQL est écrit pour des systèmes Unix, utilise des appels système Unix en permanence (fork, mémoire partagée système 5, sémaphores, etc…) et que sous Windows, il y a une (fine, sauf pour fork) couche d'émulation. D'où la question de Damien. Mais il est tout à fait possible que ça soit un test sur lequel ça aurait eu peu d'impact.
Marc.
Hors ligne
Pour ce qui est des performances de PostgreSQL sous Windows, il y a un coût, qui dépend des types de requêtes et d'usage, mais est souvent mesuré à 20 à 30%, par rapport aux performances de la même machine sous Linux. Tout simplement parce que PostgreSQL est écrit pour des systèmes Unix, utilise des appels système Unix en permanence (fork, mémoire partagée système 5, sémaphores, etc…) et que sous Windows, il y a une (fine, sauf pour fork) couche d'émulation. D'où la question de Damien. Mais il est tout à fait possible que ça soit un test sur lequel ça aurait eu peu d'impact.
Ce serait intéressant de creuser ce point sur un même serveur. En gros, jouer une dizaine de requêtes sur une volumétrie non négligeable (du gendre base 20 Go RAM 4 Go) et voir les différences entre Windows et Linux. mais je ferais le pari qu'avec Windows 2008 R2, PostGreSQL arrive en tête par rpport à Linux sur les requêtes à forte volumétrie !!! Je suis prêt à parier une caisse de champagne !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
En soit, ça ne serait probablement pas très intéressant, vu que c'est un bench qui a été déjà fait un bon nombre de fois (il suffit d'aller chercher dans la mailing list pgsql-performance par exemple). C'est la différence de performances qui varie d'un bench à l'autre. Mais Windows n'a jamais été devant pour le moment. À ma connaissance, il n'y a pas non plus eu de bench avec la version 64 bits Windows, qui est toute nouvelle en 9.0. Donc de toutes façons, en cas de gros tri, et de très gros besoin en work mem, on était coincé très rapidement avec windows.
D'un autre côté, ça serait une première d'avoir un benchmark où la version PostgreSQL pour Windows serait devant la version Unix.
Par contre, je pense qu'une base de 20Go, avec 4Go de RAM sur le serveur, ça ne va pas intéresser grand monde.
Marc.
Hors ligne
Il se trouve que certaines mauvaises pratiques de Windows ont été remaniées dans la version 2008. Par exemple, lors des formatages de disques, Win 2000 à 2003 prenait une entête de disque de 63 Ko avec un formatage de bas niveau à 64 Ko. Ce qui faisait décaler toutes les lectures de 1 Ko et donc obligeait le serveur à lire physiquement deux fois plus de données que nécessaire dans les version antérieures à la 2008... De même il y a eu de notable améliorations dans la gestion de la mémoire. Enfin, et contrairement à ce que prétendent certains discours très obsolète, Windows présente aujourd'hui (et à depuis la version 2003) un niveau de fiabilité qui a été jugé supérieur à ceux des linux dans des études menées dans de grands comptes....
Par exemple le fameux coup du "faut rebooter ton serveur Windows toutes les nuits si tu veut pas avoir d'ennuis" est quand même plus qu'obsolète. Je veux bien que cela ait été vrai du temps de Windows 16 bits (3.11) mais depuis Windows 2000 SP 4 je n'ai jamais entendu parlé de fuites de mémoire par exemple ! (sauf composants hors MS bien entendu...).
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Ben si les grandes études dans les grands comptes le disent, on ne peut que les croire.
Bref, faites vos benchs si vous le souhaitez, bien sûr. Il n'y aura vraisemblablement rien de magique, Postgres a toujours été optimisé pour les systèmes Unix. Mais si vous obtenez des chiffres allant dans l'autre sens, pourquoi pas, ça pourrait être un témoignage intéressant pour nuancer tout ce qui a été mis en évidence jusque là.
Par contre, personne n'a parlé de la fiabilité de windows dans aucun message du thread. Je ne vois pas ce qui vous a poussé à le mentionner…
Marc.
Hors ligne
