DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017

Version imprimable

03/01/2018, 08h11
Michael Guilloux

DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017
DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017
Quels étaient vos SGBD préférés en 2017 ?

Comme il est de coutume depuis ces dernières années, le site DB-Engines, spécialisé dans le classement des moteurs de base de données, a livré son classement pour l’année qui vient de s’écouler. Au total, 341 systèmes de gestion de base de données (répartis entre différents modèles de bases de données) étaient en course pour le titre du SGBD de l’année 2017.

Il faut noter que le titre de SGDB de l'année est décerné au système qui enregistre la plus forte hausse en popularité (et non la popularité absolue) au cours de l'année en question. Le classement de DB-Engines ne mesure pas non plus le nombre d'installations des SGBD ni leur utilisation dans les systèmes informatiques. La popularité d'un système de gestion de base de données telle que mesurée par le classement DB-Engines se base en effet sur les paramètres suivants :
- le nombre de fois que le système est mentionné sur les sites web. Cette statistique est mesurée par le nombre de résultats de recherche dans les moteurs Google et Bing. Afin de compter seulement les résultats pertinents, les requêtes doivent inclure le mot-clé « database » ainsi que le nom du SGBD ;
- la fréquence des recherches dans Google Trends ;
- la fréquence des discussions techniques sur le système. Cette statistique est mesurée par le nombre de questions connexes et le nombre d’utilisateurs intéressés sur Stack Overflow et DBA Stack Exchange ;
- le nombre d’offres d’emploi dans lesquelles le système est mentionné sur Indeed et Simply Hired ;
- le nombre de profils sur les réseaux professionnels, dans lesquels le système est mentionné. Le réseau social utilisé ici est LinkedIn ;
- la pertinence sur les réseaux sociaux, mesurée par le nombre de tweets dans lesquels le système est mentionné.
En se basant sur ces critères, PostgreSQL est le SGBD qui a gagné le plus en popularité dans le classement DB-Engines au cours de la dernière année, c'est pourquoi il a été déclaré SGBD de l'année 2017. PostgreSQL a en effet enregistré un gain total de 55,81 points (+17 %) au cours de l'année 2017. D'après DB-Engines, la nouvelle version PostgreSQL 10 a certainement contribué à stimuler davantage l'intérêt pour le SGBD. « Avec l'introduction du partitionnement déclaratif, l'amélioration du parallélisme des requêtes, la réplication logique et la validation par quorum pour les réplications synchrones, PostgreSQL 10 s'est spécifiquement concentré sur les améliorations pour distribuer efficacement les données sur plusieurs nœuds. »

http://www.developpez.com/public/ima...17-postgre.png

Après PostgreSQL viennent ElasticSearch (à la deuxième place) et MariaDB (en troisième position). ElasticSearch a vu son score augmenter de 16,38 points (+ 15 %) en 2017. Deux faits, selon DB-Engines, peuvent avoir contribué à ce succès : la sortie d'ElasticSearch 6 en novembre dernier et l'effort d'Elastic, la société derrière ElasticSearch, de créer avec Elastic Stack un écosystème autour d'ElasticSearch, y compris des outils pour la collecte de données, la visualisation de données et l'apprentissage automatique. MariaDB a, quant à lui, amélioré son score de 13,26 points (+29 %) en 2017.

Il faut noter ici que ce n'est pas le pourcentage d'évolution des scores de popularité qui est regardé pour déterminer le SGBD de l'année. Mais c'est plutôt la différence entre les scores de popularité au début de deux années successives (ici janvier 2017 et janvier 2018), parce que cela permet de ne pas favoriser les SGBD avec une faible popularité au début de l'année.

Il faut aussi préciser que pour le titre de SGBD de l'année, PostgreSQL succède à SQL Server de Microsoft (vainqueur en 2016) et Oracle Database, SGBD de l'année 2015. En ce qui concerne la popularité absolue des SGBD, Oracle reste cependant encore leader devant MySQL et SQL Server. Ci-dessous le top 10 de DB-Engines.

http://www.developpez.com/public/ima...ngines2017.png

Sources : Blog DB-Engines, DB-Engines Ranking

Et vous ?

:fleche: Que pensez-vous de ce classement ?
:fleche: Quels ont été vos SGBD préférés en 2017 ? Selon quels critères ?
03/01/2018, 11h26
vanquish

Que pensez-vous de ce classement ?

