SQLpro

Sujet intéressant. Dans les SGBD commerciaux en sus de SQL Server, il y a aussi une solution connue coté Oracle, mais c'est couteux.
Du coté des solutions pour les radins c'est possible aussi de trouver des solutions MySQL en cluster, et il y a aussi des sociétés qui proposent des solutions en sus pour se faire, et MariaDB a aussi son offre la dessus.

Sinon il y a des offres de SGBD en cloud avec ce genre d'options, mais le cout peut être parfois prohibitif, et il y a toujours la peur de se faire hacker, fautes de compétences utiles c'est parfois très mal sécurisé, voir pas du tout et la c'est le drame, exemple : Un million d'enregistrements de clients exposés via une instance Elasticsearch, y compris les détails des utilisateurs.

Bonjour,

sujet intéressant en effet mais je pense que le titre n'est pas très approprié. Une fois qu'on a lu ce billet on se serait plus attendu à un titre du genre "Pourquoi Microsoft SQL Server est meilleur que PostGreSQL ?"

Et promis je ne remets absolument pas en doute l'objectivité de l'auteur.

La comparaison est bien ... mais sur quel OS ?
Parce que les 2 sont disponibles sur Linux et Windows, et ce n'est pas le même cirque ...
Et surtout pourquoi toutes les références à PG parlent de 2013 ou 2014, ce qui fait une décennie tout de même, quand SQL Server a le droit a des mentions des dernières versions ?

Je pose candidement la question, parce l'entreprise dans laquelle je travaille propose un produit leader dans le segment des grand clients (plus de 2 000 employés, on a un client à plus de 40 000), possède une base de donnée de plus de 200 tables avant module complémentaires, a certaines table qui ont jusqu'à 20 enregistrements par jour par employé, nous maintenons pour pas mal de client un historique de 2 ans en base.
Et les benchmark de 2024 que l'on fait entre SQL Server sur Windows (son supposé OS de prédilection) et PostGre SQL sur Linux montrent qu'il n'y a pas photo.
On vend le produit à des groupe du Cac40, ils prennent le PostGre gratuit sans support extérieur et s'en tire très bien ...
Et pour des raisons de coût et de problème récurrent sur d'autre logiciel des client, on aide à migrer sur PostGre ...

J'ai personnellement utilisé SQL Server de 2012 à 2016 en parallèle de PG, MariaDB, SQL Lite et SQL Server CE, que ce soit pour une association d’utilité publique, ou personnellement.
Mais aujourd'hui, pour des raisons de ratio Productivité/Coût, à moins d'être dans le cloud Azure, pourquoi j'irai utiliser SQL Server ?

C'est toujours un article intéressant qui a le mérite de mettre en lumière un débat sur la manière de stocker ses données et y accéder.
Mais même les articles de comparaison de langages ont des benchmark clair et tangible, qui permettent d'y voir plus clair ...

Merci tout de même pour billet et passez une excellente journée !

Envoyé par MagnusMoi

La comparaison est bien ... mais sur quel OS ?

Effectivement cela n'est pas dit d'emblée, mais c'est bien sur Windows...

Envoyé par MagnusMoi

... certaines table qui ont jusqu'à 20 enregistrements par jour par employé, nous maintenons pour pas mal de client un historique de 2 ans en base.

Donc au pire 584 millions de lignes dans la table de votre client avec ses 40 000 employés... C'est pas mal, mais c'est peanuts avec SQL Server et un index columnstore dont l'unité minimale de stockage est de 1 million de lignes...
Bref pour lire la table séquentiellement il faut à SQL Server 584 lecture là ou PostGreSQL va faire 18 millions de lectures (=>136 Go si les lignes font en moyenne 250 octets... et PostGreSQL ne pratique pas la compression...)...
Je doute plus que fortement que le temps de réponse soit équivalent... je miserait sur 100 fois plus lent au minimum, d'autant que PostGreSQL ne sait toujours pas paralléliser toutes les opérations d'un plan de requête...

A +

Envoyé par MagnusMoi

...
Et les benchmark de 2024 que l'on fait entre SQL Server sur Windows (son supposé OS de prédilection) et PostGre SQL sur Linux montrent qu'il n'y a pas photo.
...

Pourrais tu me donner les informations sur le benchmarks de performance effectués entre SQL Server et PostGreSQL ? Parce que c'est facile d'affirmer, mais difficile de vérifier...
Pour ma part tous les benchmarks que j'ai effectué entre les deux montrent que SQL Server bat à plate couture PostGreSQL.
Quelques exemples de benchmarks reproductible :

PostGreSQL vs Microsoft SQL Server (comparaison) – Partie 1 : performances des commandes pour le DBA
Montre que les performances des commandes de :

• chargement de fichier sont 5 fois plus lentes avec PostGreSQL qu'avec SQL Server
• création d'index sont 14 fois plus lente avec PostGreSQL qu'avec SQL Server
• maintenance d'index sont 32 fois plus lents avec PostGreSQL qu'avec SQL Server
• maintenance des statistiques sont 10 fois plus lentes avec PostGreSQL qu'avec SQL Server

PostGreSQL vs Microsoft SQL Server (comparaison) – Partie 2 : performances des requêtes avec COUNT
Montre que les performances des requêtes d'agrégation sont :

• pour le COUNT DISTINCT : SQL Server est entre 61 et 561 fois plus rapide que PostGreSQL dans toutes les situations, et avec l’indexation verticale (columnstore index) SQL Server est 1 533 fois plus rapide que PostGreSQL
• pour le simple COUNT PostGreSQL se révèle entre 4 et 429 fois plus lent que SQL Server

Globalement PostGreSQL est 114 fois plus lent que SQL Server sur le COUNT...

À titre d'exemple complémentaire, voici les performances entre PostGreSQL et SQL Server pour l'INSERT de 4 000 000 (4 millions de lignes) dans une table :

Script pour MS SQL Server :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
CREATE DATABASE DB_TEST;
GO

USE DB_TEST;
GO

CREATE TABLE T (K INT IDENTITY PRIMARY KEY,
	           DATA   VARCHAR(32));

INSERT INTO T (DATA) VALUES 
('Tribui autem sed ego memineram m'),
('hi in mihi credo si pueris pueri'),
('et nec sed tantum videris credo '),
('aulum nec quod ut in ut Quo aut '),
('ec de nemo amice fuit autem trib'),
('i autem Catone pueris aut nec mo'),
('tem omittam videris modo fuit se'),
(',t pueris tribui recte non quide'),
('Quo Cato si recte mihi Paulum hi'),
('non iudicas pueris mortem Fanni '),
('lle et quantum facis quantum Fan'),
('i spectato ut credo recte recte '),
('lle filii recte mihi nec omittam'),
('Cato modo Catone tulit sed fuit '),
('uod quidem quod ille sed in aut '),
('ostulo nec credo mihi perfecto u');

SET STATISTICS TIME ON;

INSERT INTO T (DATA)
SELECT SUBSTRING(CONCAT(SUBSTRING(T1.DATA, 1, (ABS(CHECKSUM(NEWID()) % 32))), 
	                    REVERSE(SUBSTRING(REVERSE(T2.DATA), 1, (ABS(CHECKSUM(NEWID()) % 32))))), 1, 32)  
FROM   T AS T1
       CROSS JOIN T AS T2
ORDER BY CHECKSUM(NEWID()) OFFSET 0 ROW FETCH NEXT 4000000 ROWS ONLY;
--> Temps UC = 0*ms, temps écoulé = 2*ms.

