Discussion :

[Kloun]

Bonjour,

J'ai actuellement 3 bases de données comportant les données de différents systèmes.
Ces 3 bases doivent fusionner en 1 seule.
Les temps de réponses sont aujourd'hui encore acceptable mais j'ai peur que ça ne soit plus le cas dans le futur, d'autant plus que la volumétrie est amenée à croître.
J'ai ainsi une table comportant 15,5 millions, 54,5 millions et 16,5 millions de lignes (soit pas loin de 90 millions de lignes dans la table cible ...)

Comment puis-faire pour ne pas dégrader les performances, voire les améliorer ?
Toutes les idées sont les bienvenues.

Merci.

[mikedavem]

Bonjour,

Scinder vos données dans une seule base ne veut pas forcément dire que vous aurez plus de problèmes de performances. Il faudrait d'abord tester ceci en amont avant la mise en production (Je pense que vous avez déjà pensé à cela).

Avoir des millions de ligne ne veut pas dire grand chose non plus ... il faudrait plutôt voir le nombre de pages de vos tables (ou la volumétrie si vous préférez). Si vous avez une bonne stratégie d'indexation et de restriction des données à ramener côté requêtes (clause WHERE avec prédicats sargables), vous ne devriez pas avoir (en principe) de problèmes.

++

[zinzineti]

Il faut faire un test dans un environnement d'intégration par exemple avant toutes choses ...

[Kloun]

Merci pour ces réponses.
Je suis bien d'accord que des tests sont nécessaires.
Toutefois, il va falloir déjà un certain temps pour charger les données.
Si je peux éviter de tout de suite partir sur une impasse et gagner ainsi du temps, c'est pas plus mal.

Pour ce qui est des requêtes, dans un premier temps, elles se feront par système source (l'utilisateur doit tout d'abord sélectionner un système source avant d'aller plus loin dans le filtrage).
Mais à terme, cette sélection sautera certainement afin de pouvoir faire des analyses multi-systèmes source (d'où le passage à une seule base).

Pour ce qui est des index, il en existe déjà sur les bases existantes.

Je me demandais par exemple si le partitionnement des grosses tables pouvait apporter un plus ou pas ?

[mikedavem]

On peut envisager le partitionnement qu'à partir du moment où le volume de données à ramener est supérieure à la quantité de RAM disponible pour l'instance SQL Server.

Il vaut mieux commencer par une bonne stratégie d'indexation .. donc de limiter au maximum le volume de données à ramener.

Quelle est la volumétrie des tables "candidates" pour un éventuel partitionnement ?

++

[Kloun]

Je pense que le problème risque de se poser sur 2 tables.
Pour la 1ère, j'ai actuellement au total 5Go, pour la 2nde, 3Go.

[mikedavem]

Et niveau serveur vous avez quoi ?

Personnellement j'ai déjà travaillé sur des tables de plus d'une 100 de Go sans avoir mis en place le partitionnement. Une bonne stratégie d'indexation suffisait et la quantité de données à ramener restait raisonnable. Les requêtes sur ces tables ne justifiaient pas la mise en place d'une telle architecture. Il faut savoir que :

- La mise en place du partionnement complexifie l'administration
- Les plans d'exécution s'en retrouvent changés. Le coût d'exécution peut être plus important que l'exécution de la requête elle même.
- Le partitionnement n'est valable que si les différentes partitions se retrouvent sur des axes physiques différents.

Maintenant je ne dis pas que cela ne sera pas nécessaire chez vous. A vous de voir avec votre existant si le jeu en vaut la chandelle

++