+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Responsable Livres

    Avatar de MaitrePylos
    Homme Profil pro
    DBA & Dev PHP
    Inscrit en
    juin 2005
    Messages
    4 477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA & Dev PHP
    Secteur : Service public

    Informations forums :
    Inscription : juin 2005
    Messages : 4 477
    Points : 10 180
    Points
    10 180

    Par défaut [Comparatif] Performances SIG : PostGreSQL/PostGIS vs SQL Server Spatial

    Comparatif sig et performances.



    Frédéric Brouard a réalisé un test de comparaison de performance des cartouches spatiales dans deux moteurs de base de données.

    Le présent test consiste à comparer la performance d'une dizaine de requêtes identiques sur le plan logique, consacrées au traitement spatial des données entre PostgreSQL et Microsoft SQL Server dont le SIG de chacun propose les mêmes fonctionnalités du standard OGC.

    Les requêtes ont porté sur les données spatiales disponibles librement auprès de l'État français en matière de géographie politique et routière (GEOFLA et ROUTE 500)
    .

    Vous pouvez lire le comparatif ici : http://g-ernaelsten.developpez.com/t...-performances/


    Et vous ?

    Que pensez-vous de ce comparatif?
    Utilisez-vous d’autres bases de données pour vos SIG? Lesquelles ?

  2. #2
    Membre averti

    Inscrit en
    juin 2008
    Messages
    284
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 284
    Points : 327
    Points
    327

    Par défaut

    Article très intéressant. AU delà du bench ça m'a permis de connaitre des fonctionnalités intéressantes. J'ai été étonné de voir que les données liées au routes étaient gratuites.

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    71
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 71
    Points : 103
    Points
    103

    Par défaut

    J'ai une interrogation: quelle configuration l'auteur a fait sur PostgreSQL ? et sur SQL Server ?
    Par exemple, sur certaines requêtes, on signale que SQL Server fait du parallélisme à la différence de PostgreSQL. Mais la version 9.6.x n'active pas le parallélisme par défaut et certains paramètres de base sont assez limités.

    A moins que le but était de montrer les performances des 2 serveurs "out of the box" ?

  4. #4
    Rédacteur
    Avatar de eclesia
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    2 060
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 2 060
    Points : 2 939
    Points
    2 939

    Par défaut

    Dommage que SQL-Server ne respecte pas le standard pour les requetes SIG : ISO/IEC 13249-3 SQL/MM

    +1 pour PostgreSQL

  5. #5
    Modérateur

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    4 508
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : janvier 2010
    Messages : 4 508
    Points : 9 123
    Points
    9 123

    Par défaut

    Citation Envoyé par csperandio Voir le message
    A moins que le but était de montrer les performances des 2 serveurs "out of the box" ?
    C'est en effet le cas comme le précise l'article :
    Les installations des deux SGBDR sont standard. Aucun réglage particulier n'a été mis en œuvre au niveau des serveurs.

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    71
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 71
    Points : 103
    Points
    103

    Par défaut

    Citation Envoyé par aieeeuuuuu Voir le message
    C'est en effet le cas comme le précise l'article :
    Mon impatience de lire le test m'a fait sauter cette partie

    Je ne sais pas si ce genre de test est pertinent sur le plan des performances. On voit que SQL Server a des réglages de performances par défaut alors que pour PostgreSQL le choix a été de réduire les ressources utilisées (je parle du serveur et non de PgAdmin). Je tiens à signaler que je n'ai pas de préférence: j'ai juste fait des tests avec PostgreSQL (pour voir si c'était une bonne solution de remplacement à Oracle pour nos besoins), ce qui m'a permis d'appréhender son fonctionnement.

    Néanmoins, cela a permis de voir ce que l'on peut faire comme type de requêtes dans ce contexte

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2010
    Messages : 8
    Points : 16
    Points
    16

    Par défaut

    Bonjour,
    je réagis ici car je suis assez choqué par le contenu de ce comparatif.

    Comme csperandio l'a très justement fait remarquer, le seul intérêt de cet article est de comparer les configurations "out of the box" des deux serveurs, certainement pas leurs performances en situation de production.

    L'utilisation de données spatiales en devient tout à fait anecdotique.

    Pour information, la configuration par défaut de PostgreSQL est extrêmement conservatrice en terme de ressources (work_mem = 4MB, shared_buffers = 128MB). Totalement inadaptée à la manipulation de données spatiales.
    Quelques minutes de recherche sur internet auraient suffit à l'auteur pour y trouver les paramètres à ajuster ainsi que les valeurs recommandées pour un environnement de production.

    Je remarque aussi un très grand déséquilibre dans la maîtrise des deux SGBD.
    Deux exemples au hasard :

    Pour SQL Server, nous avons créé une base de nom DB_GEO en mode de récupération simple afin d'éviter une journalisation continue et sans purge des transactions.
    Et pourquoi ne pas avoir fait de même pour PostgreSQL, qui journalise en continu par défaut ? Parce que l'auteur ne savait pas que c'était le cas, ni qu'il état possible de désactiver la journalisation dans PostgreSQL je suppose.


    NOTA : la commande PG dump est bloquante, car elle pose un verrou de type lecture (AccessShareLock) pendant toute la durée de la sauvegarde, verrou qui peut ne pas être acquis si une transaction est en cours. Ceci empêche donc les sauvegardes à chaud contrairement à SQL Server qui effectue un snapshot de la base, ce qui n'empêche nullement des transactions en cours, ni le démarrage de nouvelles transactions au cours de la sauvegarde
    C'est FAUX !! ACCESS SHARE n'est bloqué que par ACCESS EXCLUSIVE, qui n'est posé que par les requête de modification de structure de la base de données (DDL). Une telle affirmation sans vérification est assez scandaleuse ! Un minimum de lecture de la documentation de PostgreSQL serait la bienvenue (une simple recherche Google aussi, car cette documentation est très bien indexée). https://www.postgresql.org/docs/9.6/...t-locking.html

    Et une autre remarque qui pourrait être risible si elle n'était aussi affligeante :
    les commandes de sauvegardes et de restaurations de PostGreSQL sont très mal documentées et peu d'exemples montrent comment faire telle ou telle sauvegarde et encore moins, restauration. Nous avons perdu plus de quatre heures en tentatives diverses et essais infructueux avant de trouver la bonne syntaxe par tâtonnement.
    4h ? Pour au final utiliser les paramètre par défaut de pg_dump ? --blobs est inclu par défaut, comme le précise la lecture de la documentation de pg_dump, lecture qui doit prendre 10 minutes au maximum. 4h de tâtonnement pour cela, ça laisse songeur, voire dubitatif...

    Au mieux, pour la restauration, PostGreSQL met deux fois plus de temps que SQL Server en mode non compressé en utilisant huit threads.
    Deux fois plus de temps pour une base de données journalisée contre une base de données non journalisée ? Quelle incroyable surprise !!!


    Il serait de bon aloi que l'auteur corrige son article, ou mieux le réalise dans des conditions un tant soit peu proches de la réalité.

  8. #8
    Membre actif
    Homme Profil pro
    Informaticien
    Inscrit en
    juin 2004
    Messages
    171
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gers (Midi Pyrénées)

    Informations professionnelles :
    Activité : Informaticien
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : juin 2004
    Messages : 171
    Points : 289
    Points
    289

    Par défaut

    Je trouve dommage d'élaborer et de mettre en place des tests aussi évolués sans tenir compte des spécifications de chaque SGBD.

    Déjà si SQL Server tourne sous Windows, pourquoi ne pas avoir installé PostgreSQL sous linux ?
    Comme cité plus haut, les paramètres par défaut, limitent volontairement l'allocation des ressources, et une meilleure configuration aurait (peut être) équilibré la donne.


    Pourquoi ne pas configurer SQL Server de façon optimale et demander à une personne compétente de faire de même avec PostgreSQL ?

    La question n'est pas de savoir lequel des SGBD sortira vainqueur mais au moins, il y aurait une vision claire des performances de chacun.

  9. #9
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 119
    Points : 39 735
    Points
    39 735
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par thewild Voir le message
    Je remarque aussi un très grand déséquilibre dans la maîtrise des deux SGBD.
    Deux exemples au hasard :
    Pour SQL Server, nous avons créé une base de nom DB_GEO en mode de récupération simple afin d'éviter une journalisation continue et sans purge des transactions.
    Et pourquoi ne pas avoir fait de même pour PostgreSQL, qui journalise en continu par défaut ? Parce que l'auteur ne savait pas que c'était le cas, ni qu'il état possible de désactiver la journalisation dans PostgreSQL je suppose.
    Dans les deux cas, les SGBD Journalisent. SQL Server en mode simple journalise autant que PostGreSQL sinon plus, car il est "ACID compliant" sur le DML, comme sur le DDL et le TCL alors que PostGreSQL ne sait pas transactionner les commandes DDL et TCL. En outre le passage en mode simple dans SQL Server n'est pas un évitement de la journalisation (cela ne correspond donc pas à "aucune journalisation", cela d'ailleurs est impossible sous SQL Server...), mais une purge automatique des transactions du journal afin d'éviter que le fichier du journal ne grossisse indéfiniment. Cela provoque donc des traitements supplémentaires au détriment des performances de SQL Server comparativement à PotsGreSQL !!! Donc ce que vous dites est stupide... Cela n'a en outre aucune importance sur nos tests, car ils portent pour l'essentiel sur des requêtes de lecture qui par nature ne journalisent pas. Donc vous me faites un procès imbécile ! (J'en suis habitué de la part de la communauté PG qui voit toujours d'un mauvais œil toute critique envers PG !)

    Citation Envoyé par thewild Voir le message
    C'est FAUX !! ACCESS SHARE n'est bloqué que par ACCESS EXCLUSIVE, qui n'est posé que par les requête de modification de structure de la base de données (DDL). Une telle affirmation sans vérification est assez scandaleuse ! Un minimum de lecture de la documentation de PostgreSQL serait la bienvenue (une simple recherche Google aussi, car cette documentation est très bien indexée). https://www.postgresql.org/docs/9.6/...t-locking.html
    La documentation est une chose, la pratique une autre. Il est facile de démontrer le blocage et je vous invite à faire une maquette sur le sujet.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  10. #10
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2010
    Messages : 8
    Points : 16
    Points
    16

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Donc vous me faites un procès imbécile ! (J'en suis habitué de la part de la communauté PG qui voit toujours d'un mauvais œil toute critique envers PG !)
    J'admets la critique, mais je remarque que vous évitez la principale qui vous est faite : l'utilisation de la configuration par défaut des deux SGBD.
    Vous semblez être un spécialiste de SQL Server, il aurait été de bon aloi de demander de l'aide à un spécialiste de PostgreSQL (ce que je ne suis pas) pour configurer votre serveur de test.

    Au passage, merci d'avoir pris la peine de répondre.


    Edit :
    Citation Envoyé par SQLpro Voir le message
    Il est facile de démontrer le blocage et je vous invite à faire une maquette sur le sujet.
    Je viens de faire un test. Je dumpe une base de donnée contenant une grosse table, et je peux sans problème en modifier le contenu. Seules les requêtes DDL sont bloquées. Pourriez-vous être plus spécifique ?

  11. #11
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 119
    Points : 39 735
    Points
    39 735
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par thewild Voir le message
    J'admets la critique, mais je remarque que vous évitez la principale qui vous est faite : l'utilisation de la configuration par défaut des deux SGBD.
    Vous semblez être un spécialiste de SQL Server, il aurait été de bon aloi de demander de l'aide à un spécialiste de PostgreSQL (ce que je ne suis pas) pour configurer votre serveur de test.
    La volumétrie étant faible, cela n'a pas beaucoup d'incidence sur les performances. Mais pour vous plaire, voici les réglages entrepris ce midi :
    postgresql.conf, modifications :

    ### cache
    shared_buffers = 2GB
    temp_buffers = 64MB
    work_mem = 1GB

    effective_cache_size = 4GB

    ### parallelisme
    max_worker_processes = 32
    max_parallel_workers_per_gather = 16


    Bien entendu le Service PostGreSQL a été redémarré.

    Et les résultats pour les 4 plus grosses requêtes, avec une moyenne sur 3 relances, après un essai pour la mise en cache :

    • Q3 est à 58 s. Pas de changement significatif (plutôt moins bon)...
    • Q10 est à 49 s. Pas de changement significatif.
    • Q5 est à 32 s. Pas de changement significatif.
    • Q7 est à 6 s. Changement significatif du à un balayage en parallèle



    Bref, absolument aucun changement comme je le prévoyais, apporté par la gestion du cache, du fait du faible jeu de données....
    En revanche, un changement significatif de la requête Q7 du fait de la gestion du parallélisme. Le temps a été divisé par 3 mais reste encore 20 fois plus lent que SQL Server !

    Nom : PG spatial Parallelism.jpg
