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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Capacité à gérer de très gros volumes de données


Sujet :

PostgreSQL

  1. #1
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    décembre 2017
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Burkina Faso

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : décembre 2017
    Messages : 16
    Points : 14
    Points
    14
    Par défaut Capacité à gérer de très gros volumes de données
    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.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    décembre 2017
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Burkina Faso

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : décembre 2017
    Messages : 16
    Points : 14
    Points
    14
    Par défaut
    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é.

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par martial.kiba Voir le message
    ....
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    décembre 2017
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Burkina Faso

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : décembre 2017
    Messages : 16
    Points : 14
    Points
    14
    Par défaut
    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

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par martial.kiba Voir le message
    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.

  8. #8
    ced
    ced est actuellement connecté
    Rédacteur/Modérateur

    Avatar de ced
    Homme Profil pro
    Gestion de bases de données techniques
    Inscrit en
    avril 2002
    Messages
    5 967
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Gestion de bases de données techniques
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2002
    Messages : 5 967
    Points : 23 557
    Points
    23 557
    Par défaut
    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...
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  9. #9
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    novembre 2007
    Messages
    1 818
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 818
    Points : 6 432
    Points
    6 432
    Billets dans le blog
    1
    Par défaut
    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.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  11. #11
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par ced Voir le message
    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
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  12. #12
    ced
    ced est actuellement connecté
    Rédacteur/Modérateur

    Avatar de ced
    Homme Profil pro
    Gestion de bases de données techniques
    Inscrit en
    avril 2002
    Messages
    5 967
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Gestion de bases de données techniques
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2002
    Messages : 5 967
    Points : 23 557
    Points
    23 557
    Par défaut
    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" !

    À +
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  13. #13
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par ced Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  14. #14
    ced
    ced est actuellement connecté
    Rédacteur/Modérateur

    Avatar de ced
    Homme Profil pro
    Gestion de bases de données techniques
    Inscrit en
    avril 2002
    Messages
    5 967
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Gestion de bases de données techniques
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : avril 2002
    Messages : 5 967
    Points : 23 557
    Points
    23 557
    Par défaut
    Citation Envoyé par martial.kiba Voir le message
    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...

    @+
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  15. #15
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    Tout à fait d'accord !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  16. #16
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    décembre 2017
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Burkina Faso

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : décembre 2017
    Messages : 16
    Points : 14
    Points
    14
    Par défaut
    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.

  17. #17
    Candidat au Club
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    septembre 2022
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 36
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : septembre 2022
    Messages : 1
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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+

  18. #18
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 995
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 995
    Points : 33 706
    Points
    33 706
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    [*]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


    Citation Envoyé par SQLpro Voir le message
    [*]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.

  19. #19
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 301
    Points : 51 012
    Points
    51 012
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par martial.kiba Voir le message
    ...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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Toutes versions] concaténation optimisée (très gros volume de données)
    Par L'Albatros dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 04/05/2012, 20h40
  2. Réponses: 3
    Dernier message: 11/05/2007, 14h47
  3. [Recherche texte sur gros volume de données]
    Par tesla dans le forum Algorithmes et structures de données
    Réponses: 8
    Dernier message: 21/02/2007, 14h43
  4. Structure de données pour gros volume de données
    Par white_angel_22 dans le forum Langage
    Réponses: 9
    Dernier message: 01/02/2007, 12h58
  5. Gérer le gros volume de données
    Par berceker united dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 21/07/2006, 20h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo