Discussion :

[martial.kiba]

Bonjour,

Quelqu'un dans le groupe aurait-il une expérience postgres (version community ou payante) avec une base de plus de 30To?

J'aimerais avoir une idée de la capacité de postgres à gérer de très grosse bases de données afin d'affiner mes choix.

Bien cordialement.

[SQLpro]

PostGreSQL n'a jamais été taillé pour gérer des gros volumes. En pratique se limiter à quelques centaines de Go. Récemment la CAF est repassé de PG à Oracle après avoir été quelques années en galère avec PostGreSQL. Une grande assurance de cadre à abandonné sous projet de migration de DB2 vers PG à la suite de résultats catastrophique lié à l'absence de compression des données et de blocage lié au processus de VACUUM...

Pourquoi PostGreSQL n'est pas capable de gérer de gros volumes :

• Pas de stockage dédié. Que ce soit dans Oracle ou Microsoft SQL Server le stockage est gérer de manière directe par des accès qui ne s'effectuent pas dans l'OS mais utilise des API spécifique d'accès aux disques, ce qui permet d'accélérer les écritures et lectures physiques.
• Pas d'index pour les grosses volumétries. Les techniques modernes d'indexation de grosses volumétries passent par des index verticaux ("columstore" par opposition aux index "rowstore"). Que PG n'est pas capable de proposer. Oracle les réservent pour l'OLAP, et Microsoft SQL Server aussi bien pour l'OLTP que pour l'OLAP.
• Compression des données. PG ne dispose pas de méthodes de compression des données relationnelles (tables et index) permettant de préserver toutes les fonctionnalités de recherche et d'accès tant en lecture qu'en écriture. MIcrosoft SQL Server dispose par exemple de 4 modes de compression (sparse columns, vardecimal, row ou page).
• Parallélisme. Le parallélisme qui permet d'accéder par de multiple thread à de grosses quantité des données a extraire est embryonnaire dans PG et manuel (seul 8 algorithmes des plans d'exécution sur une trentaine sont gérés). Dans SQL Server, le parallélisme est automatique et concerne presque toutes les opérations d'un plan de requête (plus de 100 algorithmes). Dans Oracle, ce module est manuel et payant.
• Tables "in memory". Pour accélérer certains accès, le recours aux tables en mémoire peut s'avérer très payant (jusqu'à 30 fois plus rapide). PG ne dispose pas de ce genre de chose en standard, sauf à utiliser des version payantes spécifique comme celle de Fujitsu). Le "In Memory" existe dans Oracle (limité à la BUI) et dans MS SQL Server (LOAP/OLTP).
• Procédures compilées natives. Cettet fonctionnalité qui permet d'accélérer notablement les écritures des tables "in memory" n'existe pas dans PG. Elle existe dans MS SQL Server.
• Optimiseur limité... Qui dit volume dit souvent requête complexes. En pratique l'optimiseur de PG n'est pas capable d'aller au delà de 8 jointure GEQO prends le relai et pisse des plans aléatoirement bon... ou mauvais ! La ou la R&D de Microsoft ou Oracle est irremplaçable.
• Tag de requête interdit. Dès que le plan de requête devient très complexe, alors il faut parfois donner un coup de pouce en utilisant un "hint" (tag de requête) pour forcer le moteur à adopter une certaines stratégie algorithmique. Bien que le recours à ce stratagème ne soit pas toujours très conseillé, il est utile, notamment en urgence ou pour corriger un plan déficient. PG interdit ce genre de choses (c'est le seul SGBDR a avoir cette position radicale et imbécile). Mais certaines versions payantes de PG le propose...
• Correction de plan d'exécution. Certains SGBDR possèdent de nombreux outil pour corriger les plans de requêtes anormalement lent. C'est sous la forme d'un module d'auto apprentissage. Par exemple sous SQL Server (Query Store + Intelligent Query Processing). Tous les plans de requêtes sont stockés, analysé et surveillé et en cas de dérive un plan plus adapté est forcé... Cela n'existe pas dans PG.
• Récriture de requête. Le moteur relationnel de Microsoft SQL Sever permet récrit les requêtes pour obtenir des plans d'exécution plus rapide. Cela passe par différentes adaptation (jointures adaptative, exécution entrelacée des variables table, mode d'exécution "batch" algorithmique, enlignement des fonctions scalaires...)
• Limitation des collations. Les recherches insensibles à la casse ou aux accents sont plus que limitées et parfois impossible dans PG. Alors que SQL Server présente plus de 5000 collations avec gestion des sensibilités ou non à la casse, aux diacritiques, aux kanatypes, à la largeur du caractères (2=² ?), etc.
• Statistiques d'optimiseur très limitées. PostGreSQL ne permet pas de créer des statistiques combinées sur plusieurs colonnes ce qui fait qu’en cas de restriction (clause WHERE, HAVING, prédicats des JOINs...) portant sur de nombreux critères d’une même table, l’optimiseur est incapable d’estimer correctement les cardinalités et produit des plans ineptes. De même d'ailleurs pour les requêtes LIKE '%toto%'...
• Pas de cache pour les requêtes ad hoc. Contrairement à la concurrence, PostGreSQL ne propose pas de mettre en cache les plans des requêtes « ad hoc » pour réutilisabilité, sauf à explicitement modifier le code applicatif en obligeant toute requête à passer par une phase de préparation, ce qui alourdit le code et augmente le temps de traitement.
• VACUMM bloquant. MVCC crée des lignes fantômes liées au versionnement du verrouillage optimiste. Ces lignes sont créées dans les mêmes pages que les lignes "vivantes", ce qui les alourdi considérablement. Il faut alors allez nettoyer ces pages des lignes fantômes, mais cela nécessite un verrou bloquant les pages durant le nettoyage (opération VACUUM). En pratique cette opération s'avère lourde et génère de nombreux verrous mortel. Impossible à utiliser dans une base fortement transactionnelle.
• Opérateur COUNT lent. Du fait même du MVCC, le comptage d'occurrence nécessite un parcours exhaustif des lignes des pages. Dans les SGBDR dont les lignes fantômes sont gérées en dehors des pages le comptage d'occurrence peut se faire par la lecture des entêtes des pages sans devoir les parcourir. Le résultat est que PG s'avère le plus lent des SGBDR sur la plupart des cas de comptage. SQL Server s'avérant le plus rapide devant même Oracle.

