IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 ?

Le , par Michael Guilloux

1.1KPARTAGES

12  0 
Quels étaient vos SGBD préférés en 2017 (tous modèles confondus) ?
PostgreSQL
41 %
SQL Server
37 %
SQLite
15 %
MySQL et autres dérivés
15 %
MariaDB
10 %
Firebird
7 %
MongoDB
5 %
Oracle
5 %
MS Access
2 %
DB2
2 %
Autre (à préciser)
0 %
Cassandra
0 %
Sybase
0 %
Pas d'avis
0 %
Voter 41 votants
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. »


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.


Sources : Blog DB-Engines, DB-Engines Ranking

Et vous ?

Que pensez-vous de ce classement ?
Quels ont été vos SGBD préférés en 2017 ? Selon quels critères ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de escartefigue
Modérateur https://www.developpez.com
Le 03/01/2018 à 15:36
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
3  0 
Avatar de vanquish
Membre chevronné https://www.developpez.com
Le 03/01/2018 à 11:26
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é.
2  0 
Avatar de one_eye
Futur Membre du Club https://www.developpez.com
Le 03/01/2018 à 15:14
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.
2  0 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 23/01/2018 à 19:14
Citation Envoyé par SQLpro Voir le message
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.
2  0 
Avatar de RaphAstronome
Membre actif https://www.developpez.com
Le 03/01/2018 à 16:33
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 . 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).
1  0 
Avatar de UndeadangerousK
Membre habitué https://www.developpez.com
Le 03/01/2018 à 12:39
Citation Envoyé par vanquish Voir le message


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.
0  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 07/01/2018 à 9:26
Citation Envoyé par abriotde Voir le message
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 +
0  0 
Avatar de one_eye
Futur Membre du Club https://www.developpez.com
Le 12/01/2018 à 17:21
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.
0  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 17/01/2018 à 22:12
Citation Envoyé par one_eye Voir le message
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 +
0  0 
Avatar de one_eye
Futur Membre du Club https://www.developpez.com
Le 23/01/2018 à 16:37
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 ?
0  0