Index clusterisés et columnstore
Je viens de commencer un nouveau travail où nous avons de nombreuses tables issues de processus ETL. On m'a dit de ne mettre aucun columnstore ou index cluster sur aucune table car le serveur n'a pas les ressources (CPU). Donc, fondamentalement, tout est en tas. Il existe des index non groupés sur de nombreux tabels. Nous obtenons des données de nombreux systèmes sources et une fois que les données ont atterri, nous les transformons et les combinons ...
Je veux juste savoir si cela sonne bien dans certains paramètres de ne pas utiliser de columnstore ou d'index groupés. L'utilisation d'index clusterisés nécessite-t-elle plus de processeur lorsque les tables sont utilisées pour l'analyse?
Réponses
Presque toutes les décisions de mise en œuvre sont un compromis entre des facteurs concurrents. La création d'un index columnstore est gourmande en ressources processeur, mais par la suite, les requêtes touchant de nombreuses lignes sont rapides et les mises à jour sont lentes. Qu'est-ce qui est le plus important pour votre charge de travail, en moyenne? Y a-t-il une fenêtre de temps dans laquelle cette quantité de CPU peut être consommée sans casser d'autres parties du système? Le coût supplémentaire est-il remboursé dans les prestations futures? Quel est le problème auquel un columnstore est la solution, et cela a-t-il été abordé dans d'autres aspects du système?
Vous mentionnez ETL. Souvent, ces tables ne sont traitées que comme des analyses où chaque ligne est touchée par chaque opération. Dans de tels cas, les index ralentiront le traitement car ils doivent être écrits en plus de la table.
Il y a probablement des raisons aux restrictions actuelles. Comprenez pourquoi ils ont été mis en place. Si ces circonstances ne tiennent plus (peut-être une mise à niveau de la version du serveur ou un meilleur matériel maintenant), essayez une expérience dans un environnement de test.