Discussion :

[MaitrePylos]

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 ?

[bilbot]

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.

[csperandio]

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" ?

[eclesia]

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

+1 pour PostgreSQL

[aieeeuuuuu]

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.

[csperandio]

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

[thewild]

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é.

[alassanediakite]

Salut

Que pensez-vous de ce comparatif?

Il nuit à la crédibilité de developpez.com
@+