Il ne faut pas être grand clerc de notaire pour constater qu’il n’existe pas en production de très grandes bases de données sous PostGreSQL. La plupart des sites web marchand français sont sous SQL Server (fnac, cdiscount, vente-privee…) quelques-uns sous Oracle (tgv.com en particulier) et pour plusieurs dizaines de To dans un seul et même serveur et souvent une seule base.
On nous site régulièrement l’exemple du site « leboncoin » qui héberge ses données sous PostGreSQL soit quelques 8 To de données, mais à y bien regarder, ce n’est pas la même musique… En effet dans ce témoignage livré aux « PGdays » en 2014 :
https://fr.slideshare.net/jlb666/pgd...ez-leboncoinfr
…on y trouve les informations suivantes :
• 100+ servers running PostGreSQL
• 8TB of data
Qui, si ma calculette est bonne, me dit qu’en moyenne chaque serveur héberge 80 Go de données ! Mesure parfaitement réaliste, qui échappe à beaucoup d’internautes vantant les mérites d’un PostGreSQL hébergeant plusieurs To de données… rumeur, rumeur, quand tu nous tiens… !
Notons aussi que l’activité du bon coin est faiblement transactionnelle. Il ne s’agit pas d’un site web de vente (pas de commande, pas de gestion de stock, back office réduit…), et l’essentiel ressemble plus à un CRM de grande ampleur qu’à Amazon. De plus la partie BO et le BI est confié à... Devinez ??? Microsoft SQL Server !
Chez Orange même constat, la base sert au moteur d’indexation textuel et contient 24 To répartie sur 800 serveurs PostGreSQL soit environ 30 Go par serveur…
Pour la CAF, même combat, autant de serveur PostGreSQL que de départements français… et même avec cela retour à Oracle depuis peu !


A +

[martial.kiba]

Bonsoir,

Merci pour vos éclaircissements; En effet, mes expériences avec PostgreSQL ont été sur des bases de moins de 1To. Raison pour laquelle j'ai créé ce topic ici pour avoir des retours d'expérience.

En fait, j'ai une base (des bases) qui tournent sous SQL Server 2008, et je suis entrain de changer de serveur. Donc je prospecte la possibilité de changer de serveur de base de données. Le serveur devra pouvoir gérer 250 000 000 de transactions jour (avec une taille qui va tourner autour de 40/50To). Oracle n'est pas une option, vu les coûts des licences Oracle.

Pourriez-vous expliciter cette partie: "In Memory" existe dans Oracle (limité à la BUI). Je crois savoir qu'Oracle supporte les mémoires persistantes et les tables en mémoire (transactionnelles). Je dirais même un peu mieux que SQL Serveur (pour la version 2019 de SQL Server, il y'a des limitations: il faut des clés primaires sur les tables, ...). En plus, SQL Server supporte les mémoires persistantes uniquement sous Linux.


