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.

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).

Citation:

---

Envoyé par Exeldo

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à.

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.

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 +

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.

Citation:

---

Envoyé par StringBuilder

...
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 +

Citation:

---

Envoyé par Exeldo

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

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.

Citation:

---

Envoyé par Exeldo

...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 +

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 :mouarf:

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 ! :roll:

Citation:

---

Envoyé par CinePhil

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 ! :roll:

---

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 :lol:
Pièce jointe 586567

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 !

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:

Code:

---

SELECT AVG(col1)=avg1

---

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:

---

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 +