INSERT INTO T (DATA)
SELECT SUBSTRING(CONCAT(SUBSTRING(T1.DATA, 1, (ABS(CHECKSUM(NEWID()) % 32))), 
	                    REVERSE(SUBSTRING(REVERSE(T2.DATA), 1, (ABS(CHECKSUM(NEWID()) % 32))))), 1, 32)  
FROM   T AS T1
       CROSS JOIN T AS T2
ORDER BY CHECKSUM(NEWID()) OFFSET 0 ROW FETCH NEXT 4000000 ROWS ONLY;
--> Temps UC = 265*ms, temps écoulé = 289*ms

Test d'insertion de 4 millions de lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
INSERT INTO T (DATA)
SELECT SUBSTRING(CONCAT(SUBSTRING(T1.DATA, 1, (ABS(CHECKSUM(NEWID()) % 32))), 
	                    REVERSE(SUBSTRING(REVERSE(T2.DATA), 1, (ABS(CHECKSUM(NEWID()) % 32))))), 1, 32)  
FROM   T AS T1
       CROSS JOIN T AS T2
ORDER BY CHECKSUM(NEWID()) OFFSET 0 ROW FETCH NEXT 4000000 ROWS ONLY;

Le temps de cette commande a été de :
Au niveau UC = 694 5947
Au niveau chrono = 484 355*ms.
NOTA : SQL Server a utilisé 16 cœurs pour paralléliser cette requête (sur une machine comptant 72 coeurs et pour une installation "out of the box")

Script équivalent pour PostGreSQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
ALTER SYSTEM SET
 shared_buffers = '128GB';
ALTER SYSTEM SET
 effective_cache_size = '384GB';
ALTER SYSTEM SET
 maintenance_work_mem = '2047MB';
ALTER SYSTEM SET
 checkpoint_completion_target = '0.9';
ALTER SYSTEM SET
 wal_buffers = '16MB';
ALTER SYSTEM SET
 default_statistics_target = '100';
ALTER SYSTEM SET
 random_page_cost = '1.1';
ALTER SYSTEM SET
 work_mem = '338933kB';
ALTER SYSTEM SET
 huge_pages = 'try';
ALTER SYSTEM SET
 min_wal_size = '2GB';
ALTER SYSTEM SET
 max_wal_size = '8GB';
ALTER SYSTEM SET
 max_worker_processes = '72';
ALTER SYSTEM SET
 max_parallel_workers_per_gather = '4';
ALTER SYSTEM SET
 max_parallel_workers = '72';
ALTER SYSTEM SET
 max_parallel_maintenance_workers = '4';
SELECT pg_reload_conf();

CREATE TABLE T (K INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
	           DATA   VARCHAR(32))

INSERT INTO T (DATA) VALUES 
('Tribui autem sed ego memineram m'),
('hi in mihi credo si pueris pueri'),
('et nec sed tantum videris credo '),
('aulum nec quod ut in ut Quo aut '),
('ec de nemo amice fuit autem trib'),
('i autem Catone pueris aut nec mo'),
('tem omittam videris modo fuit se'),
(',t pueris tribui recte non quide'),
('Quo Cato si recte mihi Paulum hi'),
('non iudicas pueris mortem Fanni '),
('lle et quantum facis quantum Fan'),
('i spectato ut credo recte recte '),
('lle filii recte mihi nec omittam'),
('Cato modo Catone tulit sed fuit '),
('uod quidem quod ille sed in aut '),
('ostulo nec credo mihi perfecto u');

INSERT INTO T (DATA)
SELECT SUBSTRING(CONCAT(SUBSTRING(T1.DATA, 1, CAST((RANDOM() * 32) AS INT)), 
	                    REVERSE(SUBSTRING(REVERSE(T2.DATA), 1, CAST((RANDOM() * 32) AS INT)))), 1, 32)  
FROM   T AS T1
       CROSS JOIN T AS T2
ORDER BY RANDOM() OFFSET 0 ROW FETCH NEXT 4000000 ROWS ONLY;
--> Query returned successfully in 87 msec

INSERT INTO T (DATA)
SELECT SUBSTRING(CONCAT(SUBSTRING(T1.DATA, 1, CAST((RANDOM() * 32) AS INT)), 
	                    REVERSE(SUBSTRING(REVERSE(T2.DATA), 1, CAST((RANDOM() * 32) AS INT)))), 1, 32)  
FROM   T AS T1
       CROSS JOIN T AS T2
ORDER BY RANDOM() OFFSET 0 ROW FETCH NEXT 4000000 ROWS ONLY;
--> Query returned successfully in 412 msec.

Pour PostGreSQL nous avons fait confiance à PGTune pour paramétrer l'instance (appelé curieusement "cluster" dans le vocabulaire PostGreSQL...)

Test d'insertion de 4 millions de lignes :
Notez qu'il y a moins de fonctions dans le code de la requête PostGreSQL générant les 4 millions de lignes que dans celle de SQL Server...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
INSERT INTO T (DATA)
SELECT SUBSTRING(CONCAT(SUBSTRING(T1.DATA, 1, CAST((RANDOM() * 32) AS INT)), 
	                    REVERSE(SUBSTRING(REVERSE(T2.DATA), 1, CAST((RANDOM() * 32) AS INT)))), 1, 32)  
FROM   T AS T1
       CROSS JOIN T AS T2
ORDER BY RANDOM() OFFSET 0 ROW FETCH NEXT 4000000 ROWS ONLY;

Le temps de traitement a été de 3 h 7 m ! Soit 11*220*000 ms

Autrement dit dans ce cas de figure PostGreSQL a mis 23 fois plus de temps que SQL Server...

Bref, le jour ou on me présentera des benchmarks reproductibles montrant que PostGreSQL est au moins équivalent de SQL Server j'en ferais la promotion...

Pour information il existe un organisme recensant les bencmarks officiels (TPC.org)dans lequel on n'a jamais vu figurer PostGreSQL tellement les performance comme le TCO de PostGreSQL est lamentable...

Bref si l'on est un tantinet rationnel et surtout écologique on devrait éliminer PostGreSQL pour diminuer à la fois les coûts globaux licence comprise, mais aussi pour consommer moins d'énergie pour faire la même chose !
A +

Envoyé par SQLpro

Pourrais tu me donner les informations sur le benchmarks de performance effectués entre SQL Server et PostGreSQL ? Parce que c'est facile d'affirmer, mais difficile de vérifier...

Alors je suis bien d'accord, et je vais demander à mes collègues du benchmark dans notre entreprise si je peux avoir les tests effectués.
C'est certain que le code du logiciel je ne peux pas le fournir, mais je sais que les résultats des bench on fait que l'on garde SQL Server, que pour les clients qui veulent le garder.
Mais le Saas, comme le On Premise, c'est Linux/Postgre le combo. Et SQL Server, dans notre produit, on a essayé OLEDB et ODBC pour se connecter, mais sous windows, toutes les opérations restent plus lente que Windows/Postgre ou Linux/Postgre.
Donc le coupable pourrait être le code, et la manière de faire les opérations sous Postgre que l'on écrirai mieux que sous SQL Server, seulement pour vendre à des grands ponte ont doit continuer d'avoir des certifiés Microsoft à tous les niveaux ...

Je regarderai le lien donnée http://mssqlserver.fr/postgresql-vs-...s-pour-le-dba/ et comment on implémente dans les classes de connecteurs pour avoir une réponse plus éclairé, n'hésitez pas à me relancer si j'oublie.

En tout cas merci encore pour les retours !