Affichages : 451
Taille : 92,1 Ko

    Citation Envoyé par thewild Voir le message

    Au passage, merci d'avoir pris la peine de répondre.


    Edit :

    Je viens de faire un test. Je dumpe une base de donnée contenant une grosse table, et je peux sans problème en modifier le contenu. Seules les requêtes DDL sont bloquées. Pourriez-vous être plus spécifique ?
    Comme ce n'est pas l'objet du test, mais une note marginale, je ne vais pas m'amuser à reproduire ce problème qui nécessite de mettre en œuvre une boucle infinie de mise à jour.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2010
    Messages : 8
    Points : 16
    Points
    16

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Mais pour vous plaire
    Mais ce n'est pas pour me plaire, c'est pour donner un intérêt à votre comparatif (dommage de n'avoir pas fait dès le départ, ça aurait évité ce genre d'échange).
    Merci d'avoir fait ces changements, le test en est bien plus instructif.

    Pour information et dans l'éventualité où vous effectueriez d'autres comparatifs de ce genre dans le futur, sachez qu'il est déconseillé de mettre une valeur aussi haute pour shared_buffers sous Windows. 512MB c'est en général le maximum recommandé.
    Cela n'a pas d'importance dans le cas présent bien-sûr.

    Une dernière question, qu'entendez-vous par "les fonctions PostGIS ne peuvent être utilisées directement comme expression logique d'un prédicat" ?
    La syntaxe "WHERE ST_IsValid(thegeom) = false" est peu orthodoxe, on lui préfère en général "WHERE NOT ST_IsValid(thegeom)".


    Pour ce qui est des résultats du test, je constate que PostgreSQL a encore beaucoup de progrès à faire dans la parallélisation de ses requêtes. Ceci est encore plus vrai pour PostGIS, ses fonctions ayant pour l'instant un coût par défaut qui ne permet pas au planificateur de requête de faire les bons choix.

  13. #13
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2010
    Messages : 8
    Points : 16
    Points
    16

    Par défaut

    Je me permets de continuer la discussion.
    Vous avez choisi de ne faire retourner que les plus grosses requêtes. C'est un choix arbitraire, les requêtes les plus longues ne sont pas forcément les plus exécutés. A l'inverse, les requêtes courtes peuvent être exécutées très souvent. Bref, pour comparer les serveurs, la différence se fait en ratio, pas en temps absolu.

    J'ai exécuté toutes vos requêtes sur ma machine de développement. CPU légèrement moins bon en single thread (i3 2125), 8Go de RAM, un vieux SSD Kingston (je ne sais pas ce que ça vaut par rapport à un array RAID 10 de disques magnétiques, mais les tables doivent toutes être dans le cache).

    Q1: 2700ms (deux fois moins que sur votre serveur, 5 fois plus que SQL Server)
    Q2 : 86 ms (moitié moins que SQL Server sur votre serveur)
    Q3 : même résultat que vous, la requête est CPU bound, nos processeurs semblent équivalent (10 fois plus lent que SQL Server)
    Q4 : 6800ms, 30% mieux que vous, 3x plus rapide que SQL Server
    Q5 : 30s, pas de changement
    Q6 : gain x2 grace au parallélisme (2x plus lent que SQL Server). Notez que PostGIS a une fonction ST_ContainsProperly qui remplit exactement le rôle de NOT ST_Intersects(ST_Boundary(), ...). Exécution en 900ms avec cette fonction. Que donne SQL Server ?
    Q7 : Idem que vous, mais réécrivez la requête avec un CTE "WITH D AS (SELECT CODE_DEPT, ST_Centroid(geom) AS GEOM FROM S_GEO.DEPARTEMENT)", et la requête est 4x plus rapide que sur SQL Server (71ms). Je me demande ce que vous obtenez avec ce CTE sur SQL Server.
    Q8 : 196ms, gain de temps x2 (oui, les paramètres de configuration font une différence quand le serveur fait un quicksort en mémoire plutôt que sur le disque), un peu mieux que SQL Server...
    Q9, avec le parallélisme activé (Workers Launched: 4) : 292ms, 2x mieux que SQL Server

    La restauration prend 30s sur ma machine de développement. Nul doute que sur votre serveur, avec un maintenance_work_mem à une valeur correcte, vous obtiendrez des temps comparables à SQL Server.
    La conclusion ne me parait plus aussi nette, même si sur certaines requêtes la différence en faveur de SQL Server est très grande (10x). Sur certaines elle est importante en faveur de PostgreSQL (3x ou 4x).

  14. #14
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 119
    Points : 39 735
    Points
    39 735
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par rupteur Voir le message
    Je trouve dommage d'élaborer et de mettre en place des tests aussi évolués sans tenir compte des spécifications de chaque SGBD.

    Déjà si SQL Server tourne sous Windows, pourquoi ne pas avoir installé PostgreSQL sous linux ?
    Comme cité plus haut, les paramètres par défaut, limitent volontairement l'allocation des ressources, et une meilleure configuration aurait (peut être) équilibré la donne.

    Pourquoi ne pas configurer SQL Server de façon optimale et demander à une personne compétente de faire de même avec PostgreSQL ?

    La question n'est pas de savoir lequel des SGBD sortira vainqueur mais au moins, il y aurait une vision claire des performances de chacun.
    Apparemment vous n'avez pas lu correctement le papier, car j'indique que je ferais ces tests à nouveau et sous Linux lorsque SQL Server disposera d'une version officielle sous Linux, ce qui ne saurait tarder... Les versions actuelles de SQL Server sous linux étant encore en béta...

    D'autre part, hormis le parallélisme qui peut jouer dans certains cas, le réglage par défaut de PG sous Windows, n'est pas un handicap pour ce test. En effet la faible taille des données de la base est compatible avec les réglages mémoire par défaut.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  15. #15
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 119
    Points : 39 735
    Points
    39 735
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par thewild Voir le message
    Je me permets de continuer la discussion.
    Vous avez choisi de ne faire retourner que les plus grosses requêtes. C'est un choix arbitraire, les requêtes les plus longues ne sont pas forcément les plus exécutés. A l'inverse, les requêtes courtes peuvent être exécutées très souvent. Bref, pour comparer les serveurs, la différence se fait en ratio, pas en temps absolu.

    J'ai exécuté toutes vos requêtes sur ma machine de développement. CPU légèrement moins bon en single thread (i3 2125), 8Go de RAM, un vieux SSD Kingston (je ne sais pas ce que ça vaut par rapport à un array RAID 10 de disques magnétiques, mais les tables doivent toutes être dans le cache).

    Q1: 2700ms (deux fois moins que sur votre serveur, 5 fois plus que SQL Server)
    Q2 : 86 ms (moitié moins que SQL Server sur votre serveur)
    Q3 : même résultat que vous, la requête est CPU bound, nos processeurs semblent équivalent (10 fois plus lent que SQL Server)
    Q4 : 6800ms, 30% mieux que vous, 3x plus rapide que SQL Server
    Q5 : 30s, pas de changement
    Q6 : gain x2 grace au parallélisme (2x plus lent que SQL Server). Notez que PostGIS a une fonction ST_ContainsProperly qui remplit exactement le rôle de NOT ST_Intersects(ST_Boundary(), ...). Exécution en 900ms avec cette fonction. Que donne SQL Server ?
    Notre but était de comparer les fonctionnalités GIS, par de trouver des astuces spécifiques à un SGBDR particulier ! Il fallait donc que les requêtes soient, strictement identiques d'un point de vu logique. Or la fonction ST_ContainsProperly n'existe pas dans la norme SQL MM (spatial).
    Q7 : Idem que vous, mais réécrivez la requête avec un CTE "WITH D AS (SELECT CODE_DEPT, ST_Centroid(geom) AS GEOM FROM S_GEO.DEPARTEMENT)", et la requête est 4x plus rapide que sur SQL Server (71ms). Je me demande ce que vous obtenez avec ce CTE sur SQL Server
    Q8 : 196ms, gain de temps x2 (oui, les paramètres de configuration font une différence quand le serveur fait un quicksort en mémoire plutôt que sur le disque), un peu mieux que SQL Server...
    Q9, avec le parallélisme activé (Workers Launched: 4) : 292ms, 2x mieux que SQL Server

    La restauration prend 30s sur ma machine de développement. Nul doute que sur votre serveur, avec un maintenance_work_mem à une valeur correcte, vous obtiendrez des temps comparables à SQL Server.
    La conclusion ne me parait plus aussi nette, même si sur certaines requêtes la différence en faveur de SQL Server est très grande (10x). Sur certaines elle est importante en faveur de PostgreSQL (3x ou 4x).
    Pourquoi ne faites vous pas aussi le test sur SQL Server ? Il suffit de le télécharger, j'ai donné les liens de téléchargement :
    https://www.microsoft.com/fr-fr/sql-...ons-developers
    et il y a la sauvegarde de la base sous SQL Server et la commande est scriptée dans le papier. Ce serait diablement plus constructif...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  16. #16
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2010
    Messages : 8
    Points : 16
    Points
    16

    Par défaut

    Oui, j'ai voulu installer SQL Server sur ma machine de développement, mais apparemment mon OS n'était pas compatible (Windows 7 Pro).
    Si j'ai le temps j'essaierai de l'installer sur un Server 2012 R2 la semaine prochaine.

    Citation Envoyé par SQLpro Voir le message
    D'autre part, hormis le parallélisme qui peut jouer dans certains cas, le réglage par défaut de PG sous Windows, n'est pas un handicap pour ce test. En effet la faible taille des données de la base est compatible avec les réglages mémoire par défaut.
    Ce n'est pas tout à fait exact.
    Dans Q7, les réglages par défaut ne permettent pas de trier les résultats en mémoire, PostgreSQL doit écrire sur le disque.
    Pour la restauration de la base de donnée, le réglage le plus important est maintenance_work_mem. La valeur par défaut de 64Mo est trop basse pour que les index soient créés en mémoire.

  17. #17
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 119
    Points : 39 735
    Points
    39 735
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par thewild Voir le message
    Oui, j'ai voulu installer SQL Server sur ma machine de développement, mais apparemment mon OS n'était pas compatible (Windows 7 Pro).
    Si j'ai le temps j'essaierai de l'installer sur un Server 2012 R2 la semaine prochaine.
    Effectivement il faut un Windows 10 pour la 2016. Sinon, la version 2014. Ou encore la version Linux, mais encore en Béta...

    Citation Envoyé par thewild Voir le message
    Pour la restauration de la base de donnée, le réglage le plus important est maintenance_work_mem. La valeur par défaut de 64Mo est trop basse pour que les index soient créés en mémoire.
    Ce n'était pas le but du test. Donc, anecdotique...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  18. #18
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 119
    Points : 39 735
    Points
    39 735
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par thewild Voir le message
    C'est FAUX !! ACCESS SHARE n'est bloqué que par ACCESS EXCLUSIVE, qui n'est posé que par les requête de modification de structure de la base de données (DDL).
    Pour info et après différentes sources scrutées, voici les opérations bloquant la sauvegarde dans PostGreSQL :
    • Toutes opérations DDL : CREATE, ALTER et DROP
    • TRUNCATE TABLE
    • Le rafraichissement des vues matérialisées
    • Les opérations de maintenance d'index et de stats
    • les opérations de gestion du stockage
    • ...


    En sus, lorsque des transactions ont été démarrées au niveau d'isolation SERIALIZABLE avant de lancer la sauvegarde, les tables verrouillées ne figurent pas dans la sauvegarde (à confirmer).

    Pour information toujours, aucune de ces opérations n'est bloquante pour SQL Server lors des sauvegardes.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  19. #19
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 450
    Points : 3 029
    Points
    3 029
    Billets dans le blog
    6

    Par défaut

    Salut
    Si...
    Citation Envoyé par SQLpro Voir le message
    Ce n'était pas le but du test. Donc, anecdotique...
    Pourquois...
    Citation Envoyé par SQLpro Voir le message
    Pour info et après différentes sources scrutées, voici les opérations bloquant la sauvegarde dans PostGreSQL :
    • Toutes opérations DDL : CREATE, ALTER et DROP
    • TRUNCATE TABLE
    • Le rafraichissement des vues matérialisées
    • Les opérations de maintenance d'index et de stats
    • les opérations de gestion du stockage
    • ...


    En sus, lorsque des transactions ont été démarrées au niveau d'isolation SERIALIZABLE avant de lancer la sauvegarde, les tables verrouillées ne figurent pas dans la sauvegarde (à confirmer).

    Pour information toujours, aucune de ces opérations n'est bloquante pour SQL Server lors des sauvegardes.

    A +
    Je voudrais juste éclairer ceux qui un temps soit peu accordent de l'importance aux propos de QUI ON SAIT..
    Par rapport au post précédent...
    Ce que dit la doc de PostgreSQL sur les commandes bloquant la sauvegarde (à savoir avec dump)...
    Les sauvegardes créées par pg_dump sont cohérentes, ce qui signifie que la sauvegarde représente une image de la base de données au moment où commence l'exécution de pg_dump. pg_dump ne bloque pas les autres opérations sur la base lorsqu'il fonctionne (sauf celles qui nécessitent un verrou exclusif, comme la plupart des formes d'ALTER TABLE.)


    Mais MONSIEUR QUI ON SAIT n'accorde aucune crédibilité a la doc de PostgreSQL. Pire encore, il refuse l'orthographe officiel "PostgreSQL" en mettant toujours "PostGreSQL".
    Par ailleurs, celui qui veut apprendre PostgreSQL, pose des questions, mais ne critique pas pour...
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  20. #20
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 450
    Points : 3 029
    Points
    3 029
    Billets dans le blog
    6

    Par défaut

    Salut
    Citation Envoyé par MaitrePylos Voir le message
    Que pensez-vous de ce comparatif?
    Il nuit à la crédibilité de developpez.com
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

Discussions similaires

  1. Comparatif Performance Application Serveur Apache/Php contre Tomcat/Java
    Par w3blogfr dans le forum Serveurs (Apache, IIS,...)
    Réponses: 1
    Dernier message: 04/12/2009, 09h33
  2. Réponses: 9
    Dernier message: 16/05/2008, 15h04
  3. [SGBDR|SGBDO] Existe-t-il un comparatif de performance ?
    Par neguib dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 17/02/2006, 16h29
  4. [SGBDR][XML] Quel est le comparatif des performances ?
    Par kritopal dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 28/11/2005, 11h56
  5. Comparatif performance SGBD...
    Par glouglou dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 19/05/2004, 19h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo