Discussion :

[SofEvans]

Si SQL Server est vraiment plus performant que PostgreSQL, qui après tout est possible, pourquoi notre ami SQLpro biaise-t-il ses benchmarks en exécutant PostgreSQL sous Windows alors qu'il est parfaitement admis que la version Windows est bien plus lente que la version Linux ?

C'est dit avant FatAgnus :

C'est le B A BA de savoir qu'un SGBDR possède un fonctionnement particulier.
Ce fonctionnement peut, par exemple, être incompatible avec la plupart des autres applications et même avec une autre instance du même SGBDR (rapport au fait de la concurrence d'accès).
Ce fonctionnement peut aussi, par exemple, être fortement dépendant du matériel et de l'OS sur lequel il s’exécute.

Ceux ne comprenant pas ces principe prouvent que leurs savoir sur ce sujet est d'une intense vacuité.

(oh wait !)

[SQLpro]

...
Sur les serveurs Web c'est toujours largement Linux et Mysql (parfois PostgreSQL) qui prédomine largement.

En nombre de site oui, en volume non. Aucun grand site marchand n'utilise du MySQL vu ses limitations. Pour information, les plus gros sites web marchand en France utilisent tous MS SQL Server (CDiscount, Fnac.com, OOshop, SARENZA, Veppee, LDLC...)

... PostgreSQL fonctionnera certainement plus vite sous Linux que sous Windows comme l'affirme Magnus Hagander

J'aime beaucoup les affirmation étayées sur aucun test ni aucun benchmark... Des preuves ! Soyez assez intelligent pour éviter de propager des racontars et publiez des tests !

Aux dernière nouvelles que j'avais, la "limite physique" de données qu'une instance des meilleurs SGBDR considérée 5To, ceci a cause des contraintes impliquant l'utilisation d'un SGBD relation (ACID).....

Votre méconnaissance est importante... Pour information, une des plus grosse base de données du monde est sur MS SQL Server après plusieurs Po (péta octets) c'est a dire plusieurs milliers de To... Et cela ne date pas d'aujourd'hui, mais de plus de 10 ans...
Pann Starrs :
https://fr.wikipedia.org/wiki/Pan-STARRS

Pour votre information également CDsocunt c'est plusieurs dizaine de To depuis près de 10 ans... Comme Fnac.com ou ventes privées devenu Vepee.

Donc, mettez vos connaissance à jour avant d'affirmer de telle idioties !

A +

[Invité]

Les éditeurs de solutions SIG laissent rarement le choix du SGBD à utiliser. Comparer PostGIS à SQL Server Spatial avec des benchmark en est d'autant plus inepte.

[Mat.M]

Je serais curieux d'avoir ces référence de bases de données de plusieurs To. En effet je n'en n'ai jamais vu une seule fonctionner... Malgré de très nombreux audits d'entreprise....

c'est pour cette raison que les infrastructures comme Azure ou AWS sur le Cloud se développent

Donc le benchmark de notre ami SQLpro est malheureusement sans intérêt, à part si comme notre ami SQLpro on s'est donné comme mission de faire de la propagande SQL Server au détriment des bases de données open source.

votre vision des choses c'était valable il y a quelques années auparavant.
Maintenant elle est devenue obsolète.
Le problème lorsqu'on veut crée un système informatique avec gestion de données c'est pas à savoir s'il faut prendre de l'open-source ou pas
Le problème c'est la montée en charge du système d'information bref la scalabilité du système d'information.
Et même MySQL propose une solution sur le Cloud évidemment payante...

[walfrat]

Votre méconnaissance est importante... Pour information, une des plus grosse base de données du monde est sur MS SQL Server après plusieurs Po (péta octets) c'est a dire plusieurs milliers de To... Et cela ne date pas d'aujourd'hui, mais de plus de 10 ans...
Pann Starrs :
https://fr.wikipedia.org/wiki/Pan-STARRS

Pour votre information également CDsocunt c'est plusieurs dizaine de To depuis près de 10 ans... Comme Fnac.com ou ventes privées devenu Vepee.

Donc, mettez vos connaissance à jour avant d'affirmer de telle idioties !

A +

le problème c'est que je n'ai plus l'affirmation en tête vu que ça fait longtemps, mais je l'ai très mal tourné c'est sur.

Evidemment il ne s'agit pas de 5To qu'on peut juste remplir avec des énormes volumes de données binaires., une image satellite de ce qu'on prend pour la Terre, ça pèse déjà plusieurs gigas à elle seule .

1,4 téraoctet d'images sont produites chaque nuit par Pan-STARRS et les données astronomiques sont stockés dans un système de base de données relationnelle Microsoft SQL Server 2008 sous Windows organisé en cluster à 12 nœuds comprenant 100 To de données

100/12 = 8To/instance. + les images évidemment.

En outre il s'agissait d'une estimation que les SGBDR pouvait gérer en général de 5TO sur une seule instance, en customisant la base pour des besoins spécifiques, et en séparant les données sur des instances séparés, bien sur qu'on peut aller plus loin et que c'est déjà fait, ou aussi en utilisant la base de telle façon qu'il y a extrêment peu de concurrence sur les enregistrement, mises à jour d'index etc.

En 2008, 300 To de données figurait dans la base de Pan-STARRS.

Je précise, j'ai bien vu ça, mais sans trop de précision je ne sais pas si c'est toujours sur 12 noeuds ou si'l y a une contradiction avec ce qui était dit dessus, toujours que 300/12 =>25To, on est pas non plus si loin de ça des 5To que j'avais cité (en termes d'ordre de grandeur).

C'est juste que pour moi, 5To, c'est déjà un bon repère pour savoir quand tu rentres vraiment dans le hard de ce que peuvent faire les SGBD les plus costaud, surtout quand quelqu'un met qu'il peut faire du MysQL sans DBA avec des centaines de terras.

[SQLpro]

... Le problème c'est la montée en charge du système d'information bref la scalabilité du système d'information.
Et même MySQL propose une solution sur le Cloud évidemment payante...

Mais le cloud n'est pas la solution de scalabilité des RDBMS ! Les solutions de montée en charge (volume, concurrence...) des SGBDR sont internes... Exemple avec Oracle RAC ou SQL Server avec AlwaysOn et les Distributed Partitionned Views (DPV).

A +

[kedare]

MS SQL server a une philosophie totalement à l'opposée. Le logiciel fonctionne mieux s'il tourne seul sur un serveur.

C'est le cas de toutes les bases de données.

SQL Server est très simple a "contenir" dans les ressources qui luis sont allouées, tu peux lui attribuer que certains cores et lui limiter sa mémoire utilisable très simplement.

[vanquish]

Ajouté à cela, le logiciel est longtemps resté librement distribuable.

En réalité, la licence mySQL ne permet pas un déploiement aussi libre que cela.
Bien sur je peux le mettre sur mon serveur en téléchargement gratuit à coté d'autres logiciels libres.
Je peux en installer autant d’instances que je veux en interne dans ma structure.

Mais beaucoup de distributions violent la licence qui a une vue très restrictive du GPL, puisque MySQL considère que si vous distribuez votre application en même temps que MySQL et que votre application nécessite MySQL, alors votre application et MySQL forment un tout dont l'ensemble doit être GPL.

Cela ne date pas d'Oracle. Cela avait déjà posé un problème pour le bundle LAMP puisque le les 4 produits (Linux/Apache/MySQL/Php) n'étaient pas tous sous GPL.
La version community a toujours été un produit d'appel pour la version purement commerciale.

Beaucoup de petits éditeurs considèrent MySQL/MariaDB comme un produit gratuit qu'ils peuvent distribuer gratuitement avec leur application, mais ils ont tord (à moins que leur application soit 100% GPL).

Le rachat d'Oracle a fait passer la licence commerciale de 500€/perpétuel à 5000€/an, mais la philosophie a toujours été la même et s'est inévitablement propagée au fork MariaDB.

Je distribuais très régulièrement des licences commerciales de mySQL. Après le rachat par Oracle, je suis passé à Firebird.
Comme je ne commandais plus de licences, j'ai eu un appel téléphonique étonné d'un commercial d'Oracle qui, plus menaçant que commercial, m'a fermement rappelé les conditions de distribution de mySQL.

Je continue de considérer MariaDB comme plus performant que Firebird (même si l'écart se tasse depuis la V3), mais en terme de liberté de distribution, il n'y a pas photo : Firebird est loin devant.

[blbird]

EJe distribuais très régulièrement des licences commerciales de mySQL. Après le rachat par Oracle, je suis passé à Firebird.
Comme je ne commandais plus de licences, j'ai eu un appel téléphonique étonné d'un commercial d'Oracle qui, plus menaçant que commercial, m'a fermement rappelé les conditions de distribution de mySQL.

Oracle est une véritable plaie en termes de licences, agressifs et absolument pas compréhensifs. A bannir autant que possible de tout S.I.

[Christ D]

MySQL : une source d'ennui sans fin :
- utilisée à tort et à travers y compris pour de toutes petites bases de données alors que le serveur est une usine à gaz sans nom.
- une psychose de la sécurité qui rend l'installation de plus en plus longue et difficile (évidement vu que les utilisateurs ont pris pour habitude de connecter leur site à leur base en utilisant le owner de la base, qui a tous les droits dessus, y compris de la dropper !)
- la possibilité de compiler une procédure stockée exécutant une requête dont une colonne ou une table n'existe pas !
- la possibilité de dropper un objet alors qu'il reste utilisé dans le code !!!! (Ex : drop de table alors que des procédures l'utilisent) !
- Ce n'est que depuis peu que MySQL gère les procédures stockées !
- changez de version et votre code ne fonctionne plus ! C'est tellement vrai que beaucoup utilisent encore MySQL 5.6 !!!!
(changement de code SQL dans les procédures stockées, déprécation de charset , changement de syntaxe de LOAD DATE, interdiction de chargement de fichier par défaut !!!!!! etc.....)
- comment est-il possible de faire un SGBDR qui, lorsqu'on créer une clé étrangère, ne génère pas l'indexe en même temps ?
- comment est-il possible que MySQL ne sache toujours pas gérer les clés étrangères a plusieurs colonnes ? Impossible d'exploiter des clés naturelles, on en revient toujours aux auto-incréments.

Et avez vous vu une seul fois WorkBench fonctionner sans bug gênant ?

La durée de restauration d'une base MySQL est aussi déconcertante (4h pour restaurer une base dont le backup fait 300Mo sur un serveur de dev avec disque en SSD avec un intel i7 et 16Go de RAM).
La restauration d'un backup de 300Mo sur Firebird (190 tables, 160 procédures stockées) sur la même machine dure 1 minute ! Certe, le format de backup n'est pas le même.

Dans l'ordre de mes préférences des SGBDR open source, selon les cas :
- petite base de données sans procédures stockées ni gestion des droits ==> sqlite
- une base avec procédures stockées, fonctions internes, gestion des droits, bonnes performances et exigeant relativement peu de connexions simultanées == > Firebird !
- besoin de plus ? ==> PostGresql

MySQL = ni fait, ni à faire.

[01001111]

Comme il a été dit dans certains des commentaires, MySQL est plutôt performant sur des requêtes simples...
Un des problèmes qui peuvent survenir, c'est par exemple, sur des tables avec de relativement nombreuses entrées, d'utiliser les vues avec des définitions d'algorithmes en interne.
J'ai récemment optimisé une vue qui se construisait sur un table de "seulement" 33k entrées, et qui mettait 42 secondes à se construire (je n'ai pas programmé cette horreur), en remplaçant cette vue par une table réelle construite à partir d'un script php/mysql qui a mis moins d'une seconde à s'exécuter la première fois et se met à jour toutes les heures en moins de 50ms, j'obtiens le même résultat que la vue...

Le tout est donc d'utiliser MySQL dans ce qu'il sait faire au mieux, à savoir des choses simples. Lui adjoindre un second langage pour les choses complexes est chose requise.

[Pierre Fauconnier]

[...]
Le tout est donc d'utiliser MySQL dans ce qu'il sait faire au mieux, à savoir des choses simples. Lui adjoindre un second langage pour les choses complexes est chose requise.

Comme toujours, utiliser le bon outil en fonction du besoin et des compétences techniques de qui met l'outil en place.

[Xavier_d]

POSTGRES est définitivement plus qu'une alternative à Oracle ou SQLServer, n'en déplaise à certains DBA frileux ou adeptes du clickodrome qui le trouvent "ennuyeux".
Au contraire, et c'est même sans doute là que l'on reconnait les vrais professionnels, hihihi.
Soulignons que la question de la performance comparée ORACLE/PostGresql n'est digne que des commerciaux du premier et un faux débat à une époque où le prix de la licence Oracle équivaut à celui d'une batterie de machines physiques hébergeant une armée de machines virtuelles.
Un DBA (et j'en suis depuis ORACLE V4 en 1985) arrivera toujours à faire marcher un SGBD, surtout s'il sait (faire) paralléliser et utiliser les ressources matérielles contemporaines citées ci-dessus.
Notons que le mode de gestion de la mémoire cache de PostGres partageant le cache de fichiers système impose une machine virtuelle dédiée à chaque instance, ce qui est décidément le sens de l'histoire.
Tout ce qui précède est valide dans un contexte sérieux : bases de plusieurs (dizaines de) To, contenant des tables partitionnées de plusieurs milliards d'enregistrements et avec un taux d'insertion dépassant 1000 enrts/s.
Et c'est précisément là que PostGres n'est pas du tout ennuyeux, et permet de déchainer sa créativité, à la différence d'Oracle où il faut sans cesse aller voir son chef ou son client pour une improbable extension de licence de ceci ou de celà.
Sinon, plus petit, il y a ce que vous préférez à un moment donné, et ce pourra être n'importe quoi : Mysql (qui appartient à Oracle), MariaDB, Access (oui, oui, qui peut s'avérer très amusant), Sqllite...
En revanche, migrer soi-même d'Oracle à PostGresql peut être une galère, mais ça existe, des sociétés spécialisées le font assez bien.
Il faut donc faire virer leur cuti aux développeurs (mais yapa la fonction COUNT(*) ?) et aux DBA (zone de confort, invitation aux grand-messes Oracle annuelles) AVANT la conception du projet.
Terminons en précisant justement que sur un site important, le coût de licence/maintenance d'Oracle peut représenter le salaire de plusieurs ingénieurs.
Alors autant payer des salaires à des jeunes (ou pas) en France qu'enrichir Larry Ellison, non ?

[JefGDev]

Pour avoir utilisé les 3 (ainsi qu'Oracle, mais sous la torture du client), pour mon utilisation, PostgreSQL était souvent le meilleur. SQL Server était rarement un choix potentiel avec des serveurs presque exclusivement sous Linux depuis plus de 15 ans, et ne servait que de repoussoir pour faire baisser les montants des licences Oracle (si vous voulez une réduction, annoncez au commercial Oracle que c'est trop cher et que vous préférez SQL Server du fait du prix des licences).

[vanquish]

MySQL : une source d'ennui sans fin.

Je n'ai pas du tout la même expérience.
Comme je l'ai écrit ailleurs, je suis passé de mySQL à Firebird, mais pas à cause du logiciel.

J'ai toujours des dizaines d'instances et je n'en entend jamais parler.
Les dump sont au dessus du Go et ne mettent pas 4h pour être remonté, loin de de là.

Un dump 1,5 Go sur mon ordi portable SSD, trop vieux pour avoir droit à W11, ça se remonte en 20 min maxi.
Alors 4h pour 300 Mo, je ne pige pas.

De plus, pour InnoDB (le moteur que j'utilise systématiquement) il a toujours existé un backup binaire à chaud (et transactionnel).
Je l'achetais moins de 400€ directement auprès de InnoDB avant le rachat par Oracle.

Percona en a fait une version open-source que MariaDB intégre à sa version community.
(Le binaire Percona n'est dispo que sur Linux, mais le binaire MariaDB est aussi dispo sous Windows)

Avec ce système, remonter une base c'est faire un xcopy.
Difficile de faire plus rapide.
Le seul soucis c'est que cela backup toute l'instance (et pas seulement une base).

J'ai eu bien plus de problème avec Firebird.
Avec les version antérieur à la 3, on pouvait se retrouver avec une base qu'il était possible de sauvegarder, mais dont la sauvegarde ne pouvais être remonté à cause de soucis d'intégrité référentielle ou de valeur de champ date incohérente. Mes recherches sur internet m'ont montré que je n'étais pas tout seul.
Des sauvegardes sur lesquelles on ne peut pas compter, ce n'est pas des sauvegardes.

[SQLpro]

Quelques exemples de manques de MySQL face à SQL Server :

• Pas de cache des plans d'exécution des requêtes
• Pas de parallélisme d'exécution des requêtes
• Aucun autre algorithme de jointure que la boucle imbriquée qui est l'algorithme le plus lent
• Inconsistance de la clause GROUP BY
• Pas de tables In Memory
• Pas d'index verticaux (columstore)
• Pas d'indexation du XML
• Pas de tables de graphe ni le langage (GQL : Graph Query Language) qui va avec
• Pas de "big table" (SQL Server peut monter jusqu'à 30 000 colonnes)
• Pas de compression des données des tables et index
• Pas de table de type paire clé / valeur comme Redis
• Pas de datalink (norme SQL) comme le FILESTREAM de SQL Server

...

[walfrat]

Je suis pas le seul à ne pas être à jour : https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html (MySQL 8.0.20 (2020-04-27, General Availability) )

En outre que MySQL ne peut pas gérer des tables à 30k colonnes, sérieusement on s'en fou.

C'est pas la faute de MySQL si des gens veulent l'utiliser pour gérer des centaines de millions de données alors qu'il n'a jamais été développé dans cet esprit ni n'a jamais eu les moyens de le faire comme SQL Server.

Tu casses juste du sucre gratuitement sur MySQL plutôt que sur les personnes qui le choisissent, c'est pas vraiment pro tout ça.

[SQLpro]

Je suis pas le seul à ne pas être à jour : https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html (MySQL 8.0.20 (2020-04-27, General Availability) )...

Extrait de la doc Oracle :
Beginning with MySQL 8.0.18, MySQL employs a hash join for any query for which each join has an equi-join condition, and in which there are no indexes that can be applied to any join conditions, such as this one:
Ce qui limite considérablement la chose....

Comme si on disait, vous pouvez prendre des pneu neige, uniquement s'il neige et fait entre 0 et -3 degré avec un vent latéral de moins de 30 km/h.... !

A +

[SQLpro]

...
Sur les serveurs Web c'est toujours largement Linux et Mysql (parfois PostgreSQL) qui prédomine largement.

Pour ton information 80% des gros site web marchand français sont sous SQL Server :

• fnac.com
• cdiscount
• vepee (ex ventre privées)
• sarenza
• salendo
• ...

A +

[Pierre Fauconnier]

Ce qui est bien, avec les stats, c'est qu'elles ne veulent rien dire.....

80% (j'attends les chiffres) des "gros sites" (c'est quoi un gros site), puis tu en cites 5, les ... étant un effet rhétorique laissant croire qu'il y en a beaucoup plus.

Bref, de la daube!