Du coup, avez-vous des retours d'expérience de SQL Server sous Linux? J'envisage fortement un déploiement de SQL Server sous Linux.

Merci déjà pour votre disponibilité.

[SQLpro]

....
Pourriez-vous expliciter cette partie: "In Memory" existe dans Oracle (limité à la BUI). Je crois savoir qu'Oracle supporte les mémoires persistantes et les tables en mémoire (transactionnelles). Je dirais même un peu mieux que SQL Serveur (pour la version 2019 de SQL Server, il y'a des limitations: il faut des clés primaires sur les tables, ...). En plus, SQL Server supporte les mémoires persistantes uniquement sous Linux.

Du coup, avez-vous des retours d'expérience de SQL Server sous Linux? J'envisage fortement un déploiement de SQL Server sous Linux.

Les versions Linux et Windows de SQL Server ont des fonctionnalités identiques, sauf en ce qui concerne FILESTREAM et FileTable qui n'est pas supporté dans Linux.
Nous avons un client qui gère du casino en ligne sous Linux et d'autres pour des activités moindres. Pas de souci particulier, si ce n'est qu'il y a beaucoup moins d'outils facilitant l'administration. Or aujourd'hui une licence Windows, c'est moins de 1000 € ! Donc, pour les grosses bases, je recommande toujours Windows plutôt que Linux. Et pour Linux, il vaut mieux respecter les plateformes supportées sinon en cas de problème, la hot line MS n'interviendra pas. Sachez aussi que pour une solution de SQL Server sous Linux, la hot line MS se limitera strictement à SQL Server alors que sous Windows, la hotline pourra aussi intervenir sous Windows...

Comme je suis en vacances, je n'ai pas toute ma doc, mais je ne me souviens pas de l'exigence d'une clef primaire pour une table "In Memory" dans SQL Server. De même pour Oracle, dans mon souvenir cela était limité à la BI. Est-ce encore le cas dans la version la plus récente, je ne sais pas...

Pour ce qui est du nombre de transactions, il y a belle lurette que SQL Server a battu Oracle sur ce plan là. Regardez les benchmarks du TPC. Oracle continu de publier des résultats pour le TPC-C devenu obsolète (datant de 1992, soit près de 30 ans.... - la pire requête comporte 2 jointures !) et s'est fait battre à plate couture par les chinois (OceanBase d'Alibaba...). Le benchmark le plus approprié pour l'OLTP étant maintenant le TPC-E datant de 2007 (la requête la plus complexe comporte 8 tables) SQL Server étant actuellement le plus performant.

A +

[martial.kiba]

Comme je suis en vacances, je n'ai pas toute ma doc, mais je ne me souviens pas de l'exigence d'une clef primaire pour une table "In Memory" dans SQL Server.
...

Bonsoir
J'ai souffert avant de le retrouver celui là

Syntax for memory-optimized indexes

Each CREATE TABLE statement for a memory-optimized table must include an index, either explicitly through an INDEX or implicitly through a PRIMAY KEY or UNIQUE constraint.

To be declared with the default DURABILITY = SCHEMA_AND_DATA, the memory-optimized table must have a primary key. The PRIMARY KEY NONCLUSTERED clause in the following CREATE TABLE statement satisfies two requirements:

Provides an index to meet the minimum requirement of one index in the CREATE TABLE statement.

Provides the primary key that is required for the SCHEMA_AND_DATA clause.

voici le lien sur le site de Microsoft: https://docs.microsoft.com/en-us/sql...l-server-ver15

par contre, concernant les mémoires persistantes, j'avais mal lu. C'est bien supporté sous Windows.


J'ai eu le support de Enterprise DB (ils offrent une distribution de PostgreSQL sous licence commerciale). Ils me confirment qu'ils peuvent gérer une base de cette taille en garantissant des requêtes en temps réel. J'aurais besoin de preuves la dessus quand même (je vais le leur exiger).

