Discussion :

[nicooooo1]

Bonjour,

A priori, je suis amené à stocker des données dans une table SQL Server (environ 14 champs). Le contenu de cette table devrait être d'environ 11 000 000 de lignes par an pour une durée de 15 ans. Comment estimer les ressources matérielles nécessaires ? et surtout les performances SQL Server, sachant que des recherches vont être réalisées sur cette table (sur des champs de type date et/ou varchar) ? Quelles solutions existent afin d'améliorer ou de s'assurer des performances à venir ? Est-ce préférable de prévoir une table sur un an glissant et une seconde pour le stockage longue durée ? Faut-il s'orienter vers une autre solution que SQL Server ?

Merci d'avance pour vos retours ou vos pistes

[escartefigue]

Bonsoir

11 millions de lignes par an sur 15 ans, soit 165 millions ce n'est pas gigantesque, si les critères de recherche sont filtrants et sargables *, la réponse peut être quasi immédiate.
Par contre, avec une telle volumétrie, le partitionnement est recommandé.

14 Colonnes (les champs n'existent pas dans les tables relationnelles) ce n'est pas beaucoup, mais surtout, il faut savoir quel est le type et la longueur de ces colonnes.
Certains types sont très couteux en stockage (BLOB notamment), d'autres très économiques (small, int et bigint).

SQL server supportera sans aucun souci cette volumétrie

* Sargable : Search Argument Able prédicat correspondant à un ou plusieurs index et éligible pour ces index

[SQLpro]

Pas forcément besoin de partitionnement, mais je recommanderais que la table, si elle est unique soit mise en clustered columnstore, ce qui améliore considérablement les performances (en général division par 4 à 20 des temps de réponse par rapport aux index traditionnels).

Voir cependant de quelle édition de SQL Server il s'agit. En effet, mieux vaut utiliser SQL Server 2019, mais l'édition Standard limite à 32 Go les index columnstore.... Bon, comme les index columstore sont naturellement compressés (3 à 10 fois moins volumineux), je pense que cette limitation avec une table de moins de 200 millions de ligne et 15 colonnes, ne sera jamais atteinte !

Pour information, voici la différence pour une table de 1 250 000 lignes et 17 colonnes en version normale (clustered BTree) et clustered columnstore:

On y voit que le stockage occupe 42 Mo... au lieu de 251 soit un ratio de compression de 6...

Avec 300 millions de ligne cette table occuperait moins de 12 Go (la compression n'étant pas linéaire, plus la table a de lignes, plus la compression est importante !). Donc loin de la limite des 32 Go...


A +

[nicooooo1]

Super, merci pour vos retours ! je vais étudier le partitionnement et le clustered columnstore.

Je me demande aussi comment estimer les capacités serveur (CPU/RAM) ?

[SQLpro]

Le CPU est plus fonction du nombre de users et de transactions.
La Ram si base parfaitement modélisée 10%, modéle à chier 120 %

A +