Ottimizzazione delle prestazioni per una tabella enorme (SQL Server 2008 R2)


14

Sfondo:
ho una tabella dei fatti in fase UAT. Obiettivo caricare 5 anni di dati in Prod (dimensioni previste 400 record Mn). Attualmente ha solo 2 anni di dati in Test.

Caratteristiche del tavolo:

  1. Numero di dimensioni ~ 45
  2. Misure ~ 30
  3. Misure non additive e altre colonne ~ 25
  4. Dimensione attuale dei dati ~ 200 milioni (dati di 2 anni)
  5. Time View: 3 diverse visualizzazioni Mese: Fiscale / Calendario / Rettificato (ovvero la stessa riga può cadere in diversi mesi in base alla vista che si sta cercando)
  6. L'utente richiederà solo una vista alla volta. (ad es. nella query verrà utilizzata solo una colonna del mese, ci sta impedendo di eseguire il partizionamento nella visualizzazione temporale)
  7. Indici: 1 indice cluster sulle chiavi naturali (8 colonne) .Creato 3 che copre gli indici non cluster uno sulla colonna di ogni mese, inclusi pochi SK dimensione (FK) e tutte le misure).
  8. Gli indici sono enormi (190 GB in totale) per questo motivo.
  9. Lo spazio non è vincolo (1 TB assegnato)
  10. 64 GB di RAM disponibili nel server.
  11. Anche la compressione della tabella è stata eseguita.

Requisito: le
query su questa tabella dei fatti dovrebbero dare il risultato entro 30 secondi (le query generali selezionano la somma (misura) che unisce alcuni gruppi di dimensioni per i valori di dimensione). I rapporti vengono eseguiti direttamente in cima a questa tabella dei fatti.

Problema:
qualsiasi query che include colonne disponibili nell'indice funziona correttamente, ma se includiamo altre colonne che non sono incluse ... Fa schifo. Ci vogliono più di 5-10 minuti. Qualcuno può suggerire qualche soluzione in cui funziona bene per qualsiasi dimensione / colonna che selezioniamo. Index può visualizzare aiuto in questa situazione?

Risposte:


6

Eseguire l'aggiornamento a SQL Server 2012 e utilizzarlo columnstore . Prosperano in questi requisiti. Seriamente, scarica l' edizione di valutazione e provala. Rilascia tutti gli indici, elimina l'indice cluster, aggiungi semplicemente un indice columnstore non cluster su tutte le colonne e fai un vortice. Ho visto casi come il tuo che hanno ridotto il tempo di esecuzione a 2-3 secondi, principalmente a causa dell'inizio dell'eliminazione del segmento . Alcune letture supplementari:


0

Una vista indicizzata risolverà il tuo problema? Quanto devono essere aggiornati i dati? È possibile creare una vista indicizzata per alcune permutazioni. Ma con tutte quelle dimensioni e misure potresti esaurire rapidamente lo spazio!

Che ne dici di usare SSD?


I dati verranno aggiornati ogni mese. Quanto tempo ci vorrà per aggiornare la vista?

Se la query esistente richiede 5-10 minuti, la visualizzazione indicizzata richiederà 5-10 minuti. Al termine, quando si esegue la stessa query tornerà come se uscisse da una tabella (cioè immediatamente). Una vista indicizzata pre-esegue un determinato bit di SQL. Se si invia SQL corrispondente, lo prende dalla vista indicizzata, anziché eseguirlo nuovamente. Il vantaggio principale di una vista indicizzata è che non è necessario modificare le query esistenti, che verranno utilizzate automaticamente. Lo svantaggio è che devi crearne uno per alcune combinazioni diverse.
Nick.McDermaid,

Ma non ti suggerisco di andare a creare più viste indicizzate per accelerare le cose - alla fine rimarrai senza tempo e spazio su disco. Potrebbe essere solo una cosa da mettere nel tuo arsenale.
Nick.McDermaid,

e per favore ... guarda nelle colonne come suggerito!
Nick.McDermaid,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.