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

Administration PostgreSQL Discussion :

Nombre de connexions max - dizaines de milliers de connexions


Sujet :

Administration PostgreSQL

  1. #1
    Membre confirmé Avatar de Aizen64
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    561
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 561
    Points : 462
    Points
    462
    Par défaut Nombre de connexions max - dizaines de milliers de connexions
    Bonjour,

    j'ai lu quelques infos sur le sujet et pourtant j'ai bien du mal à trouver une réponse claire à ma question, est-ce potentellement délicat pour un serveur dédié aujourd'hui de gérér des dizaines de milliers d'utilisateurs avec du SELECT ? Prenons un exemple, un site acceulllant 50 000 utilisateurs.

    Bien sur, tout dépend des ressources du serveur, j'ai juste tendance à penser que vu la puissance de calcul actuelle, faire ce type d'opération n'est pas si compliqué.

    Quelqu'un a des infos claires sur le sujet à partager ?
    Exprimer une différence d'opinion vaut mieux que :

  2. #2
    Membre éclairé Avatar de Arkhena
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 552
    Points : 769
    Points
    769
    Par défaut
    Bonjour,

    "50 000 utilisateurs qui font du SELECT", ça ne veut malheureusement pas dire grand chose (même si je suis bien consciente que vous avez galéré pour obtenir ne serait-ce que cette information).
    Ce qui est important, c'est
    - le nombre d'utilisateurs simultanés (en moyenne et en pointe)
    - le temps de réponse moyen des SELECT effectués
    - s'il y a des écritures en même temps qui risquent de poser des verrous sur les données lues
    - le dimensionnement de la machine (ou des machines en cas de load balancing sur des Hot Standbys)

    En gros, le nombre de connexions simultanées maximum est lié au paramètre max_connections (https://www.postgresql.org/docs/9.6/...onnection.html) qu'on peut setter différemment en fonction du matériel qu'on a.

    Cordialement,

    Arkhena
    A bove ante, ab asino retro, a stulto undique caveto

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool.

    Les gros SGBDR commerciaux supportent en pratique plusieurs dizaines de milliers de connexions simultanées, car il utilisent un pooler interne mais il faut que le serveur soit bien dimensionné. Par exemple sur le serveur d'Eurydile (registre du commerce) nous avions des pointes à plus de 30 000 connexions simultanées sur un serveur à 64 cœurs hyperthreadé (donc 128 vcore). Mais c'est du MS 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/ * * * * *

  4. #4
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 590
    Points
    3 590
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool...
    Encore de la désinformation gratuite. Et encore une confirmation de ce que vaut l'homme et de ce qu'il dit.
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  5. #5
    Membre régulier
    Homme Profil pro
    test
    Inscrit en
    Mai 2016
    Messages
    343
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Algérie

    Informations professionnelles :
    Activité : test
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Mai 2016
    Messages : 343
    Points : 121
    Points
    121
    Par défaut
    @sqlpro vous été payé de microsoft pour faire ces types de publicités ?

  6. #6
    Membre éclairé Avatar de Arkhena
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 552
    Points : 769
    Points
    769
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Pour information, en pratique, PostGreSQL a du mal à supporter plusieurs centaines d'utilisateurs simultanés, et dans ce cas, même en lui rajoutant un "pooler" de connexion comme PGpool.
    Bonjour SQLPro,

    Je ne demande qu'à vous croire, mais je suis comme Saint Thomas... Pouvez-vous m'expliquer ce qui vous fait penser cela ?

    Cordialement,

    Arkhena
    A bove ante, ab asino retro, a stulto undique caveto

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

    Citez moi une seule application documentée avec plusieurs milliers d'utilisateurs en transactionnel sous PostGreSQL et sur un seul serveur et je ferais mon mea culpa !

    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/ * * * * *

  8. #8
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

    Donc "le bon coin" perdrait volontairement plusieurs milliers d'euros par an en infrastructure juste pour éviter un SGBDR commercial... tout en restant gratuit pour pas mal de particuliers. Sont-ils subventionnés par de généreux mécènes anti-SQL server ?
    Est-ce vraiment la seule raison ? Ont-ils une autre contrainte qui ne serait pas supportée par un seul serveur avec SGBDR commercial ?

    Cela semble assez peu plausible, pour des raisons purement idéologiques, non ?
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  9. #9
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 590
    Points
    3 590
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Un exemple simple... Demandez vous pourquoi "le bon coin" utilise plus de 100 serveurs postGreSQL en // pour leur service d'annonce là ou d'autres sites beaucoup plus lourds (fnac.com, cdiscount, ventresprivées...) n'en utilise qu'un seule et en plus avec gestion de transactions financières (panier, commandes, factures, BL, etc...) ?

    Citez moi une seule application documentée avec plusieurs milliers d'utilisateurs en transactionnel sous PostGreSQL et sur un seul serveur et je ferais mon mea culpa !

    A +
    Faisons l'inverse...
    Donne-nous l'aveu officiel de "le bon coin" sur ce choix, on fera le mea-culpa.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  10. #10
    Membre éclairé Avatar de Arkhena
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 552
    Points : 769
    Points
    769
    Par défaut
    Bonjour,

    Je suis désolée SQL-Pro, je crois qu'on s'est mal compris... Je voulais une preuve, non un exemple...

    Cordialement,

    Arkhena
    A bove ante, ab asino retro, a stulto undique caveto

  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 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    J'aime beaucoup la bêtise de certains...
    Citation Envoyé par Arkhena Voir le message
    Je suis désolée SQL-Pro, je crois qu'on s'est mal compris... Je voulais une preuve, non un exemple...
    Il n'est pas possible de donner une preuve négative. Même en justice... En effet prouver la non existence nécessiterait d'arrêter tous les projets de la terre, en faire un exemple exhaustif et constater que cela n'existe pas. C 'est pourquoi je vous ais montré le preuve du contraire !

    Croyez vous que ce soit pas masochisme que le bon coin utilise plus de 120 serveur PG ? Non, c'est tout simplement que la "scalability" verticale de PG est très mauvaise. Ceci est d'ailleurs confirmé par les développeurs du noyau PG eux même dans cet article :
    https://wiki.postgresql.org/wiki/Sim...pment_Projects
    En particulier le processus VACUUM... ou il est dit que :
    VACUUMs are clearly a problem for VLDBs,

    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/ * * * * *

  12. #12
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 590
    Points
    3 590
    Billets dans le blog
    8
    Par défaut
    "Science sans honnêteté n'est que ruine de l'âme"
    Citation Envoyé par SQLpro Voir le message
    Il n'est pas possible de donner une preuve négative.
    pour autant on ne peut pas compter le nombre de fois que tu as surmonté cette impossibilité.
    Citation Envoyé par SQLpro Voir le message
    Croyez vous que ce soit pas masochisme que le bon coin utilise plus de 120 serveur PG ? Non, c'est tout simplement que la "scalability" verticale de PG est très mauvaise.
    des allégations sans fondement et qui n'ont rien a avoir avec "nombre max de connections"
    Citation Envoyé par SQLpro Voir le message
    Ceci est d'ailleurs confirmé par les développeurs du noyau PG eux même
    FAUX,
    This page contains details of a number of development projects that I'm either working on or planning to work on in the next Development Cycle.
    Well, it did once. This was last updated in about 2010.
    Sont les propos d'un individu et n'engage que lui. Par ailleurs, vous voulez nous faire consommer un avis de 2010!!!
    Citation Envoyé par SQLpro Voir le message
    VACUUMs are clearly a problem for VLDBs,
    La récupération des espaces morts est inhérente à tous les SGBDR. C'est un choix judicieux mais qui à ces inconvénients surtout avec les grosses bases de données (VLDB).
    Amène quelque chose de plus honnête...
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  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 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par alassanediakite Voir le message
    La récupération des espaces morts est inhérente à tous les SGBDR. C'est un choix judicieux mais qui à ces inconvénients surtout avec les grosses bases de données (VLDB).
    Amène quelque chose de plus honnête...@+
    Tout à fait, mais cela est minimal dans SQL Server par exemple car :
    • soit il n'y a pas de versionnement des lignes (verrouillage pessimiste) donc aucun espace mort lié aux copies des lignes
    • soit en mode snapshot (verrouillage optimiste) la version des lignes est gérée dans la tempdb, donc pas dans les bases de production...

    Cela n'est donc ni pénalisant ni bloquant au contraire du VACUUM de PG.

    En sus la récupération des espaces mort peu se faire en mode ON LINE, sans blocage...
    • ALTER TABLE ma_table REBUILD WITH ( ONLINE = ON )
    • ALTER INDEX mon_index ON ma_table WITH ( ONLINE = ON )


    Ce qui n'est pas le cas dans PG...

    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
    Membre confirmé Avatar de Aizen64
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    561
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 561
    Points : 462
    Points
    462
    Par défaut
    OK, merci pour vos réponse.

    Je n'ai jamais eu à considérer ces questions de performance auparavant d'où mes questions, quelques infos supplémentaires :
    - en moyenne :
    => nombre de lignes retournées par requête : 30.
    => nombreuses jointures comme BDD complexe.
    => temps de réponse d'une requête HTTP lors d'un allez retour au SGBD, les 2 étant sur un serveur différent : 500 ms.
    => temps d'INSERT/UPDATE via WS : en localhost : > 1 seconde, ce qui me parait énorme alors que je n'ai que 2 ou 3 connexions actives. Les perfs sont équivalentes en prod.

    Le reste de mon argumentaire mais je le pose quand même, l'ignorance n'est pas un crime, alors autant se cultiver.
    Le SQL a été mis en place dans les années 70, le principe est justement de mutualiser l'information et la rendre disponible à différents client, par exemple, de nombreux sites gèrent des dizaines de milliers d'utilisateurs. Les CPU serveur aujourd'hui ont une puissance colossale, idem pour la quantité de RAM, comment peut on expliquer par exemple qu'un CPU serveur avec plus de 10Go de RAM puisse uniquement gérer quelques centaines de connexions ?

    Des explications et articles sont les bienvenus.
    Exprimer une différence d'opinion vaut mieux que :

  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 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Aizen64 Voir le message
    OK, merci pour vos réponse.

    Je n'ai jamais eu à considérer ces questions de performance auparavant d'où mes questions, quelques infos supplémentaires :
    - en moyenne :
    => nombre de lignes retournées par requête : 30.
    Très faible

    => nombreuses jointures comme BDD complexe.
    PostGreSQL n'est pas le plus à l'aise en cette matière. À défaut il sait optmiser à peut près bien une requête pourvue de 12 jointures simples (ne portant que sur col1 = col2) mais on peut le régler à plus au détriment du temps. Au dela son algorithme "geqo" censé réduire le temps de calcul du plan de requête provoque des plans parfois catastrophiques... https://postgresql.developpez.com/do....3.0/geqo.html Rien à voir avec les optimiseurs des gros SGBDR comme Oracle ou mieux encore SQL Server qui savent traiter efficacement des dizaines, voire des centaines de jointures en un temps record...
    => temps de réponse d'une requête HTTP lors d'un allez retour au SGBD, les 2 étant sur un serveur différent : 500 ms.
    ça ne veut rien dire, il faudrait diagnostiquer les différents temps, et en cette matière PG ne dispose d'aucun outil au contraire par exemple de SQL Server ou, sur une requête, on peut savoir à quel endroit on perd du temps : disque, RAM, réseau, CPU, attente de verrouillage, de méta données, de claul de plan de gestion du cache, etc... https://www.brentozar.com/sql/wait-stats/

    => temps d'INSERT/UPDATE via WS : en localhost : > 1 seconde, ce qui me parait énorme alors que je n'ai que 2 ou 3 connexions actives. Les perfs sont équivalentes en prod.
    Cela dépend de la journalisation, mais PostrGreSQL n'utilise qu'un seul journal de transaction pour toutes les bases d'un cluster là ou SQL Server utilise un journal par base, voire plus (un journal distinct pour les tables temporaires). Là encore le manque d'outil de PG le redn difficile à diagnostiquer...

    Le reste de mon argumentaire mais je le pose quand même, l'ignorance n'est pas un crime, alors autant se cultiver.
    Le SQL a été mis en place dans les années 70,
    Non, vous confondez 3 choses :

    le principe est justement de mutualiser l'information et la rendre disponible à différents client, par exemple, de nombreux sites gèrent des dizaines de milliers d'utilisateurs. Les CPU serveur aujourd'hui ont une puissance colossale, idem pour la quantité de RAM, comment peut on expliquer par exemple qu'un CPU serveur avec plus de 10Go de RAM puisse uniquement gérer quelques centaines de connexions ?
    Un SGBDR est par nature très consommateurs de ressources de toutes nature :
    1) RAM pour la mise en cache des données, des métadonnées des plans de requêtes et du code interprété... les connexions consommant chacune de la mémoire....
    2) DISQUE pour le stockage des données et la journalisation des transactions
    3) CPU pour le calculs des plans de requêtes, la gestion du cache, les algorithmes de parcours de données et de calculs (jointures, agrégats...)
    Le problème est de distinguer d'un côté, les connexions au serveur, qui peuvent être "dormantes" et sont toujours en nombre limitées et pour les gros SGBDR (Oracle : 2 048, SQL Server : 32 767) gérés par pool, et d'un autre côté les requêtes exécutées simultanément. En standard PG n'ayant pas de mécanises de pooling, cela dépend du hardware, mais rares sont les installations supportant en pratique plusieurs centaines de connexions. https://wiki.postgresql.org/wiki/Num...se_Connections
    Pour obtenir d'excellentes performances, les gros SGBDR (Oracle, DB2, SQL Server) dispose d'un OS interne qui gère les threads, la RAM et les accès disque (ils ne passant pas par l'OS hôte, mais accède directement aux disques/SAN par des routines de bas niveau). Par exemple dans SQL Server l'OS interne est appelé SOS (cela ne s'invente pas !!! ;-)

    Des explications et articles sont les bienvenus.
    Aujourd'hui dans ma clientèle, un serveur moyen s'installe avec 256 Go de RAM et 24 à 32 cpu et pour le stockage, en général, il dépasse le TO d'emblée.
    Personnellement j'ai du revoir mes outils interne il y a 18 mois (je fais beaucoup d'audit de bases SQL Server) et donc mon PC de dev est un HP Z840 avec 2 CPU XEON 12 cœurs multithreadés (donc 48 cœurs logiques), 128 Go de RAM (que je dois porter à 256 dans les semaines qui viennent), 8 disques SAS en RAID 10 pour un stockage de 4 To, 2 dsques SSD de 1 To en RAID 1 sur port PCI, et deux NAS en réseau escsi de 24 To (QNAP).

    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 confirmé Avatar de Aizen64
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    561
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 561
    Points : 462
    Points
    462
    Par défaut
    Si on revient une dizaine d'années en arrière, allez au début des années 2000, comment les gros sites géraient leurs traffic ? Des centaines d'instance de SGBD répliqués ?
    Exprimer une différence d'opinion vaut mieux que :

  17. #17
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Aizen64 Voir le message
    Si on revient une dizaine d'années en arrière, allez au début des années 2000, comment les gros sites géraient leurs traffic ? Des centaines d'instance de SGBD répliqués ?
    Pour info le plus gros site web marchand français était la fnac et à démarré avec 4 serveurs MS SQL Server 2000 en parallèle; Aujourd'hui il y en as 8. Le problème du "scale out" c'est qu'il faut répliquer une bonne partie des donné&es de la base ce qui est très couteux. On essaye de faire l'inverse au départ : "scale up", c'est à dire partir sur des gros serveurs sui ont beaucoup de RAM de disques et de CPU.

    Le pooling sert à faire patienter les connexions et donc les déconnecter en les mettant en réserve, dès qu'il n'y a plus de raison de maintenir une connexion chaude.

    Par exemple le dernier gros serveur que j'ai installé pour un opérateur télécom mobile avait 1 To de RAM, 128 cpu et 80 To de disques composé de la sorte :
    • 2 cartes fusion IO de 2 To (en RAID 1) sur port PCI (soit 2 To)
    • 16 disques SSD interne de 1 To en RAID 1 (soit 8 To)
    • baie SAN dédiée de 64 disques SAS de 1,2 To à 10 krpm en RAID 10 (soit 38 To)
    • seconde baie SAN dédiée de 32 disques SATA de 8 To en RAID 1 (soit 128 To)


    Ceci afin d'assumer la volumétrie des données et des sauvegardes avec du stockage qui va du très chaud (SSD) au tiède (SATA).

    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/ * * * * *

  18. #18
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2008
    Messages
    2 947
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 2 947
    Points : 5 846
    Points
    5 846
    Par défaut
    Citation Envoyé par Arkhena Voir le message
    - s'il y a des écritures en même temps qui risquent de poser des verrous sur les données lues
    Non, les SELECT ne sont pas bloqués par les écritures concurrentes.

    Table-level Lock Modes
    ACCESS EXCLUSIVE

    Conflicts with locks of all modes (ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE). This mode guarantees that the holder is the only transaction accessing the table in any way.

    Acquired by the ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, and VACUUM FULL commands. This is also the default lock mode for LOCK TABLE statements that do not specify a mode explicitly.

    Tip: Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.

  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 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par skuatamad Voir le message
    Non, les SELECT ne sont pas bloqués par les écritures concurrentes.
    Tout dépend du mode de verrouillage...
    Par défaut dans PostGreSQL, le mode de verrouillage est le mode optimiste qui se traduit par un versionnement de lignes et donc ne bloque pas les écritures, sauf dans le cas de la lecture des métadonnées.

    Dans certaines bases, c'est le mode pessimiste par défaut (Access, Sybase, MS SQL Server). Donc une lecture bloque les écritures.

    Certaines bases permettent les deux, il suffit de les paramétrer correctement. C'est le cas de SQL Server.

    Mode optimiste...
    • Avantage : pas de blocage des écritures par les lectures
    • Inconvénient : perte possible de mise à jour, volumétrie accrue due à la génération des versions de ligne, augmentation de la durée des traitements du fait de la génération des copies pour les versions


    Mode pessimiste...
    • Avantage : une fois engagée, la mise à jour sera effectuée, durée transactionnelle moindre, volumétrie stable
    • Inconvénient : blocage des écritures par les lectures


    Le mieux étant évidemment de pouvoir jouer sur les deux, ce que PG ne sait pas faire.... Et la gestion des copies de lignes est assez mal faite dans PG (VACUUM...)

    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/ * * * * *

Discussions similaires

  1. [Débutant] Comment indiquer le nombre de connexions max a un service web
    Par PascalCmoa dans le forum Services Web
    Réponses: 2
    Dernier message: 22/02/2013, 12h59
  2. [HSQLDB / Pool JDBC] Nombre de connexions max
    Par prisonier dans le forum JDBC
    Réponses: 10
    Dernier message: 14/02/2013, 18h37
  3. Définir le nombre de caractères max d'un JTextField
    Par mitje dans le forum Composants
    Réponses: 4
    Dernier message: 20/01/2006, 17h48
  4. Comment modifier le nombre de caractere max d'un textearea?
    Par Death83 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 8
    Dernier message: 12/09/2005, 12h06
  5. Réponses: 2
    Dernier message: 27/08/2005, 17h12

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