Access seulement 3 places derrière PostGresSQL et loin devant MariaDB.
EnterpriseDB, 100 places derrières sa version Open Source (alors que c'est fondamentalement le même logiciel)

Ce classement de popularité ne renseigne sur rien d'autre que ... la popularité.
03/01/2018, 12h39
UndeadangerousK

Citation:

Envoyé par vanquish

Ce classement de popularité ne renseigne sur rien d'autre que ... la popularité.

A condition qu'il soit répertorié dans le classement pour qu'on puisse voter pour. Même si une liste exhaustive existe, les listes de vote sont souvent fermés. Ceci dit, l'open-source devient de plus en plus populaire et c'est une bonne chose à mon sens.
03/01/2018, 15h14
one_eye

Ce qui est sur c'est que les bases postgresql poussent comme des champignons ces derniers temps.

Après, sur la base préférée, on aura des dizaines de réponses différentes.
Certains regarderont le coût des licences (je parle ici de versions payantes) et s'orienteront vers pg (par exemple enterprisedb) ou mysql ou autres.
D'autres, en faisant abstraction de ces coûts de licence, regarderont la robustesse, les fonctionnalités, la performance et se tourneront vers oracle, db2 et sql server (qui pour moi sont au dessus de la mêlée).
D'autre, un peu de tout ça et on aura un autre résultat.
03/01/2018, 15h36
escartefigue

Comme tout classement, les critères retenus sont au moins aussi importants que le résultat et l'interprétation peut varier.

Par exemple, le critère "nombre de recherches dans Google" signifie un réel intérêt pour le SGBD, mais peut aussi être symptomatique d'un manque de documentation de la part de l'éditeur.

Pour parler du SGBD que je connais le mieux, à savoir DB2 for Z/OS (la version mainframe donc), il n'existe quasiment pas de documentation hors doc officielle IBM car celle-ci est extrêmement riche et précise, les recherches se font essentiellement sur le site IBM et au sein de forums consacrés. Point de recherche Google donc ;)

Autre exemple, le critère "nombre d’offres d’emploi dans lesquelles le système est mentionné sur Indeed et Simply Hired", ces sites représentent quelle proportion du marché de l'emploi informatique ?
Dans le monde ? en Europe ? en France ?

D'ailleurs je n'ai pas vu sur quel secteur géographique était effectué le classement

Etc...

Donc, ce classement en vaut un autre, il faut juste utiliser la bonne grille de lecture ;)
03/01/2018, 16h33
RaphAstronome

J'ai voté pour PostgreSQL car ce système est vraiment sympa. Par rapport à MySQL/MariaDB qui à toujours des bizarreries genre lorsque l'on met une chaîne trop longue elle est enregistrée tronquée. La possibilité de faire des modifications sur les tables (drop/create/alter ...) dans des transactions est très pratique en phase de développement. PostgreSQL est aussi très complet.

Coté inconvénients je dirais les migrations qui peuvent être assez compliqués et surtout longues lorsque l'on passe d'une version majeure à l'autre.

J'aime pas mal SQLite pour des usages en lecture seule, typiquement pour une publication d'observations qui n'est complété que par tous les plusieurs mois ou moins. Cela permet d'avoir juste un fichier à déployer et archiver.

Pour ce qui est des privateur à mon travail c'est quasi interdit car manque de maîtrise sur les données et le fait de ne pas pouvoir changer de fournisseur est particulièrement craint. Il faut dire que l'on nous à déjà fait une vacherie un fournisseur qui multiplie x10 le prix sans possibilité de changer :traine: . Résultat : projet abandonné. De plus la liberté d'installer n'importe où est très pratique (duplications de VMs, sur PC portable par exemple).
04/01/2018, 14h45
abriotde

Citation:

Envoyé par one_eye

Après, sur la base préférée, on aura des dizaines de réponses différentes.
Certains regarderont le coût des licences (je parle ici de versions payantes) et s'orienteront vers pg (par exemple enterprisedb) ou mysql ou autres.
D'autres, en faisant abstraction de ces coûts de licence, regarderont la robustesse, les fonctionnalités, la performance et se tourneront vers oracle, db2 et sql server (qui pour moi sont au dessus de la mêlée).
.

La vérité c'est que l'on ne peux pas faire totalement abstraction du coût quelque soit l'entreprise. SQL Server n'est pas plus performant ou robuste qu'un bon MariaDB ou PostgreSQL. Oracle est peut être plus performant mais beaucoup trop cher et complexe pour une très large majorité des utilisations (y compris dans les très grosses et riches entreprises). On ne peux pas non plus oublier le côté souplesse et migration... Le tout fais que dans la majorité des cas les bonnes solutions Open-Source l'emportent au delà de toute considérations politique et polémique.
07/01/2018, 09h26
SQLpro

Citation:

Envoyé par abriotde

La vérité c'est que l'on ne peux pas faire totalement abstraction du coût quelque soit l'entreprise. SQL Server n'est pas plus performant ou robuste qu'un bon MariaDB ou PostgreSQL.

