Quel est le meilleur moyen de gérer un grand nombre de tables dans MS SQL Server?

Question

Cette question est liée à une autre:
Le fait d'avoir plusieurs groupes de fichiers aidera-t-il à accélérer ma base de données?

Le logiciel que nous développons est un outil analytique utilisant MS SQL Server 2005 pour stocker des données relationnelles. L'analyse initiale peut être lente (car nous traitons des millions, voire des milliards de lignes de données), mais le rappel rapide des analyses précédentes étant soumis à des exigences de performance, nous "sauvegardons" les sauvegardes. résultats de chaque analyse.

Notre approche actuelle consiste à enregistrer les résultats de l'analyse dans une série de "tests spécifiques à l'exécution". tables, et l'analyse est suffisamment complexe pour que nous puissions avoir jusqu'à 100 tables par analyse. Habituellement, ces tables utilisent quelques centaines de Mo par analyse (ce qui est petit comparé à nos centaines de Go, voire plusieurs TB de données source). Mais dans l’ensemble, l’espace disque n’est pas un problème pour nous. Chaque ensemble de tableaux est spécifique à une analyse et, dans de nombreux cas, cela nous apporte d’énormes améliorations de performances par rapport au renvoi aux données source.

L'approche commence à se dégrader une fois que nous avons accumulé suffisamment de résultats d'analyse sauvegardés - avant d'ajouter une capacité d'archivage / nettoyage plus robuste, notre base de tests a grimpé à plusieurs millions de tables. Mais il n’est pas exagéré pour nous d’avoir plus de 100 000 tables, même en production. Microsoft impose une limite théorique assez énorme à la taille des sysobjects (environ 2 milliards de dollars), mais lorsque notre base de données dépasse 100 000 personnes environ, des requêtes simples comme CREATE TABLE et DROP TABLE peuvent être considérablement ralenties.

Nous avons un peu de marge pour débattre de notre approche, mais je pense que cela pourrait être difficile de faire sans plus de contexte, alors je voudrais plutôt poser la question plus généralement: si nous sommes obligés de créer autant de tables, quel est le meilleur approche pour les gérer? Plusieurs groupes de fichiers? Plusieurs schémas / propriétaires? Plusieurs bases de données?

Autre remarque: je ne suis pas enchanté par l'idée de "lancer simplement du matériel sur le problème". (c’est-à-dire l’ajout de RAM, de puissance de l’UC, de vitesse du disque) Mais nous ne l'excluons pas non plus, surtout si (par exemple) quelqu'un peut nous dire de manière définitive quel effet l'ajout de RAM ou l'utilisation de plusieurs groupes de fichiers aura sur la gestion d'un catalogue système volumineux.

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 un " bases de données " tableau faisant référence à un ou plusieurs "exécuter" bases de données, chacune contenant des ensembles distincts de résultats d'analyse. Ensuite, le menu principal " run " table 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 correspondant à toutes les requêtes.

Cette approche permet de rendre le catalogue système de chaque base de données plus raisonnable, de mieux séparer les tables principales / permanentes et les tables dynamiques / d'exécution, tout en facilitant la gestion des sauvegardes et de l'archivage. Cela nous permet également de fractionner nos données sur plusieurs disques physiques, bien que l’utilisation de plusieurs groupes de fichiers l’aurait également fait. Globalement, cela fonctionne bien pour nous à présent, compte tenu de nos exigences actuelles, et, en fonction de la croissance attendue, nous pensons que cela évoluera également pour nous.

Nous avons également constaté que SQL 2008 tend à mieux gérer les catalogues système volumineux que SQL 2000 et SQL 2005. (Nous ne sommes pas passés à 2008 lorsque j'ai posté cette question.)

Answer 2

Sans d'abord voir l'ensemble du système, ma première recommandation serait de sauvegarder les exécutions historiques dans des tables combinées avec un RunID faisant partie 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 la répartir dans d'autres groupes de fichiers.

Une autre possibilité consiste à placer chaque exécution dans sa propre base de données, puis à les détacher, en les attachant uniquement si nécessaire (et sous forme de lecture seule)

CREATE TABLE et DROP TABLE fonctionnent probablement mal car les bases de données master ou model ne sont pas optimisées pour ce type de comportement.

Je vous recommande également de discuter avec Microsoft du choix de conception de votre base de données.

Answer 3

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

S'il s'agit de structures différentes, mais uniquement 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 NULL dans les colonnes non applicables.

S'il s'agit d'une analyse (des calculs de prix dérivés peut-être?), vous pouvez transférer les résultats d'un calcul en fichiers plats et réutiliser vos calculs en les chargeant à partir des fichiers plats.

Answer 4

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èmes et il est donc difficile de commencer à aider. Plusieurs paramètres de solution ne sont pas évidents dans votre message. Par exemple, combien de temps comptez-vous conserver les tables d'analyse d'exécution? Il y a BEAUCOUP d'autres questions à poser.

Vous allez avoir besoin d’une combinaison d’entreposage de données sérieux et de partitionnement de données / tables. Selon la quantité de données que vous souhaitez conserver et archiver, vous devrez peut-être commencer à dénormaliser et à aplatir les tables.

Ce serait un très bon cas où contacter directement Microsoft peut être mutuellement bénéfique. Microsoft obtient de bons arguments à présenter à d'autres clients et vous obtenez de l'aide directement du fournisseur.