Quelle est la meilleure façon de gérer un grand nombre de tables dans MS SQL Server?

Question

Cette question est liée à une autre:
Will having multiple filegroups help speed up my database?

Le logiciel que nous développons est un outil d'analyse qui utilise MS SQL Server 2005 pour stocker des données relationnelles. L'analyse initiale peut être lente (puisque nous traitons des millions ou des milliards de rangées de données), mais il y a des exigences de performance pour rappeler rapidement les analyses précédentes, de sorte que nous «sauvegardons» les résultats de chaque analyse. Notre approche actuelle consiste à enregistrer les résultats d'analyse dans une série de tableaux «spécifiques à l'exécution», et l'analyse est suffisamment complexe pour aboutir à 100 tables par analyse. Habituellement, ces tables utilisent quelques centaines de Mo par analyse (ce qui est faible par rapport à nos centaines de Go, ou parfois plusieurs TB, de données sources). Mais dans l'ensemble, l'espace disque n'est pas un problème pour nous. Chaque ensemble de tables est spécifique à une analyse et, dans de nombreux cas, cela nous apporte d'énormes améliorations de performance par rapport aux données sources. L'approche commence à se décomposer une fois que nous avons accumulé suffisamment de résultats d'analyse sauvegardés - avant que nous ayons ajouté des fonctionnalités d'archivage/nettoyage plus robustes, notre base de tests a atteint plusieurs tables millions. Mais ce n'est pas exagéré d'avoir plus de 100 000 tables, même en production. Microsoft place une limite théorique assez énorme sur la taille des sysobjects (~ 2 milliards), mais une fois que notre base de données dépasse 100 000 ou plus, les requêtes simples comme CREATE TABLE et DROP TABLE peuvent ralentir considérablement. Nous avons de la place pour débattre de notre approche, mais je pense que cela pourrait être difficile à faire sans plus de contexte, donc je veux plutôt poser la question plus généralement: si nous sommes obligés de créer autant de tables, quel est le meilleure approche pour les gérer? Plusieurs groupes de fichiers? Plusieurs schémas/propriétaires? Plusieurs bases de données? Une autre note: Je ne suis pas ravi de l'idée de "jeter simplement du matériel sur le problème" (c'est-à-dire d'ajouter de la RAM, de la puissance du processeur, de la vitesse du disque). Mais nous ne l'exclurons pas non plus, surtout si (par exemple) quelqu'un peut nous dire définitivement quel effet ajouter de la RAM ou utiliser plusieurs groupes de fichiers aura sur la gestion d'un grand catalogue système.

Answer 1

Nous avons fini par diviser notre base de données en plusieurs bases de données. La base de données principale contient donc une table de "bases de données" qui fait référence à une ou plusieurs bases de données "exécutées", chacune contenant des ensembles distincts de résultats d'analyse. Ensuite, la table principale "run" contient un ID de base de données, et le code qui récupère un résultat enregistré inclut le préfixe de base de données pertinent sur toutes les requêtes. Cette approche permet au catalogue système de chaque base de données d'être plus raisonnable, d'assurer une meilleure séparation entre les tables core/permanentes et les tables dynamiques/run, ainsi que de rendre les sauvegardes et l'archivage plus gérables. Cela nous permet également de diviser nos données sur plusieurs disques physiques, même si l'utilisation de plusieurs groupes de fichiers l'aurait également fait. Dans l'ensemble, cela fonctionne bien pour nous maintenant compte tenu de nos exigences actuelles, et en fonction de la croissance prévue, nous pensons que cela va bien évoluer pour nous aussi.

Nous avons également remarqué que SQL 2008 a tendance à mieux gérer les grands catalogues système que SQL 2000 et SQL 2005. (Nous n'avions pas mis à niveau vers 2008 lorsque j'ai posté cette question.)

Answer 2

Cela semble être un problème/une application très intéressant avec lequel vous travaillez. J'aimerais travailler sur quelque chose comme ça. :)

Vous avez une très grande surface de problème et il est difficile de commencer à vous aider. Il y a plusieurs paramètres de solution qui ne sont pas évidents dans votre message. Par exemple, combien de temps prévoyez-vous de conserver les tables d'analyse d'exécution? Il y a beaucoup d'autres questions à poser.

Vous aurez besoin d'une combinaison de stockage de données sérieux et de partitionnement de données/tables. En fonction de la quantité de données que vous souhaitez conserver et archiver, vous devrez peut-être commencer à normaliser et à aplatir les tables.

Ce serait un très bon cas où contacter Microsoft directement peut être mutuellement bénéfique. Microsoft obtient une bonne affaire pour montrer d'autres clients, et vous obtenez de l'aide directement du fournisseur.

Answer 3

Les tables sont-elles toutes différentes structures? Si elles sont la même structure, vous pourriez vous en sortir avec une seule table partitionnée.

S'il s'agit de structures différentes, mais seulement de sous-ensembles du même ensemble de colonnes de dimension, vous pouvez toujours les stocker dans des partitions de la même table avec des valeurs nulles dans les colonnes non applicables.

Si cela est analytique (calculs de prix de produits dérivés peut-être?) vous pouvez exporter les résultats d'un calcul vers des fichiers plats et réutiliser vos calculs en les chargeant à partir des fichiers plats.

Answer 4

Sans voir d'abord le système entier, ma première recommandation serait de sauvegarder les historiques dans les tables combinées avec un RunID dans le cadre de la clé - un modèle dimensionnel peut également être pertinent ici. Cette table peut être partitionnée pour amélioration, ce qui vous permettra également de répartir la table dans d'autres groupes de fichiers.

Une autre possibilité à mettre chaque terme dans sa propre base de données, puis les détacher, ne les attacher au besoin (et sous forme de lecture seule)

CREATE TABLE et DROP TABLE exécutent probablement mal parce que le maître ou les bases de données de modèles ne sont pas optimisées pour ce type de comportement.

Je recommande également de parler à Microsoft de votre choix de conception de base de données.