Bonjour,
je me permet de faire un long commentaire.

Au contraire, SQL Server agit en amont au démarrage de la transaction : les différentes transactions sont propagées en parallèle, immédiatement sur tous les nœuds, y compris le primaire. Il en résulte que, si les machines sont équilibrées, le délai n’est que celui du transit réseau dont le seuil d’alerte est de l’ordre de 15 ms, au-delà duquel SQL Server passe transitoirement en mode asynchrone pour éviter les blocages (phase de rattrapage).

Existe-t-il un paramètre pour bloquer ce passage en asynchrone ? On peut considérer que dans certains cas d'usage avoir un délai trop long est signe "d'erreur grave". Je demande cela car je sais que l'audit sql serveur peut être en mode "on bloque si on peut plus auditer" ou laisser les opérations continuer même si l'audit n'est plus possible.

PostGreSQL ne disposant pas d’un mécanisme de quorum indépendant et au niveau système, il faut impérativement au moins 3 nœuds, c’est-à-dire trois instances de PostGreSQL pour pouvoir prétendre à un basculement automatique en mode synchrone.

Je ne suis pas tout à fait d'accord avec cette affirmation. D'abord parce que postgresql en version libre ne dispose pas du tout de mécanisme de bascule automatique! Cela va donc dépendre de la solution choisie. Par exemple, si on veut utiliser replication manager (repmgr) de 2ndquadrant (enfin EDB), il faudra effectivement 3 instances (2 avec les datas, et une 3ieme servant de témoin). Si on utilise patroni, une autre solution avec le failover automatique, on aura besoin que deux instances postgresql, cependant, pour faire le quorum/vote il faudra (choix non exhaustif): 3 instance patroni, un cluster etcd (qui peut être mutualisé, 3 nœuds mini), ou un cluster zookeeper,...
Vu que SQL Serveur intègre la fonction de HA de bout en bout, cela simplifie (je suppose car je n'ai jamais testé) sa mise en place. Alors que si on veut rester en mode full libre, il faut du PG, un produit gérant la bascule et éventuellement un autre produit pour gérer le quorum.

En comparaison SQL Server utilise le cluster Windows et un quorum (disque ou partage de fichier) pour assurer le vote majoritaire qui décide du basculement.

Un quorum basé sur un disque ou sur le partage de fichier. N'est-ce pas un peu léger/dangereux ? De même, quel est le nombre de membres dans un "cluster windows" ? Il devrait être impair, non ? Sinon la solution me parait sensible au split-brain, non ?

Bien que PostgreSQL propose un basculement automatique, celui-ci met beaucoup de temps en mode synchrone (30 secondes environ).

Comme dit précédemment, Postgresql en version libre, ne dispose pas de bascule automatique. Il faut rajouter d'autres outils (ou basculer dans une version fermée). Ou alors, j'ai raté un gros truc. En tout cas, dans les paramétrages par défauts de ces outils, c'est fixé à 30 secondes. Mais c'est un paramétrage qui peut être changé. Pour Patroni, on peut descendre à 20 secondes (https://patroni.readthedocs.io/en/la...iguration.html). Cela reste plus élevé que les millisecondes annoncées pour sqlserver.

SQL Server en comparaison ne met que quelques millisecondes…

Je serais curieux d'en savoir plus en détail. Comment le choix de basculer est fait, qu'est-ce qui se passe quand le réseau est instable (gros lag réseau ou des micro coupure de quelques millisecondes). Précédemment, le cluster windows est abordé, mais quid des sqlserveurs sous linux ? La question sql server sous linux est intéressante à aborder car les fonctionnalités ne sont pas au même niveau entre les deux éditions. Du moins c'était le cas il y a quelques années.

PostGreSQL ne dispose pas de manière interne de la notion de « listener » qui permet à toute application de ne jamais être coupé de la base opérationnelle, quel que soit le nœud actif (le listener étant constitué dans SQL Server d’une adresse IP de redirection vers le nœud actif). Compte tenu de ceci, il faudra donc modifier les chaines de connexion des applicatifs pour que le service des données fonctionne de nouveau.
On comprend donc que, si le rétablissement de la disponibilité des bases peut être très rapide en cas de sinistre dans PostGreSQL, il n’en est pas de même pour les applicatifs, car il faudra agir manuellement… !

C'est vrai, il n'y a pas de "listener" dans postgresql (on parle d'ailleurs plus de pooler de connexion dans son écosystème) intégré. Et a l'image de la bascules automatique, il y a plusieurs solutions malgré tout.

La première, c'est le client lui même qui le fait. Le driver jdbc, ou la libpq sont capables d'avoir plusieurs serveurs dans leur configuration. Il est possible d'indiquer si on veut avoir une session capable d'écrire ou pas (load balancing de la lecture). A l'ouverture de la session, le client va tester si l'instance courante répond à ces critères, si ce n'est pas le cas, il passera à la suivante.
Avec ceci, on est pas obligé de changer la configuration. Par contre, il faut prévoir la liste des membres du cluster à l'avance.

En plus complexe, on peut rajouter un pooler de connexion comme pgbouncer pour jouer le role de listener/pool de connexion. Ce dernier est par exemple capable de mettre en pause le session avec ses clients, le temps de changer de serveur postgres interrogé. Cela donne une impression de bascule transparente au client. Cependant, il y a des contraintes pour ce genre de mécanisme.

Souvent cité en complément de patroni, la mise en place d'un ha-proxy (ou plusieurs pour eviter le SPOF). Pas de transition transparente vers le nouveau maitre, il est assez simple de configurer ha-proxy pour changer sa configuration en fonction de l'état du cluster "patroni". Utile si le client ou l'application ne peut user des possibilités proposé par libpq ou autre. Après, on se fait un dns-roundrobing sur les instances ha-proxy et hop plus besoin de configurer plusieurs hôtes

Dans SQL Server, chaque groupe de disponibilité rassemblant différentes base, est généralement doté d’un listener qui redirige le flux des requêtes applicatives sur le serveur actif de manière totalement transparente du point de vue des applications. Il n’y a donc aucune action à entreprendre au niveau des applications pour que celles-ci continuent d’accéder aux données de la base active en cas de basculement automatique.

Où s’exécute ce listener ? Sur tous les membres du cluster ? Est-ce un spof ? Quelle adresse on configure sur le client ? J'avoue ne pas voir du tout comment cela fonctionne.

PostGreSQL ne disposant que d’un seul journal de transactions commun à toutes les bases de données, si la réplication n’a d'intérêt que pour certaines bases, le volume des communications entre nœuds est pollué par des informations inutiles qui obèrent les ressources.

C'est vrai qu'en pg, il n'y a qu'un seul journal de transaction pour toute l'instance. C'est un manque du produit. D'autres sont à l'image de sql server et ont un journal des transactions par base de donnée de l'instance (comme DB2 il me semble).

Il y a plus de dix ans, nous faisions dans mon organisation énormément de mutualisation d'instance sur un nombre d'hôtes physiques. On a avait donc des instances pg multi-bases (uniquement en hors production). Avec cette limite là, impossible de faire de la restauration physique pitr pour une seule base a cause de cette limite, sauf a avoir plusieurs instances sur le même serveur. Depuis, on fait de la virtualisation et a solution retenue a été de faire une vm = 1 instance bdd, ce qui contourne la limite en question.
Comme on est sur la version full libre de postgresql, on a pas à se poser la question du coût de licence lorsque l'on rajouter une nouvelle instance. Et comprendre les licences payantes, est un enfer.

Avec PostGreSQL vous aurez donc toujours un nœud dont toutes les bases sont actives et sur l’autre toutes passives avec l’étrange impression que le serveur accueillant toutes les bases passives dispose de ressources presque toutes totalement inexploitées.

Pour rebondir sur la seconde phrase, les instances secondaires peuvent servir pour faire de la lecture. Il faudra faire attention à la fraicheur des données (si réplication asynchrone) pour ne pas avoir des surprises. Comme j'ai pu le voir sur une application codée avec les pieds utilisant un replicaset mongodb....

Ceci n’est pas le cas dans SQL Server, car grâce au concept de Groupe de Disponibilité, vous pouvez par exemple, enrôler 50 % de vos bases dans un groupe et le reste dans l’autre, le groupe 1 étant actif sur le nœud A et le groupe 2 actif sur le nœud B. Ceci améliore grandement les performances globales du service des données, ou encore, permet de choisir des serveurs moins « costaud » au niveau des ressources afin d’économiser sur le matériel et les licences…

Je comprends bien l'avantage de cette architectures (en fait surtout si on utilise des machines physiques), mais il se passe quoi si on a une base qui bouffe plus des ressources que les voisines au point que ces dernières soient ralenties ? Existe-t-il un système de quota de ressources données à une base ?

Autre question, comment se passe les montées de version (mineure et majeur) lorsqu'on utilise un group de disponibilité ?

Nous savons tous que PostGreSQL est un outil gratuit… Mais dans une certaine mesure ! En effet plusieurs entreprises proposent des versions payantes de PostGreSQL (Enterprise DB, Fujitsu, Citus…) dont le coût est loin d’être négligeable et qui deviennent vite indispensable dès que la volumétrie augmente ou que l’on a besoin de telle ou telle fonctionnalité manquante dans la version « libre » de PostGreSQL… N’oublions pas que les développeurs de PostGreSQL ont eux aussi besoin de manger et que bon nombre d’entre eux sont salariés de la société Enterprise DB qui bride sciemment les fonctionnalités de PostGreSQL pour permettre de vendre leurs produits…

Je n'ai presque jamais ressenti le besoin d'utiliser une version "entreprise" de postgresql. Au début, nous avons pas mal utilisé le support (dalibo, 2ndquadrant,..) avant d'être autonome. Ces versions fermées proposent sans doute certaines fonctionnalités en avance sur la version libre (un audit plus complet, des moteurs de stockage de tables différent que la "heap",...), mais je trouve pourtant l'écosystème pg bien plus sains que pour d'autres produits "libre". Les entreprises vendant des versions évoluées, finissent par reverser/discuter du bien fondé de mettre certaines nouvelles fonctionnalité dans la version libre de postgresql. J'aime lire de temps en temps les discutions qu'ont pu avoir les dev sur certaines fonctionnalités.

Tu as raison de dire que les dev de postgres doivent manger (comme nous tous). Pourtant, selon mon avis, la base postgres est la base la plus saine dans le monde libre. Il n'y a pas qu'une seule entreprise derrière! C'est assez rare dans le monde relationnelle (voir des bdd ?) pour être souligné. Ces dernières années, on a vu trop souvent des bases "libres" se refermer petit à petit vers un modèle "freenium", "open core" ou tout autre dénomination. Je pense à mongodb (impossible de faire la prod sans passé à la cause entreprise), elasticsearch, MySQL, redis... Amazon étant souvent la source de ces changements de licence et de confli.
Leur point commun était d'avoir qu'une seule entreprise derrière le produit. Ce qui rend le produit sensible au manque d'argent et au rachat. Il me semble avoir vu que Mariadb inc n'était pas en grande forme par exemple. Et si cette dernière fermait, que se passerait-il avec le projet open source ?
Coté postgresql, il y a plusieurs entreprises. Le board et la core team (sur?)veille les conséquences en cas de rachat. (ex le rachat de 2ndquadrant par entreprisedb: https://www.postgresql.org/about/new...quadrant-2094/). Bien sur, le risque n'est pas totalement nul qu'à force de rachat, le projet postgresql ne se retrouve pas dans la même situation.

Ainsi, pour une machine à 16 cœurs logiques, avec un amortissement sur 5 ans, pour lequel vous serez passé par deux à trois versions de SQL Server (2017, 2019, 2022… par exemple), le budget mensuel sera donc de moins de 1000 €, soit un peu moins que le TJM de 2 journées d’un développeur…?

Le prix indiqués prennent-ils en compte le coup de la licence windows ? Sur le sujet, des groupes de disponibilité, cela se passe comment avec SQL server linux ? Est-ce que je lis bien ce tableau en pensant que c'est disponible dés la version standard ?


Petite digression sur les prix, on est dans un monde un peu bizarre (ou simplement mon organisation). Les produits (semi-)libre font sont de bonne "démo" pour attirer le dev qui ignore ce que sont les contraintes d'une production. Ces dernières années, j'ai vu arriver des produits (comme elasticsearch, mongodb, mysql,...) que les dev tentaient d'imposer en nous disant "c'est facile et gratuit". Ben a chaque fois ils (et leurs chefs...) tombaient des nues lorsque derrière on expliquaient "vous êtes bien gentil, mais pour pouvoir faire de la sauvegarde à chaud ou de l'audit, faut passer à la caisse"....

J’oubliais le prix des licences Windows… environ 1000 € pour 16 cœurs physiques. En amortissement sur 5 ans, cela représente donc 5 € par mois…
Cher non ?

Écris comme cela, non. Avis personnel et malgré les défauts existant, on peut faire pas mal de chose avec les sgbdr libre qui font que l'on a pas besoin de payer de suite des licence. Et certaines entreprises/organisations peuvent être rebutées pour payer des licences.

Autre chose aussi qui peut rebuter, les changements "surprise" de licence/prix de licence. Si on regarde du coté, d'oracle ils ont tellement resserrer les vis qu'ils ont fait fuir pas mal de client de leur sgbd. Toujours oracle, en changeant régulièrement le fonctionnement de la licence oracle jdk, il crée une instabilité qui me parait déraisonnable/préjudiciable.. Elasticsearch qui tue sa licence gold (la moins chère) faisant explosant le coût des clusters elasticsearch en auto-hébergé. Certes, il y a plus de fonctionnalités, mais tout le monde n'en a pas besoin... Attlassian qui se tourne en full sas. On était a deux doigts d'acheter des licences lorsque la nouvelle est tombée. Du coup le projet d'aller sur jira est tombé à l'eau. Ne parlons pas de ce que fait vmware depuis son rachat par broadcom. Elle est tombé au moment on a pris la décision de migrer de RHEV vers vmware XD.
Comme dirait le MEDEF, les entreprises ont besoin de stabilité...
Tu as données les prix actuels, mais les conditions d'accès d'un produit (libre ou pas) peut très vite changer.
Après il me semble que Microsoft est du genre "stable" sur les licences, mais c'est un avis au doigt mouillé.

Sur ce genre de billet, serait-il possible d'avoir plus de pointeurs vers la doc de Microsoft (que je trouve pas toujours évidente à parcourir).

[1] la compression des données dans SQL Server concerne les données des tables et des index et s’opère a différents niveaux plus qui permettent d’économiser plus ou moins d’octets, mais n’affecte pas les lectures dont les performances sont améliorées grâce au gain de place en cache liée à cette compression. Les techniques de compression étant spécifiques aux SGBDR. Dans SQL Server ces algorithmes consistent en deux familles : l’élimination des données non significatives d’une part (compression « ROW ») et la réalisation de dictionnaires de racines d’autre part (compression de type « PAGE ») dont on trouvera, pour cette dernière, quelques les détails techniques ici : Implémentation de la compression de page.

Je crois qu'à la toute fin, il manque un lien vers "Implémentation de la compression de page".

Le sujet est intéressant d'autant plus que coté postgresql, il y a de la compression et des mécanismes (toast) et qui peuvent générer des surprises.
qu'est-ce que toast ?
billet sur le sujet
les surprises que peut générer ce mecanisme
Un peut hors sujet: Il est possible de compresser les journaux de transaction

Aller dernier lien et une question pour la route sur la "compression" des données. Cet article explique l'influence de l'ordre des colonnes sur la taille de la table en postgresql. Ce phénomène existe-t-il également sur sql server ?


Cordialement.

Pour information il existe un organisme recensant les bencmarks officiels (TPC.org)dans lequel on n'a jamais vu figurer PostGreSQL tellement les performance comme le TCO de PostGreSQL est lamentable...

Je suis peut être pas doué, mais j'ai beau naviguer sur les différents menus "all results" je ne trouve pas de mention à postgresql (a part peut être la version custom de fujitsu). Je suis étonné de ne pas voir de résultat sur MySQL ou encore Mariadb. J'ai raté un truc ? Ou alors, il faut un compte pour avoir tous les résultats ?

Bref si l'on est un tantinet rationnel et surtout écologique on devrait éliminer PostGreSQL pour diminuer à la fois les coûts globaux licence comprise, mais aussi pour consommer moins d'énergie pour faire la même chose !

Radical comme avis et je ne suis pas d'accord avec. Sur un projet de mon organisation, où une centaine d'ordinateurs enregistrant des informations issues de capteurs (date + donnée binaire), le prestataire à du changer de base en cours de route. A l'origine, il voulait faire du redis, mais les bécanes n'arrivait pas à suivre. Il est passé sur postgresql car il était moins gourmand en ressource et fonctionner sur tous les modèles de machine. Le rôle de ces machines étant de stocker pendant quelques dizaine de jours les informations avant de les purger. Sql server me parait trop consommateur pour ce genre cas d'usage (512 mo minimum hors ram pour l'os ? + 6Go d'espace disques pour les binaires).

Questions intéressantes !!!

Envoyé par Tarul

...Existe-t-il un paramètre pour bloquer ce passage en asynchrone ?...

Directement non. Indirectement oui. On peut intercepter le moment ou AlwaysOn passe en mode asynchrone et intimer un SHUTDOWN de l'instance. La commande SHUTDOWN étant une commande Transact SQL et l'Agent SQL peut intercepter ce type d'alerte

Envoyé par Tarul

... Un quorum basé sur un disque ou sur le partage de fichier. N'est-ce pas un peu léger/dangereux ? ...

À ce jour et depuis la version 2012 de SQL Server, aucune problématique de ce genre n'a été relevé... Sur quelque millions d'instances SQL Server en cluster ! Mais le partage doit impérativement être situé sur une machine distaincte des machines à surveiller...

Envoyé par Tarul

... De même, quel est le nombre de membres dans un "cluster windows" ? Il devrait être impair, non ? Sinon la solution me parait sensible au split-brain, non ? ...

Rassurez-vous le cluster veille et désactive le quorum quand un nombre paire de votant est atteint pour rétablir l'imparité du vote...
Par exemple chez un grand logisticien international fonctionnant 24h sur 24 nous avions, en version 2016, 5 noeuds (1 active RW, 1 passif, 3 Readable) le quorum était non votant mais si nous éteignions une machine, alors il devenait votant...

Envoyé par Tarul

... Je serais curieux d'en savoir plus en détail. Comment le choix de basculer est fait ...

Chaque nœud est valué avec un poids. Ce qui permet de savoir sur quelle machine passer la production en cas de défaillance du nœud actif

Envoyé par Tarul

... qu'est-ce qui se passe quand le réseau est instable (gros lag réseau ou des micro coupure de quelques millisecondes). ...

Passage en mode asynchrone, puis rattrapage.

Envoyé par Tarul

... Précédemment, le cluster windows est abordé, mais quid des sqlserveurs sous linux ? La question sql server sous linux est intéressante à aborder car les fonctionnalités ne sont pas au même niveau entre les deux éditions. Du moins c'était le cas il y a quelques années. ...

Bonne question. Mais je vais vous décevoir... rares sont les installations de SQL Server sous Linux et très rares sont celle avec de la haute disponibilité car trop complexe, trop instables... Cela nécessite des outils externes qui collaborent mals....

Envoyé par Tarul

... C'est vrai, il n'y a pas de "listener" dans postgresql [...] Où s’exécute ce listener ? Sur tous les membres du cluster ? Est-ce un spof ? Quelle adresse on configure sur le client ? ...

C'est une ressources externe, une adresse IP virtuelle enregistrée dans l'AD comme nom de machine "flottante" et qui assure la redirection. Elle est considérée comme une machine (PC) mais est gérée à la fois au niveau du cluster et du groupe de disponibilité.

Envoyé par Tarul

... Pour rebondir sur la seconde phrase, les instances secondaires peuvent servir pour faire de la lecture. Il faudra faire attention à la fraicheur des données (si réplication asynchrone) pour ne pas avoir des surprises. Comme j'ai pu le voir sur une application codée avec les pieds utilisant un replicaset mongodb.... ...

En pratique, la latence est souvent de moins d'une seconde... À la condition d'avoir, si site distant, de la fibre avec un débit dédié...

Envoyé par Tarul

... Je comprends bien l'avantage de cette architectures (en fait surtout si on utilise des machines physiques), mais il se passe quoi si on a une base qui bouffe plus des ressources que les voisines au point que ces dernières soient ralenties ? Existe-t-il un système de quota de ressources données à une base ? ...

Bien évidemment. Cela passe par le gouverneur de ressources qui permet d'imposer des quotas de mémoire, de disque et de CPU...
On peut aussi effectuer de nombreux réglages différents base par base. Par exemple avoir des bases qui travaillent en version 2008, 2012, 2016, 2017, 2019, 2022 dans une instance 2022 (ni PostGreSQL ni Oracle ne savent faire ça..). On peut régler le niveau de parallélisme base par base, etc...

Envoyé par Tarul

... Autre question, comment se passe les montées de version (mineure et majeur) lorsqu'on utilise un group de disponibilité ? ...

Comme dit précédemment, le problème est bien différent, car SQL Server permet de faire tourner des bases en rétrocompatibilité. Les version "mineures" de PostGreSQL correspondent aux CU (Cumulative Update) et n'ont généralement pas besoin de redémarrage (modification à chaud). Si un tel CU a besoin de redémarrer, alors le système bascule et les applications ne voient rien... Pour ce qui est des version majeures il est possible d'assurer la cotinuité en ajoutant un noeud dans la version supérieure et de forcer le basculement, en mode synchrone. Là aussi les applications ne voient rien et les bases restent dans leur mode de rétrocompatibilité jusqu'à ce qu'on les modifient (à chaud) pour être dans la dernière version. Par exemple si sur une instance 2019 je met un nœud 2024 et qu'il y a une base en rétrocompatibilité 2016 et une autre en compatibilité directe (2019) alors la bascule vers 2022, laisse les bases en 2016 et 2019, jusqu'à ce que le DBA lance la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 160;

Ceci se faisant à chaud avec des utilisateurs qui verront les requêtes suivantes dans leur connexion utiliser la nouvelle version...

Envoyé par Tarul

... Je n'ai presque jamais ressenti le besoin d'utiliser une version "entreprise" de postgresql. Au début, nous avons pas mal utilisé le support (dalibo, 2ndquadrant,..) avant d'être autonome. Ces versions fermées proposent sans doute certaines fonctionnalités en avance sur la version libre (un audit plus complet, des moteurs de stockage de tables différent que la "heap",...), mais je trouve pourtant l'écosystème pg bien plus sains que pour d'autres produits "libre". Les entreprises vendant des versions évoluées, finissent par reverser/discuter du bien fondé de mettre certaines nouvelles fonctionnalité dans la version libre de postgresql. J'aime lire de temps en temps les discutions qu'ont pu avoir les dev sur certaines fonctionnalités. ...

Je dirais que c'est souvent une question de taille... Je travaille avec des entreprises et des éditeurs de logiciel dont les bases font couramment plusieurs Tera octets et ces bases comptent souvent plusieurs milliers de tables (sans compter les vues et procédures stockées....) Par exemple il y a quelques années, un de mes client à embauché un nouveau DSI qui ne jurait que par PostgreSQL et m'a demandé de passer la base de leur l'ERP de SQL Server à PostReSQL. je lui ait fournit un devis de plus de 10 années hommes... la base comportait plus de 400 tables et près de 1000 procédures stockées dont 30% avec du XML que PostGreSQL ne sait pas gérer correctement (il est resté à XPatch 1.0...)

Envoyé par Tarul

... Tu as raison de dire que les dev de postgres doivent manger (comme nous tous). Pourtant, selon mon avis, la base postgres est la base la plus saine dans le monde libre. ...

Je te rejoins... Surtout si tu compare à MariaDb qui est en faillite et MySQL qui pousse vers Oracle...

Envoyé par Tarul

... Il n'y a pas qu'une seule entreprise derrière! C'est assez rare dans le monde relationnelle (voir des bdd ?) pour être souligné. Ces dernières années, on a vu trop souvent des bases "libres" se refermer petit à petit vers un modèle "freenium", "open core" ou tout autre dénomination. Je pense à mongodb (impossible de faire la prod sans passé à la cause entreprise), elasticsearch, MySQL, redis... ...

Mais ce sera le lot de PostGreSQL tôt ou tard avec l'évolution des technologies qui nécessitent de plus en plus d'investissement (ce pourquoi PostGreSQL est bridée) et aussi à cause de la volumétrie des données qui augmente...

Envoyé par Tarul

... Le prix indiqués prennent-ils en compte le coup de la licence windows ? Sur le sujet, des groupes de disponibilité, cela se passe comment avec SQL server linux ? Est-ce que je lis bien ce tableau en pensant que c'est disponible dés la version standard ? ...

La licence Windows Server standard (suffisante dans 99% des cas et 99.9 pour SQL Server) est très peu cher. De tête je dirais moins de 1 000 €.... par paquet de 16 cœurs physique (soit 32 cœurs logiques...)
Et oui, AlwaysOn est disponible en version standard mais avec quelques restrictions :

• un groupe de disponibilité par base (comme PostGreSQL)
• deux nœuds au maximum.

Envoyé par Tarul

... Petite digression sur les prix, on est dans un monde un peu bizarre (ou simplement mon organisation). Les produits (semi-)libre font sont de bonne "démo" pour attirer le dev qui ignore ce que sont les contraintes d'une production. Ces dernières années, j'ai vu arriver des produits (comme elasticsearch, mongodb, mysql,...) que les dev tentaient d'imposer en nous disant "c'est facile et gratuit". Ben a chaque fois ils (et leurs chefs...) tombaient des nues lorsque derrière on expliquaient "vous êtes bien gentil, mais pour pouvoir faire de la sauvegarde à chaud ou de l'audit, faut passer à la caisse".... ...

C'est là ou SQL Server est souvent beaucoup moins cher....

Envoyé par Tarul

... Autre chose aussi qui peut rebuter, les changements "surprise" de licence/prix de licence. Si on regarde du coté, d'oracle ils ont tellement resserrer les vis qu'ils ont fait fuir pas mal de client de leur sgbd. Toujours oracle, en changeant régulièrement le fonctionnement de la licence oracle jdk, il crée une instabilité qui me parait déraisonnable/préjudiciable.. Elasticsearch qui tue sa licence gold (la moins chère) faisant explosant le coût des clusters elasticsearch en auto-hébergé. Certes, il y a plus de fonctionnalités, mais tout le monde n'en a pas besoin... Attlassian qui se tourne en full sas. On était a deux doigts d'acheter des licences lorsque la nouvelle est tombée. Du coup le projet d'aller sur jira est tombé à l'eau. Ne parlons pas de ce que fait vmware depuis son rachat par broadcom. Elle est tombé au moment on a pris la décision de migrer de RHEV vers vmware XD.
Comme dirait le MEDEF, les entreprises ont besoin de stabilité...
Tu as données les prix actuels, mais les conditions d'accès d'un produit (libre ou pas) peut très vite changer.
Après il me semble que Microsoft est du genre "stable" sur les licences, mais c'est un avis au doigt mouillé. ...

Effectivement Microsoft est extrêmement stable sur son modèle de licence qui n'a ahcngé qu'une seule v=fois en 25 ans, pour passer d'une tarification "serveur" à une tarification par coeur au moment de la sortie de la version 2012...
C'est une volonté pour se démarquer de la concurrence... qui change de modèle de vente comme de chemise !

Envoyé par Tarul

... Je crois qu'à la toute fin, il manque un lien vers "Implémentation de la compression de page"....

Oui et je ne sais pas comment le corriger.... voici le lien

Implémentation de la compression de page

Envoyé par Tarul

... Aller dernier lien et une question pour la route sur la "compression" des données. Cet article explique l'influence de l'ordre des colonnes sur la taille de la table en postgresql. Ce phénomène existe-t-il également sur sql server ? ...

Oui cette problématique est très connue. Quand je donnais des cours sur les SGBDR il y a 30 ans, j'en parlais déjà en disant qu'il fallait placer les colonnes de taille fixe en tête et celle de taille variable en queue... Mais si tu doit rajouter une colonne à une table en exploitation, c'est mort !
le problème n'existe pas dans SQL Server qui ordonne les colonnes pour les optimiser dans ce sens et sépare les LOBs dans une couche de stockage différente afin de ne pas polluer les données purement relationnelles. J'avais écrit il y a fort longtemps un article sur le stockage dans PostGreSQL qui montrait ce genre de défaut...

Voici un schéma que je donne dans mon livre "SQL Server 2014"

Concernant PostGreSQL les deux points noirs sont :

• la gestion du MVCC qui est une catastrophe
• le modèle de fonctionnement en processus (et non pas en thread) qui imite le parallélisme et bouffe d'énormes ressources

Ceci fait que la montée en charge (volume, utilisateurs, parallélisme...) sera toujours un lourd handicap... En dehors d'un nombre important de fonctionnalités aujourd'hui essentielles dans le monde de l'entreprise (tables "in memory", table de graphe, index verticaux, procédures natives, tables temporelles...).
A +

PS : ravi de cette discussion, je vois que vous vous intéressez au monde des bases de données et il y a hélas peu de gens compétent et capable de comprendre les problèmes et les enjeux des données et notamment leur importance critique dans l'organisation de l'entreprise...

Questions intéressantes !!!

Envoyé par Tarul

...Existe-t-il un paramètre pour bloquer ce passage en asynchrone ?...

Directement non. Indirectement oui. On peut intercepter le moment ou AlwaysOn passe en mode asynchrone et intimer un SHUTDOWN de l'instance. La commande SHUTDOWN étant une commande Transact SQL et l'Agent SQL peut intercepter ce type d'alerte

Envoyé par Tarul

... Un quorum basé sur un disque ou sur le partage de fichier. N'est-ce pas un peu léger/dangereux ? ...

À ce jour et depuis la version 2012 de SQL Server, aucune problématique de ce genre n'a été relevé... Sur quelque millions d'instances SQL Server en cluster ! Mais le partage doit impérativement être situé sur une machine distaincte des machines à surveiller...

Envoyé par Tarul

... De même, quel est le nombre de membres dans un "cluster windows" ? Il devrait être impair, non ? Sinon la solution me parait sensible au split-brain, non ? ...

Rassurez-vous le cluster veille et désactive le quorum quand un nombre paire de votant est atteint pour rétablir l'imparité du vote...
Par exemple chez un grand logisticien international fonctionnant 24h sur 24 nous avions, en version 2016, 5 noeuds (1 active RW, 1 passif, 3 Readable) le quorum était non votant mais si nous éteignions une machine, alors il devenait votant...

Envoyé par Tarul

... Je serais curieux d'en savoir plus en détail. Comment le choix de basculer est fait ...

Chaque nœud est valué avec un poids. Ce qui permet de savoir sur quelle machine passer la production en cas de défaillance du nœud actif

Envoyé par Tarul

... qu'est-ce qui se passe quand le réseau est instable (gros lag réseau ou des micro coupure de quelques millisecondes). ...

Passage en mode asynchrone, puis rattrapage.

Envoyé par Tarul

... Précédemment, le cluster windows est abordé, mais quid des sqlserveurs sous linux ? La question sql server sous linux est intéressante à aborder car les fonctionnalités ne sont pas au même niveau entre les deux éditions. Du moins c'était le cas il y a quelques années. ...

Bonne question. Mais je vais vous décevoir... rares sont les installations de SQL Server sous Linux et très rares sont celle avec de la haute disponibilité car trop complexe, trop instables... Cela nécessite des outils externes qui collaborent mals....

Envoyé par Tarul

... C'est vrai, il n'y a pas de "listener" dans postgresql [...] Où s’exécute ce listener ? Sur tous les membres du cluster ? Est-ce un spof ? Quelle adresse on configure sur le client ? ...

C'est une ressources externe, une adresse IP virtuelle enregistrée dans l'AD comme nom de machine "flottante" et qui assure la redirection. Elle est considérée comme une machine (PC) mais est gérée à la fois au niveau du cluster et du groupe de disponibilité.

Envoyé par Tarul

... Pour rebondir sur la seconde phrase, les instances secondaires peuvent servir pour faire de la lecture. Il faudra faire attention à la fraicheur des données (si réplication asynchrone) pour ne pas avoir des surprises. Comme j'ai pu le voir sur une application codée avec les pieds utilisant un replicaset mongodb.... ...

En pratique, la latence est souvent de moins d'une seconde... À la condition d'avoir, si site distant, de la fibre avec un débit dédié...

Envoyé par Tarul

... Je comprends bien l'avantage de cette architectures (en fait surtout si on utilise des machines physiques), mais il se passe quoi si on a une base qui bouffe plus des ressources que les voisines au point que ces dernières soient ralenties ? Existe-t-il un système de quota de ressources données à une base ? ...

Bien évidemment. Cela passe par le gouverneur de ressources qui permet d'imposer des quotas de mémoire, de disque et de CPU...
On peut aussi effectuer de nombreux réglages différents base par base. Par exemple avoir des bases qui travaillent en version 2008, 2012, 2016, 2017, 2019, 2022 dans une instance 2022 (ni PostGreSQL ni Oracle ne savent faire ça..). On peut régler le niveau de parallélisme base par base, etc...

Envoyé par Tarul

... Autre question, comment se passe les montées de version (mineure et majeur) lorsqu'on utilise un group de disponibilité ? ...

Comme dit précédemment, le problème est bien différent, car SQL Server permet de faire tourner des bases en rétrocompatibilité. Les version "mineures" de PostGreSQL correspondent aux CU (Cumulative Update) et n'ont généralement pas besoin de redémarrage (modification à chaud). Si un tel CU a besoin de redémarrer, alors le système bascule et les applications ne voient rien... Pour ce qui est des version majeures il est possible d'assurer la cotinuité en ajoutant un noeud dans la version supérieure et de forcer le basculement, en mode synchrone. Là aussi les applications ne voient rien et les bases restent dans leur mode de rétrocompatibilité jusqu'à ce qu'on les modifient (à chaud) pour être dans la dernière version. Par exemple si sur une instance 2019 je met un nœud 2024 et qu'il y a une base en rétrocompatibilité 2016 et une autre en compatibilité directe (2019) alors la bascule vers 2022, laisse les bases en 2016 et 2019, jusqu'à ce que le DBA lance la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 160;

Ceci se faisant à chaud avec des utilisateurs qui verront les requêtes suivantes dans leur connexion utiliser la nouvelle version...

Envoyé par Tarul

... Je n'ai presque jamais ressenti le besoin d'utiliser une version "entreprise" de postgresql. Au début, nous avons pas mal utilisé le support (dalibo, 2ndquadrant,..) avant d'être autonome. Ces versions fermées proposent sans doute certaines fonctionnalités en avance sur la version libre (un audit plus complet, des moteurs de stockage de tables différent que la "heap",...), mais je trouve pourtant l'écosystème pg bien plus sains que pour d'autres produits "libre". Les entreprises vendant des versions évoluées, finissent par reverser/discuter du bien fondé de mettre certaines nouvelles fonctionnalité dans la version libre de postgresql. J'aime lire de temps en temps les discutions qu'ont pu avoir les dev sur certaines fonctionnalités. ...

Je dirais que c'est souvent une question de taille... Je travaille avec des entreprises et des éditeurs de logiciel dont les bases font couramment plusieurs Tera octets et ces bases comptent souvent plusieurs milliers de tables (sans compter les vues et procédures stockées....) Par exemple il y a quelques années, un de mes client à embauché un nouveau DSI qui ne jurait que par PostgreSQL et m'a demandé de passer la base de leur l'ERP de SQL Server à PostReSQL. je lui ait fournit un devis de plus de 10 années hommes... la base comportait plus de 400 tables et près de 1000 procédures stockées dont 30% avec du XML que PostGreSQL ne sait pas gérer correctement (il est resté à XPatch 1.0...)

Envoyé par Tarul

... Tu as raison de dire que les dev de postgres doivent manger (comme nous tous). Pourtant, selon mon avis, la base postgres est la base la plus saine dans le monde libre. ...

Je te rejoins... Surtout si tu compare à MariaDb qui est en faillite et MySQL qui pousse vers Oracle...

Envoyé par Tarul

... Il n'y a pas qu'une seule entreprise derrière! C'est assez rare dans le monde relationnelle (voir des bdd ?) pour être souligné. Ces dernières années, on a vu trop souvent des bases "libres" se refermer petit à petit vers un modèle "freenium", "open core" ou tout autre dénomination. Je pense à mongodb (impossible de faire la prod sans passé à la cause entreprise), elasticsearch, MySQL, redis... ...

Mais ce sera le lot de PostGreSQL tôt ou tard avec l'évolution des technologies qui nécessitent de plus en plus d'investissement (ce pourquoi PostGreSQL est bridée) et aussi à cause de la volumétrie des données qui augmente...

Envoyé par Tarul

... Le prix indiqués prennent-ils en compte le coup de la licence windows ? Sur le sujet, des groupes de disponibilité, cela se passe comment avec SQL server linux ? Est-ce que je lis bien ce tableau en pensant que c'est disponible dés la version standard ? ...

La licence Windows Server standard (suffisante dans 99% des cas et 99.9 pour SQL Server) est très peu cher. De tête je dirais moins de 1 000 €.... par paquet de 16 cœurs physique (soit 32 cœurs logiques...)
Et oui, AlwaysOn est disponible en version standard mais avec quelques restrictions :

• un groupe de disponibilité par base (comme PostGreSQL)
• deux nœuds au maximum.

Envoyé par Tarul

... Petite digression sur les prix, on est dans un monde un peu bizarre (ou simplement mon organisation). Les produits (semi-)libre font sont de bonne "démo" pour attirer le dev qui ignore ce que sont les contraintes d'une production. Ces dernières années, j'ai vu arriver des produits (comme elasticsearch, mongodb, mysql,...) que les dev tentaient d'imposer en nous disant "c'est facile et gratuit". Ben a chaque fois ils (et leurs chefs...) tombaient des nues lorsque derrière on expliquaient "vous êtes bien gentil, mais pour pouvoir faire de la sauvegarde à chaud ou de l'audit, faut passer à la caisse".... ...

C'est là ou SQL Server est souvent beaucoup moins cher....

Envoyé par Tarul

... Autre chose aussi qui peut rebuter, les changements "surprise" de licence/prix de licence. Si on regarde du coté, d'oracle ils ont tellement resserrer les vis qu'ils ont fait fuir pas mal de client de leur sgbd. Toujours oracle, en changeant régulièrement le fonctionnement de la licence oracle jdk, il crée une instabilité qui me parait déraisonnable/préjudiciable.. Elasticsearch qui tue sa licence gold (la moins chère) faisant explosant le coût des clusters elasticsearch en auto-hébergé. Certes, il y a plus de fonctionnalités, mais tout le monde n'en a pas besoin... Attlassian qui se tourne en full sas. On était a deux doigts d'acheter des licences lorsque la nouvelle est tombée. Du coup le projet d'aller sur jira est tombé à l'eau. Ne parlons pas de ce que fait vmware depuis son rachat par broadcom. Elle est tombé au moment on a pris la décision de migrer de RHEV vers vmware XD.
Comme dirait le MEDEF, les entreprises ont besoin de stabilité...
Tu as données les prix actuels, mais les conditions d'accès d'un produit (libre ou pas) peut très vite changer.
Après il me semble que Microsoft est du genre "stable" sur les licences, mais c'est un avis au doigt mouillé. ...

Effectivement Microsoft est extrêmement stable sur son modèle de licence qui n'a ahcngé qu'une seule v=fois en 25 ans, pour passer d'une tarification "serveur" à une tarification par coeur au moment de la sortie de la version 2012...
C'est une volonté pour se démarquer de la concurrence... qui change de modèle de vente comme de chemise !

Envoyé par Tarul

... Je crois qu'à la toute fin, il manque un lien vers "Implémentation de la compression de page"....

Oui et je ne sais pas comment le corriger.... voici le lien

Implémentation de la compression de page

Envoyé par Tarul

... Aller dernier lien et une question pour la route sur la "compression" des données. Cet article explique l'influence de l'ordre des colonnes sur la taille de la table en postgresql. Ce phénomène existe-t-il également sur sql server ? ...

Oui cette problématique est très connue. Quand je donnais des cours sur les SGBDR il y a 30 ans, j'en parlais déjà en disant qu'il fallait placer les colonnes de taille fixe en tête et celle de taille variable en queue... Mais si tu doit rajouter une colonne à une table en exploitation, c'est mort !
le problème n'existe pas dans SQL Server qui ordonne les colonnes pour les optimiser dans ce sens et sépare les LOBs dans une couche de stockage différente afin de ne pas polluer les données purement relationnelles. J'avais écrit il y a fort longtemps un article sur le stockage dans PostGreSQL qui montrait ce genre de défaut...

Voici un schéma que je donne dans mon livre "SQL Server 2014"

Concernant PostGreSQL les deux points noirs sont :

• la gestion du MVCC qui est une catastrophe
• le modèle de fonctionnement en processus (et non pas en thread) qui imite le parallélisme et bouffe d'énormes ressources

Ceci fait que la montée en charge (volume, utilisateurs, parallélisme...) sera toujours un lourd handicap... En dehors d'un nombre important de fonctionnalités aujourd'hui essentielles dans le monde de l'entreprise (tables "in memory", table de graphe, index verticaux, procédures natives, tables temporelles...).
A +

PS : ravi de cette discussion, je vois que vous vous intéressez au monde des bases de données et il y a hélas peu de gens compétent et capable de comprendre les problèmes et les enjeux des données et notamment leur importance critique dans l'organisation de l'entreprise...

Envoyé par Tarul

Je suis peut être pas doué, mais j'ai beau naviguer sur les différents menus "all results" je ne trouve pas de mention à postgresql (a part peut être la version custom de fujitsu). Je suis étonné de ne pas voir de résultat sur MySQL ou encore Mariadb. J'ai raté un truc ? Ou alors, il faut un compte pour avoir tous les résultats ? ...

Vous plaisantez ? les résultats de tels tests sont tellement mauvais qu'ils n'ont jamais osé publier quoi que ce soit... ! PostGreSQL a bien tenté mais renoncé...
Lisez les test de performance que j'ai fait comparant SQL Server et PostGreSQL....
Sur les commandes du DBA.... PostgGreSQL est en moyenne 30 fois plus lent...
Sur les requêtes statistiques (count, sum)... PostgGreSQL est jusqu'à 1500 fois plus lent...
Tous les tests que je fais sont reproductibles car je donne les bases de données des deux moteurs et les requêtes de test...

Envoyé par Tarul

Radical comme avis et je ne suis pas d'accord avec. Sur un projet de mon organisation, où une centaine d'ordinateurs enregistrant des informations issues de capteurs (date + donnée binaire), le prestataire à du changer de base en cours de route. A l'origine, il voulait faire du redis, mais les bécanes n'arrivait pas à suivre. Il est passé sur postgresql car il était moins gourmand en ressource et fonctionner sur tous les modèles de machine. Le rôle de ces machines étant de stocker pendant quelques dizaine de jours les informations avant de les purger. Sql server me parait trop consommateur pour ce genre cas d'usage (512 mo minimum hors ram pour l'os ? + 6Go d'espace disques pour les binaires).

Pour information il existe une solution gratuite SQL Server et spécifique pour cela, "service broker". Chaque machine est dotée d'une version Express de SQL Server (gratuite) et pas besoin d'un OS serveur... et "service broker" est charger d'expédier les données de l'ensemble des machines vers une base centrale. Pour information, la SNCF utilise cela pour tous ses guichets (électronique ou agent) depuis la version 2005 (cela fait tout de même plus de 25 000 noeuds qui communique avec une base centrale à St Lazare.... projet Nefertiti. Les données arrivent au fil de l'eau (pas en temps réel).
Quelques éléments...
A quoi sert Service Broker
Service Broker : un SODA au goût de SQL !

Je l'ai moi même utilisé pour la production des vaccins sur les chaines de prod de Pasteur Mérieux... et d'autres clients comme récemment le club med pour la gestion des villages vacances...

A +