La version de SQL Server que j'utilise actuellement est la 2008 R2 et j'avoue qu'elle m'a deçu. J'ai fait des tests dessus, et sur une PostgreSQL community (pour des chargements en masse). Les deux bases ont été installées sur le même serveur. Sur 1 300 000 lignes environs, j'ai les mêmes temps avec SQL Server et PostgreSQL (c'est vrai vrai que plus la base devien lourde on peut avoir tendance à voir ces chiffres baisser. En plus du fait vous me déconseillez PostgreSQL pour les grosses bases).

J'avoue également avoir tester SQL Server 2012 et les performances étaient nettement meilleures. Je suppose donc qu'avec la 2019 c'est encore mieux. Apparement pour les BigData Clusters if faut que le master database soit sous Linux.


Merci

[SQLpro]

SQL Server 2019 à des performances très exceptionnelles., du fait de nouveaux algorithmes de l'optimiseur... testez là !

Quand à enterpriseDB, exigez de communiquer avec les clients des références qu'ils vous donnerons.... Pour ce que je sais, aucune entreprise que je connais avec du PG ne l'utilise avec une seule base ayant ce volume. La compagnie d'assurance dont je parle (Agirc Arrco pour ne pas la nommer - c'est l'assurance retraite des cadres en France, plusieurs millions de comptes....) a jeté l'éponge après avoir dépensé des sommes colossales pour une telle migration...

je n'ai pas parlé des vulnérabilité de PG... qui sont en nombre ahurissante malgré sa petite taille par rapport à SQL Server... ni du fait qu'il n'y a pas d'option NoSQL dans PG, alors que les modes "graphe", "document", "big table" et PKV sont possible dans SQL Server...

A +

[Invité]

Quelqu'un dans le groupe aurait-il une expérience postgres (version community ou payante) avec une base de plus de 30To?

Moi non mais apparemment certains oui :
https://medium.com/adyen/updating-a-...e-f64384b799e7
https://www.postgresql.org/community...esql-database/
https://sudonull.com/post/212847-The...-on-PostgreSQL

Après si tu n'écoutes que les vendeurs de sql server, ils vont te dire que pg est nul, etc, etc... forcément.

[ced]

Bonjour,

MeteoFrance gère de grosses bases de données avec PostgreSQL, sans broncher : https://www.postgresql.fr/temoignages/meteo_france
Ne croyez pas forcément tout ce qu'on vous annonce de manière péremptoire...

[pachot]

Bonjour,

Le volume de la base n'est pas le plus critique (à condition d'avoir un bon moyen de faire des backups au niveau du stockage). J'ai vu une base PostgreSQL en dizaine de TB mais elles gérait des images et des sons.
Par contre, les 250M transactions par jour c'est beaucoup. Mais ça ne veut pas dire impossible. L'idéal serait de faire un PoC car tout dépend du contexte.

Pour rester 100% compatible PostgreSQL mais être sûr de la scalabilité il y a aussi la base de donnée distribuée https://www.yugabyte.com/yugabytedb/
Open Source, ils utilisent la couche SQL et PL/pgSQL de PostgreSQL mais ont un moteur distribué dessous qui permet de rajoutée des noeuds.

A mon avis ça n'a pas trop d’intérêt de regarder les autres projets: Les projets plantés, c'est souvent à cause de la mauvaise gestion plutôt que de la technique. Les projets réussis, là c'est intéressant de voir les "lessons learned". Il faut avoir conscience qu'il y a un gros effort d'administration et de dev pour faire marcher une base PostgreSQL de cette taille.

Franck.

[SQLpro]

QUOTE=SimonDecoline;11611557]Moi non mais apparemment certains oui : [/QUOTE]
https://medium.com/adyen/updating-a-...e-f64384b799e7
Référence foireuse... En effet, je lit :
"We currently process 5,000+ PostgreSQL transactions per second across multiple clusters."
Donc encore une fois, pas une base mais plusieurs !

https://www.postgresql.org/community...esql-database/
La communauté PG présente de nombreuses données fausses (paratronic, CAF...). En particulier cet article sans aucune référence de "clients" contactables ne peut être vérifiée....

https://sudonull.com/post/212847-The...-on-PostgreSQL
Cette étude est plus intéressante car c'est bien un aveux d'échec des perf de PostGreSQL :
"The Postgres code has been modified to work with such huge amounts of information..."
C'est bien ce que je disais dans mes posts précédent : absence de big table et d'index verticaux....

Après si tu n'écoutes que les vendeurs de sql server, ils vont te dire que pg est nul, etc, etc... forcément.

Sans doute, mais je n'ai jamais vendu aucun produit d'aucun éditeur... Pas même Microsoft !

A +

[SQLpro]

Bonjour,

MeteoFrance gère de grosses bases de données avec PostgreSQL, sans broncher.
Ne croyez pas forcément tout ce qu'on vous annonce de manière péremptoire...

Arrêtons les contre vérités....
"
Actuellement, l’infrastructure bases de données chez Météo-France est composée de plus de 100 serveurs PostgreSQL,10 serveurs Rack Oracle (3 clusters) pour une volumétrie de 80TB.
"
même sans retirer les bases Oracle cela ferait 800 Go par base en moyenne.... Comme je pense que les serveurs oracle ont BEAUCOUP pus de données que les PG (ne serait-ce que par le fait de leur ancienneté)... je parierais sur environ 200 Go par base, ce qui est déjà pas mal pour du PostGreSQL !
Michel Edwell, Ingénieur DBA à la direction des systèmes d'information de Météo-France

