Optimisation des performances pour une grande table (SQL Server 2008 R2)

14

Contexte:
J'ai une table de faits en phase UAT. Objectif de charger 5 ans de données dans Prod (taille attendue 400 Mn d'enregistrements). Actuellement, il n'a que 2 ans de données en test.

Caractéristiques de la table:

  1. Nombre de dimensions ~ 45
  2. Mesures ~ 30
  3. Mesures non additives et autres colonnes ~ 25
  4. Taille actuelle des données ~ 200 millions (données sur 2 ans)
  5. Affichage de l'heure: 3 vues de mois différentes: fiscales / calendrier / ajustées (c'est-à-dire que la même ligne peut tomber dans des mois différents en fonction de la vue recherchée)
  6. Une seule vue sera requise à la fois par un utilisateur. (c'est-à-dire qu'une seule colonne de mois sera utilisée dans la requête, cela nous empêche de faire le partitionnement sur la vue temporelle)
  7. Index: 1 index groupé sur les clés naturelles (8 colonnes) .Créé 3 couvrant les index non groupés un sur chaque colonne de mois, y compris quelques dimensions SK (FK) et toutes les mesures).
  8. Les index sont énormes (190 Go au total) pour cette raison.
  9. L'espace n'est pas une contrainte (1 To alloué)
  10. 64 Go de RAM disponibles sur le serveur.
  11. La compression de table a également été effectuée.

Exigence: Les
requêtes sur ce tableau de faits doivent donner un résultat dans les 30 secondes (les requêtes générales sélectionnent la somme (mesure) joignant quelques groupes Dims par valeurs Dim). Les rapports se font directement en haut de ce tableau de faits.

Problème:
toute requête qui inclut des colonnes disponibles dans l'index fonctionne très bien, mais si nous incluons d'autres colonnes qui ne sont pas dans le include..It suce. Cela prend plus de 5 à 10 minutes. Quelqu'un peut-il suggérer une solution où cela fonctionne bien pour n'importe quelle dimension / colonne que nous sélectionnons. Index peut-il voir l'aide dans cette situation?

sql-server-2008-r2 user1801862
la source

Réponses:

6

Mettez à niveau vers SQL Server 2012 et utilisez des colonnes de magasins . Ils prospèrent dans ces exigences. Sérieusement, téléchargez l' édition d'évaluation et essayez-la. Supprimez tous les index, supprimez l'index cluster, ajoutez simplement un index columnstore non cluster sur toutes les colonnes et donnez-lui un tourbillon. J'ai vu des cas comme le vôtre qui ont réduit le temps d'exécution à 2-3 secondes, principalement en raison de l' élimination des segments . Certaines lectures supplémentaires:

Remus Rusanu
la source
0

Une vue indexée résoudra-t-elle votre problème? Dans quelle mesure les données doivent-elles être à jour? Vous pouvez créer une vue indexée pour quelques permutations. Mais avec autant de dimensions et de mesures, vous risquez de manquer rapidement d'espace!

Que diriez-vous d'utiliser des SSD?

Nick.McDermaid
la source
Les données seront mises à jour chaque mois. Combien de temps faut-il pour mettre à jour la vue?
Si votre requête existante prend 5 à 10 minutes, la vue indexée prendra 5 à 10 minutes. Une fois terminé, lorsque vous exécutez la même requête, elle reviendra comme si elle sortait d'une table (c'est-à-dire immédiatement). Une vue indexée pré-exécute un bit particulier de SQL. Si vous soumettez du SQL qui lui correspond, il le prend dans la vue indexée, plutôt que de l'exécuter à nouveau. Le principal avantage d'une vue indexée est que vous n'avez pas besoin de modifier vos requêtes existantes, elles l'utiliseront automatiquement. L'inconvénient est que vous devez à peu près en créer un pour quelques combinaisons différentes.
Nick.McDermaid
Mais je ne vous suggère pas de créer plusieurs vues indexées pour accélérer les choses - vous finirez par manquer de temps et d'espace disque. Ce pourrait être une chose à mettre dans votre arsenal.
Nick.McDermaid
et s'il vous plaît ... regardez dans les colonnes comme suggéré!
Nick.McDermaid