Vous dites n'importe quoi. Non seulement SQL Server et nettement plus performant que PG, il suffit de lire de bons benchmarks (par exemple celui-ci : http://g-ernaelsten.developpez.com/t...-performances/ juste entre 4 et 10 fois plus rapide...) mais il est même nettement plus performant qu'Oracle pour un prix entre 4 et 25 fois moins cher...

A +
12/01/2018, 17h21
one_eye

Non SQL Server n'est pas nettement plus performant qu'oracle et oui on ne peux pas faire totalement abstraction du coût quelque soit l'entreprise.
Même si j'aime beaucoup postgresql, certaines fonctionnalités restent à améliorer (ça viendra au fur et à mesure des années j’espère).

Pour le coût des licences, ça dépend des négociations ...

Par exemple sur un serveur 2*6 core (tarifs négociés) :
mysql Enterprise sur 3 ans (licence au serveur. Même prix chaque année) : 10-12k au total
postgresql (avec distrib enterprisedb) sur 3 ans (licence au nb de cœurs. Même prix chaque année) : 30-35k au total
sql server enterprise : la je ne sais pas comment on compte (nous sommes dans des licences par cœurs). Pour les coût d'acquisition de licence c'est simple (prix public pour 2 coeurs : 14k) mais pour les années suivantes, je ne sais pas comment ça marche (rien, même prix chaque ou coût de maintenance)
db2 enterprise sur 3 ans (licence au nb de cœurs. Coût acquisition licence 1er année, puis maintenance sur les années suivantes): 100k au total
oracle enterprise sur 3 ans (licence au nb de cœurs. Coût acquisition licence 1er année, puis maintenance sur les années suivantes) : je ne sais plus mais plus cher encore.
17/01/2018, 22h12
SQLpro

Citation:

Envoyé par one_eye

Non SQL Server n'est pas nettement plus performant qu'oracle

Ha oui et que pensez vous de cet autre test :
https://www.periscopedata.com/blog/c...ver-and-oracle
"In all three examples, SQL Server outperformed Oracle by about 25-40%."

Il y a beaucoup d'autres exemples ou SQL Server obtient des performances très supérieures à Oracle. Ce qui pèche chez Oracle c'est son optimiseur qu'il faut sans arrêt bricoler pour avoir des performances justes acceptable, alors que sous SQL Server il est rare de devoir rajouter des "hint"...

A +
23/01/2018, 16h37
one_eye

Je ne me sers pas trop des benchs trouvés sur internet. On peut leur faire dire tout et son contraire. Mais ça peut me donner des infos sur certaines problématiques.
Pour l'optimiseur d'oracle, je suis d'accord. Pour avoir fait, il y a quelques années, une migration de db2 9.5 linux vers oracle 11g linux, j'ai trouvé l'optimiseur db2 meilleur.
Mais, l'utilisation des hints avec oracle permet de compenser.

Et pour ma culture perso, comment est calculé le cout des licences (celle par core) sql server. Cout d'acquisition la premiere année (prix public d'une enterprise : 7k/core), et maintenance les années suivantes ?
23/01/2018, 19h14
Waldar

Citation:

Envoyé par SQLpro

Il y a beaucoup d'autres exemples ou SQL Server obtient des performances très supérieures à Oracle. Ce qui pèche chez Oracle c'est son optimiseur qu'il faut sans arrêt bricoler pour avoir des performances justes acceptable, alors que sous SQL Server il est rare de devoir rajouter des "hint"...