[ced]

En 5 ans, MeteoFrance a poursuivi son travail de migration d'Oracle vers PostgreSQL, ce qui est d'ailleurs rappelé dans le témoignage le plus récent.

Je suis bien d'accord avec vous : "Arrêtons les contre-vérités" !

À +

[SQLpro]

Regardez juste les dates des deux interviews... 2015 pour celle de Michel Edwell, 2020 pour celle de David Peyrieres...
En 5 ans, MeteoFrance a poursuivi son travail de migration d'Oracle vers PostgreSQL, ce qui est d'ailleurs rappelé dans le témoignage le plus récent.

Je suis bien d'accord avec vous : "Arrêtons les contre-vérités" !

À +

NON, c'est toujours une multitude de clusters PG et non une seule base. Désolé mais je suis au parfum sur cette affaire !

A +

[ced]

Quelqu'un dans le groupe aurait-il une expérience postgres (version community ou payante) avec une base de plus de 30To?
J'aimerais avoir une idée de la capacité de postgres à gérer de très grosse bases de données afin d'affiner mes choix.

Le mieux, c'est de contacter directement les personnes citées dans les articles présentés...
Eux sont réellement au parfum...

@+

[SQLpro]

Tout à fait d'accord !

A +

[martial.kiba]

Bonsoir,

Merci à tous pour vos différentes contributions.

J'avais contacté Enterprise DB directement, en demandant des références.

Ils ont dit qu'ils savaient gérer une base de cette taille, et m'ont même demandés un jeu de requêtes pour m'aider à dimensionner la plateforme.

Après cela, ils m'ont directement envoyé une cotation en disant qu'ils faut un paiement avant qu'ils puisse avancer.

Du coup, moi j'ai pas trouvé ça très pro, et j'ai lâché l'affaire (en plus des commentaires ici, ça me rassure pas).

Merci encore à tous.

[carosim]

Qui, si ma calculette est bonne, me dit qu’en moyenne chaque serveur héberge 80 Go de données ! Mesure parfaitement réaliste, qui échappe à beaucoup d’internautes vantant les mérites d’un PostGreSQL hébergeant plusieurs To de données… rumeur, rumeur, quand tu nous tiens… !

Bonjour,

Je suis désolée mais votre calculette vous fait prendre des raccourcis un peu rapide.

C'est dommage de venir faire un laïus sans la connaissance sur ce sujet. Plusieurs entreprises ont des gros volumes MAIF et MGEN, et il y en a d'autres.

Dans tous les cas, l'idéal, est de contacter ces entreprises, ils vous parleront au mieux du sujet.

A+

[escartefigue]

[*]Tag de requête interdit. Dès que le plan de requête devient très complexe, alors il faut parfois donner un coup de pouce en utilisant un "hint" (tag de requête) pour forcer le moteur à adopter une certaines stratégie algorithmique. Bien que le recours à ce stratagème ne soit pas toujours très conseillé, il est utile, notamment en urgence ou pour corriger un plan déficient. PG interdit ce genre de choses (c'est le seul SGBDR a avoir cette position radicale et imbécile). Mais certaines versions payantes de PG le propose...

Les "Hints" sont indispensables dans certains cas de figure, les interdire est un gros défaut

[*]VACUMM bloquant. MVCC crée des lignes fantômes liées au versionnement du verrouillage optimiste. Ces lignes sont créées dans les mêmes pages que les lignes "vivantes", ce qui les alourdit considérablement. Il faut alors allez nettoyer ces pages des lignes fantômes, mais cela nécessite un verrou bloquant les pages durant le nettoyage (opération VACUUM). En pratique cette opération s'avère lourde et génère de nombreux verrous mortel. Impossible à utiliser dans une base fortement transactionnelle.

Probablement le défaut principal de PG.

[SQLpro]

...J'avais contacté Enterprise DB directement, en demandant des références.

Ils ont dit qu'ils savaient gérer une base de cette taille, et m'ont même demandés un jeu de requêtes pour m'aider à dimensionner la plateforme.

Après cela, ils m'ont directement envoyé une cotation en disant qu'ils faut un paiement avant qu'ils puisse avancer.

Du coup, moi j'ai pas trouvé ça très pro, et j'ai lâché l'affaire (en plus des commentaires ici, ça me rassure pas).

Merci encore à tous.

Pour information, Microsoft dispose d'un data center de test qui est gratuit pour les nouveaux projets...

A +