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

Décisions SGBD Discussion :

Impact du volume de donnée sur les performances.


Sujet :

Décisions SGBD

  1. #1
    Membre à l'essai
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2012
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : février 2012
    Messages : 5
    Points : 11
    Points
    11
    Par défaut Impact du volume de donnée sur les performances.
    Bonjour,

    Je suis dev back dans une petite agence web, et pour la première fois de ma carrière, je me retrouve dans la position de référent technique pour les choix de techno, d'archi, et tout le toutim.
    Ça fait donc presque un an que je suis passé dans une phase ou j'essaye de comprendre plus en profondeur les outils que j'utilise, et plus seulement faire de la production avec.

    Bref, venant s'en au sujet.

    Suite à la dernière demande d'un client, je me suis rendu compte que je n'avais aucune idée de l'impact que pouvait avoir une entrée "massive" de données dans une bdd, ni même comment évaluer une charge de donnée tout court.
    J'ai beaucoup de mal à trouver des ressources à ce sujet.

    Dans le cas présent, j'ai une app avec une petite bdd, (une 15ene de tables, < 100k entrées) et forcement, c'est très réactif, ça fonctionne très bien.
    Seulement, là, je doit ajouter une fonctionnalité qui va rajouter potentiellement +300k entrées dans une table par trimestre et j'ai beaucoup de mal à évaluer l'impact que ça va avoir sur les performances de ma bdd (c'est du PostGres).

    Ça me parais beaucoup (ça ne l'est peut être pas), et j'ai envie d'externaliser la feature dans un microservice avec sa propre base mais je sous-estime peu être les capacités d'un SGBD.

    Est ce qu'il existe des méthodes pour évaluer ça, autre que le doigt mouillé ou l'xp?

    Merci.

  2. #2
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 571
    Points : 33 387
    Points
    33 387
    Billets dans le blog
    13
    Par défaut
    Bonjour,
    Ces articles ont quelques années mais vous trouverez des infos chez SQLPro. De mémoire, c'est dans la partie "Optimisation" (descendez la colonne de gauche vers le bas de la page).
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #3
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    8 043
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 8 043
    Points : 16 164
    Points
    16 164
    Par défaut
    Citation Envoyé par Exeldo Voir le message
    Seulement, là, je doit ajouter une fonctionnalité qui va rajouter potentiellement +300k entrées dans une table par trimestre et j'ai beaucoup de mal à évaluer l'impact que ça va avoir sur les performances de ma bdd (c'est du PostGres).
    Ca reste du petit volume (à moins que votre table ait 1000 colonnes).
    Vérifiez bien vos index et envisagez de partitionner cette table, cela pourrait s'avérer avantageux pour les requêtes d'extraction.

    Pour vous faire une première idée, il faut raisonner en espace occupé par votre base de données vs la RAM allouée à votre SGBD.
    Tant que vous avez plus de RAM que de base, vraiment c'est sans soucis, et vous êtes certainement dans ce cas-là.

  4. #4
    Membre à l'essai
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2012
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : février 2012
    Messages : 5
    Points : 11
    Points
    11
    Par défaut
    Merci, pour le lien SQLpro
    C'est très intéressant.

    Si je comprend bien, je reste dans dans la case petit volume de donnée. Et dans mon cas de figure, c'est surtout les capacités et la configuration du serveur qui héberge la db qui va jouer.

    Ça me rassure ^^
    Merci beaucoup pour vos réponses.

  5. #5
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 470
    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 : 20 470
    Points : 48 324
    Points
    48 324
    Par défaut
    La notion de volume est relative à la croissance des technologies informatiques liée à la loi de Moore.

    • On considère comme petite toute base tenant sur la RAM d'un serveur physique. Acheter un serveur physique ayant moins de 32 Go de RAM relève aujourd'hui de la gageure... ça coute presque plus cher qu'avec 64 Go de RAM. En conclusion une petite base c'est aux alentours de 64 Go.
    • Une moyenne tient sur un disque magnétique ultra rapide (SAS) par exemple. Donc aux alentours de quelques centaines de Go
    • Une grosse évolue sur les plus gros disques magnétique ou SSD rapides, disons aux alentours de 4 à 6 To
    • Quant aux très grosses bases elles tournent aux alentours de plusieurs dizaines de To


    Attention cependant. Tous les SGBDR ne sont pas taillés pour être utilisées par de grosses bases, ni par un fort volume transactionnel ni encore par de très nombreux utilisateurs.
    Les 3 SGBDR suivant utilisent couramment des bases de plusieurs dizaines de To voire plusieurs centaines, y compris avec une forte activité transactionnelle et pour des milliers d'utilisateurs : Oracle database, MS SQL Server et IBM DB2
    PostGreSQL doit être limité à quelques centaines de Go et une centaines d'utilisateurs et surtout pas en 24h/24 7j/7 à pleine charge
    MySQL doit être limité à quelques dizaines de Go et quelques dizaines d'utilisateurs et surtout pas en 24h/24 7j/7 à pleine charge

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

  6. #6
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    4 016
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 4 016
    Points : 7 185
    Points
    7 185
    Billets dans le blog
    1
    Par défaut
    Je suis un peu surpris quand même qu'on ne parle "que" des données.

    Quels sont les traitements ?

    En effet, une table contenant des milliards de lignes, avec des ajouts de plusieurs millions par jours restera extrêmement véloce du moment qu'on utilise un index simple (clé unique int64 par exemple, ou index unique sur un timestamp, etc.) et qu'on fait des opérations simples dessus (accès à une ligne à la fois par exemple, pas de concurrence de transactions, etc.).

    En revanche, base avec quelques tables de quelques milliers de lignes peu rapidement devenir une limace desséchée si on commence à se lancer dans des transactions concurrentes portant sur de gros volumes de données, des agrégations et fonctions de fenêtrage dans tous les sens, pendant qu'on y est, un peu de pivot aussi, etc.

    Bref, si dans ta base tu stockes les coordonnées des satellites autour de la terre, tu n'auras que quelques centaines de milliers de lignes grand max... si tu commences à faire des calculs de trajectoire pour déterminer à quel endroit mettre en place un nouveau satellite sans risque une collision, ça pourrait bien mettre plusieurs jours à te retourner une ligne.

    Alors qu'à l'inverse, si tu stockes dans ta base tous les articles de tous les dépôts d'Amazon, et tu auras bien plus de lignes que dans la base des satellites, en moins d'un millième de second tu sauras quel produit se trouve dans le dépôt A, travée 7 rangée E étage 12. Tout comme il ne te faudra pas plus de temps pour savoir où trouver la paire de chaussettes en taille 42 la plus proche de ton magasinier, même sur un serveur qui a 10 ans.

    Aussi, n'importe quelle table de plus de 100 000 lignes avec des LIKE comme critères de recherche va plonger le serveur dans une profonde léthargie.
    On ne jouit bien que de ce qu’on partage.

  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
    20 470
    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 : 20 470
    Points : 48 324
    Points
    48 324
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    ...
    En revanche, base avec quelques tables de quelques milliers de lignes peu rapidement devenir une limace desséchée si on commence à se lancer dans des transactions concurrentes portant sur de gros volumes de données, des agrégations et fonctions de fenêtrage dans tous les sens, pendant qu'on y est, un peu de pivot aussi, etc.....
    Là encore tout dépend des techniques intégrées aux SGBDR et la qualité desdites techniques : partitionnement, vues indexées, colonnes calculées, verrouillage optimiste, table de graphe, compression, indexation verticale...
    par exemple, si la plupart des SGBDR intègrent aujourd'hui le partitionnement, les performances du partitionnement n'ont rien à voir entre SQL Server qui fait systématiquement du parallélisme sur les partitions, alors que la notion de parallélisme est inconnue de MySQL et de PostGreSQL (à ce niveau)....

    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
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 359
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 359
    Points : 16 965
    Points
    16 965
    Par défaut
    Citation Envoyé par Exeldo Voir le message
    Suite à la dernière demande d'un client, je me suis rendu compte que je n'avais aucune idée de l'impact que pouvait avoir une entrée "massive" de données dans une bdd, ni même comment évaluer une charge de donnée tout court.
    Est ce qu'il existe des méthodes pour évaluer ça, autre que le doigt mouillé ou l'xp?
    Merci.
    i lfaudrait préciser de quelle bdd il s'agit.
    Cela n'a rien à voir avec l'expérience , c'est certain que si l'applicatif utilise une bdd genre Acess alors il faut monter vers plus gros comme SQL-Server ou Oracle voire AWS
    Qu'est ce qui est petit et marron ? Un marron ( Kaamelott)

  9. #9
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    4 016
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 4 016
    Points : 7 185
    Points
    7 185
    Billets dans le blog
    1
    Par défaut
    C'est indiqué dans le message d'origine : PostgreSQL

    Mais je maintiens que l'utilisation de la base a au moins autant d'importance que sa volumétrie.
    On ne jouit bien que de ce qu’on partage.

  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
    20 470
    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 : 20 470
    Points : 48 324
    Points
    48 324
    Par défaut
    Citation Envoyé par Exeldo Voir le message
    ...c'est du PostGres...
    Pour information, je déconseille totalement PostGreSQL dans les cas suivants :
    • forte volumétrie (plus de quelques centaines de Go), mettons à ce jour 300.
    • plusieurs centaines d'utilisateurs
    • fonctionnement 24h/24 sans heures creuses


    En dehors de ces cas, PostGreSQL est le meilleur SGBD relationnel du monde libre.

    je prépare un long article sur le sujet pour contrer cet article qui est un tissus d'âneries, fake news et imbécilité en tout genre :
    https://www.enterprisedb.com/blog/mi...at-differences
    Cet article ayant été publié par Enterprise DB qui vend du PostgreSQL "amélioré"....

    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
    Membre averti
    Profil pro
    Inscrit en
    mars 2010
    Messages
    346
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2010
    Messages : 346
    Points : 429
    Points
    429
    Par défaut
    J'ai hate de voir votre article! Je me suis re-mis recemment a SQL Server justement dans le but d'evaluer une base de plusieurs dizaine de TO

  12. #12
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 571
    Points : 33 387
    Points
    33 387
    Billets dans le blog
    13
    Par défaut
    Moi qui ne connais pas bien SQL Server, et après avoir lu jusqu'au premier tableau, j'ai bien l'impression en effet que l'article de Entreprise DB est bourré de conneries sur SQL Server !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  13. #13
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    4 016
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 4 016
    Points : 7 185
    Points
    7 185
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Moi qui ne connais pas bien SQL Server, et après avoir lu jusqu'au premier tableau, j'ai bien l'impression en effet que l'article de Entreprise DB est bourré de conneries sur SQL Server !
    J'adore la comparaison de syntaxe !
    Celle de l'alias, je ne suis même pas sûr qu'elle exste dans la documentation de SQL Server
    Nom : connerie_sql.png
Affichages : 50
Taille : 51,9 Ko

    Quant à la comparaison des types, y'a à boire, à manger... et surtout à vomir !

    Ils arrivent quand même à parler de NTEXT et IMAGE qui sont deprecated depuis plusieurs versions !
    On ne jouit bien que de ce qu’on partage.

  14. #14
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 470
    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 : 20 470
    Points : 48 324
    Points
    48 324
    Par défaut
    C'est pas le pire, mais c'est déjà gratiné !!!!

    Pour info... Extrait concernant cette page :

    Also the below syntax given by the author:

    Does not exists in SQL Server and throw an exception:

    Msg*102, Niveau*15, État*1, Ligne*2
    Incorrect syntax near '='.


    Which proves that the author does not even check his own writings... The correct old fashionned and unusued syntax is

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT avg1=AVG(col1) ...

    Mon article va faire à peu près 4 fois la taille de l'original.....

    Parution, la semaine prochaine, probablement mardi

    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. [2008] Impact sur les performance de l'ODBC ?
    Par Sergejack dans le forum Développement
    Réponses: 1
    Dernier message: 11/08/2010, 00h00
  2. Impact sur les performances d'un grand nombre de tables
    Par thechief dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 16/07/2010, 17h47
  3. Impact du double archive log sur les performances du système ?
    Par condor_01 dans le forum Administration
    Réponses: 5
    Dernier message: 22/05/2008, 15h08
  4. Impact du CLASSPATH sur les performances
    Par Rei Angelus dans le forum Langage
    Réponses: 10
    Dernier message: 12/03/2008, 17h12
  5. Réponses: 2
    Dernier message: 13/11/2007, 11h32

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