Déjà séparons les besoins OLTP / R-OLAP. Les exemples dont je parle ci-dessous sont du vécu sur les versions Oracle 11gR2 et SQL-Server 2008 R2 SP2 (je ne sais plus, c'était en 2013-2014).

Côté OLTP, les deux optimiseurs sont excellents du moment que la base est bien modélisée et indexée.
Si vous avez beaucoup (plus de 100 agents qui lancent chacun un 100aine de requêtes par seconde) de concurrence, ça commence à sentir pas très bon pour SQL-Server. Vous avez le choix entre des verrous de lecture à chaque requête (si vous venez d'Oracle, constater qu'un select pose un verrou bloquant c'est surprenant), ou bien des dirty read (et de surcroît il y a un bug sur les dirty read où parfois ça génère un doublon, même en lecture sur une table avec une PK).
Dans un grand site de vente en ligne qui tourne, ils ont opté pour les dirty read, non pas par amour mais parce que les autres modes d'isolation ne font pas le job, soit à cause des verrous soit à cause des performances.
Le comité exécutif sait que tous ses reportings de vente a un marge d'erreur d'environ 1%.
Donc oui pour revenir aux hints, l'utilisation des dirty read se faisait en précisant à chaque appel de vue / table dans tous les scripts, fonctions et procédures, un petit (read uncommitted) systématique. Ça fait pas mal de rajouts de hint in fine.

Côté R-OLAP, l'optimiseur d'Oracle va commencer à pêcher sur des requêtes de plusieurs milliers de lignes (la requête, pas le contenu des tables).
SQL-Server est très vite à la ramasse. Les jointures avec beaucoup de colonnes ont des performances moins bonnes qu'en calculant un hash de toutes les colonnes, en gardant à l'esprit les problèmes inhérents aux hashs.

Les requêtes avec beaucoup de niveaux, idem SQL-Server est poussif.
En général sur Oracle on lance une grosse requête, là où sur SQL-Server il vaut mieux créer plein de tables temporaires pour stocker les résultats intermédiaires, justement pour palier la faiblesse de l'optimiseur de SQL-Server.
Alors oui, on met des hints sur Oracle pour changer ci ou ça, mais y'a pas photo au final, on bricole moins à écrire quelques hints qu'à réécrire tout un traitement.

Maintenant, les deux bases sont quand même très robustes et en général si on a l'une ou l'autre ça ne vaut pas le coup de migrer pour celle d'en face, sauf usage bien précis (typiquement, les DWH sur SQL-Server, c'est mauvais).

Au bilan de cette prose, j'ai mis beaucoup de choses sans preuve à l'appui, c'est du retour d'expérience personnelle sans métrique derrière, je n'ai pas le courage d'installer tout ce qu'il faut pour aller faire des comparaisons reproductibles.
Peut-être que quelqu'un dira tout le contraire.
24/01/2018, 11h04
SQLpro

Citation:

Envoyé par Waldar

...de surcroît il y a un bug sur les dirty read où parfois ça génère un doublon, même en lecture sur une table avec une P).

Ce n'est pas un bug, c'est un comportement normal de la lecture sale...

Citation:

Envoyé par Waldar

Dans un grand site de vente en ligne qui tourne, ils ont opté pour les dirty read, non pas par amour mais parce que les autres modes d'isolation ne font pas le job, soit à cause des verrous soit à cause des performances.

Je dirais que c'est souvent par incompétence, car ils peuvent faire du verrou optimiste avec le niveau d'isolation SNAPSHOT. Cependant pour faire des camembert statistique une marge d'erreur de 2% ne sera pas visible...

Citation:

Envoyé par Waldar

Donc oui pour revenir aux hints, l'utilisation des dirty read se faisait en précisant à chaque appel de vue / table dans tous les scripts, fonctions et procédures, un petit (read uncommitted) systématique. Ça fait pas mal de rajouts de hint in fine.

La encore incompétence, car il n'est pas nécessaire de rajouter cela dans la requête. À mon sens le SQL des requêtes ne devrait JAMAIS être touché par le rajout des options physiques. Cela peut être fait :
1) en optant pour le niveau d'isolation READ UNCOMMITTED soit dans le batch qui lance la requête, soit dans la connexion.
2) en interceptant la requête dans le serveur SQL avant exécution et en rajoutant dynamiquement le hint à la volée (guide plan de requête).

Citation:

Côté R-OLAP, l'optimiseur d'Oracle va commencer à pêcher sur des requêtes de plusieurs milliers de lignes (la requête, pas le contenu des tables).
SQL-Server est très vite à la ramasse. Les jointures avec beaucoup de colonnes ont des performances moins bonnes qu'en calculant un hash de toutes les colonnes, en gardant à l'esprit les problèmes inhérents aux hashs.

Les requêtes avec beaucoup de niveaux, idem SQL-Server est poussif.
En général sur Oracle on lance une grosse requête, là où sur SQL-Server il vaut mieux créer plein de tables temporaires pour stocker les résultats intermédiaires, justement pour palier la faiblesse de l'optimiseur de SQL-Server.
Alors oui, on met des hints sur Oracle pour changer ci ou ça, mais y'a pas photo au final, on bricole moins à écrire quelques hints qu'à réécrire tout un traitement.

Maintenant, les deux bases sont quand même très robustes et en général si on a l'une ou l'autre ça ne vaut pas le coup de migrer pour celle d'en face, sauf usage bien précis (typiquement, les DWH sur SQL-Server, c'est mauvais).

Au bilan de cette prose, j'ai mis beaucoup de choses sans preuve à l'appui, c'est du retour d'expérience personnelle sans métrique derrière, je n'ai pas le courage d'installer tout ce qu'il faut pour aller faire des comparaisons reproductibles.
Peut-être que quelqu'un dira tout le contraire.

Moi j'ai l'expérience inverse, notamment avec les gens qui fuient Oracle et constate que SQL Server consomme moins de ressources et pour les grosses requêtes s'en tire incomparablement plus vite... Mais peut être n'as tu pas travaillé avec les versions récentes... pour information de grosses différences ont eut lieu avec les version 2012 et 2014. Sans parler des améliorations des version 2016 et 2017....

A +