Approches du partitionnement de table dans SQL Server

Question

La base de données avec laquelle je travaille a actuellement une taille de plus de 100 Go et promet d'augmenter beaucoup plus au cours de l'année à venir. J'essaye de concevoir un schéma de partitionnement qui fonctionnera avec mon ensemble de données mais jusqu'ici j'ai échoué lamentablement. Mon problème est que les requêtes sur cette base de données testent généralement les valeurs de plusieurs colonnes dans cette grande table, se retrouvant dans des ensembles de résultats qui se chevauchent de manière imprévisible. Tout le monde (les DBA avec lesquels je travaille) met en garde contre l'utilisation de tables d'une certaine taille et j'ai recherché et évalué les solutions que j'ai trouvées, mais elles semblent toutes dépendre d'une caractéristique de données permettant partitionnement de table. Malheureusement, je ne vois pas de moyen d'y parvenir compte tenu de la structure de mes tables.

Voici la structure de nos deux tables principales pour mettre cela en perspective.

Table: Case 
Columns: 
Year 
Type 
Status 
UniqueIdentifier 
PrimaryKey 
etc. 

Table: Case_Participant 
Columns: 
Case.PrimaryKey 
LastName 
FirstName 
SSN 
DLN 
OtherUniqueIdentifiers 

Notez que l'une des colonnes ci-dessus peuvent être utilisés comme paramètres de requête.

Answer 1

Plutôt que de deviner, mesurez. Rassemblez les statistiques d'utilisation (queries run), regardez les propres statistiques du moteur comme sys.dm_db_index_usage_stats et ensuite vous prenez une décision éclairée: la partition qui offre le meilleur équilibre entre la taille des données et la meilleure affinité pour les requêtes les plus souvent exécutées sera un bon candidat. Bien sûr, vous devrez faire des compromis. N'oubliez pas que partitioning est par index (où 'table' = l'un des index), pas par table, donc la question n'est pas de savoir sur quoi partitionner, mais quel index partitionner ou pas et quel partitionnement fonction à utiliser. Vos index clusterisés sur les deux tables seront évidemment les candidats les plus probables (pas très logique de partitionner juste un index non clusterisé et pas de partitionner le cluster) donc, à moins que vous ne réfléchissiez à la refonte de vos clés en cluster, la question est vraiment ce que la fonction de partitionnement à choisir pour vos index en cluster. Si j'oserais deviner je dirais que pour toute donnée qui s'accumule au fil du temps (comme les «cas» avec une «année») la partition la plus naturelle est le sliding window.

Answer 2

Si vous n'avez pas d'autre choix, vous pouvez partitionner par module clé le nombre de tables de partition. Disons que vous voulez partitionner à 10 tables. Vous définirez tables:
Case00
Case01
...
Case09

Et vous partitionner les données par UniqueIdentifier ou un module PrimaryKey 10 et placer chaque enregistrement de la table correspondante (En fonction de votre UniqueIdentifier vous unique, pourrait avoir besoin de démarrer l'allocation manuelle des identifiants). Lors de l'exécution d'une requête, vous devez exécuter la même requête sur toutes les tables et utiliser UNION pour fusionner l'ensemble de résultats en un résultat de requête unique.

Ce n'est pas aussi bon que de partitionner les tables en fonction d'une séparation logique qui correspond à la requête attendue, mais il est préférable d'atteindre la limite de taille d'une table.

Answer 3

Une autre chose à observer (avant le partitionnement) est votre modèle.

Êtes-vous dans une base de données normalisée? Y a-t-il d'autres étapes qui pourraient améliorer les performances par différents choix dans la normalisation/de/partielle-normalisation?Existe-t-il des options pour transformer les données en un modèle en étoile dimensionnel de type Kimball, optimal pour les rapports/requêtes? Si vous n'allez pas supprimer des partitions de la table (fenêtre coulissante, comme mentionné) ou traiter différentes partitions différemment (vous dites que des colonnes peuvent être utilisées dans la requête), je ne suis pas sûr de ce que vous essayez pour sortir du partitionnement que vous ne retirerez pas déjà de votre stratégie d'indexation.

Je ne connais aucune limite de table sur les lignes. AFAIK, le nombre de lignes est limité uniquement par le stockage disponible.