Dostrajanie wydajności dla ogromnej tabeli (SQL Server 2008 R2)

14

Tło:
Mam tabelę faktów w fazie UAT. Cel, aby załadować 5 lat danych do Prod (oczekiwany rozmiar rekordów 400 Mn). Obecnie ma tylko 2 lata danych w teście.

Funkcje stołu:

  1. Liczba wymiarów ~ 45
  2. Środki ~ 30
  3. Miary nieaddytywne i inne kolumny ~ 25
  4. Obecny rozmiar danych ~ 200 milionów (dane z 2 lat)
  5. Widok czasu: 3 różne widoki miesiąca: Fiskalny / Kalendarz / Skorygowany (tj. Ten sam wiersz może przypadać w różnych miesiącach, w zależności od tego, którego widoku szukasz)
  6. Użytkownik będzie wymagał tylko jednego widoku na raz. (tzn. w zapytaniu zostanie użyta tylko jedna kolumna miesiąca, co powstrzymuje nas przed partycjonowaniem w widoku czasu)
  7. Indeksy: 1 indeks klastrowany na klawiszach naturalnych (8 kolumn). Utworzono 3 obejmujące indeksy nieklastrowane po jednym na kolumnę każdego miesiąca, w tym kilka SK wymiarów (FK) i wszystkie miary).
  8. Z tego powodu indeksy są ogromne (łącznie 190 GB).
  9. Miejsce nie jest ograniczeniem (przydzielono 1 TB)
  10. 64 GB pamięci RAM dostępnej na serwerze.
  11. Wykonano również kompresję tabeli.

Wymaganie:
Kwerendy w tej tabeli faktów powinny dać wynik w ciągu 30 sekund (zapytania ogólne wybierają sumę (miarę) łączącą kilka grup Dims według wartości Dim). Raporty są sporządzane bezpośrednio na podstawie tabeli faktów.

Problem:
każde zapytanie zawierające kolumny dostępne w Indeksie działa poprawnie, ale jeśli uwzględnimy inne kolumny, których nie ma w Uwzględnij ... To jest do bani. Zajmuje to więcej niż 5-10 minut. Czy ktoś może zasugerować jakieś rozwiązanie, w którym działa dobrze dla dowolnego wybranego wymiaru / kolumny. Czy indeks może wyświetlić pomoc w tej sytuacji?

użytkownik1801862
źródło

Odpowiedzi:

6

Uaktualnij do SQL Server 2012 i korzystaj z magazynów kolumnowych . Rozwijają się w tych wymaganiach. Poważnie, pobierz wersję testową i spróbuj. Porzuć wszystkie indeksy, upuść indeks klastrowany, po prostu dodaj nieklastrowany indeks magazynu kolumn do wszystkich kolumn i nadaj mu wir. Widziałem przypadki takie jak twoje, które skróciły czas wykonania do 2-3 sekund, głównie z powodu rozpoczęcia eliminacji segmentów . Niektóre dodatkowe informacje:

Remus Rusanu
źródło
0

Czy indeksowany widok rozwiąże Twój problem? Jak aktualne muszą być dane? Możesz utworzyć widok indeksowany dla kilku permutacji. Ale przy tak wielu wymiarach i miarach możesz szybko zabraknąć miejsca!

Co powiesz na używanie dysków SSD?

Nick.McDermaid
źródło
Dane będą aktualizowane co miesiąc. Ile czasu zajmie zaktualizowanie widoku?
Jeśli twoje istniejące zapytanie zajmuje 5-10 minut, widok indeksowany zajmie 5-10 minut. Po zakończeniu, gdy uruchomisz to samo zapytanie, wróci ono tak, jakby wychodziło ze stołu (tj. Natychmiast). Widok indeksowany wstępnie uruchamia określony fragment kodu SQL. Jeśli prześlesz SQL, który pasuje do niego, pobierze go z widoku indeksowanego, zamiast uruchamiać od nowa. Główną zaletą widoku indeksowanego jest to, że nie trzeba zmieniać istniejących zapytań, one automatycznie go wykorzystają. Wadą jest to, że musisz stworzyć jedną dla kilku różnych kombinacji.
Nick.McDermaid
Ale nie sugeruję, aby tworzyć wiele indeksowanych widoków, aby przyspieszyć - ostatecznie zabraknie czasu i miejsca na dysku. To może być jedna rzecz, którą możesz umieścić w swoim arsenale.
Nick.McDermaid
i proszę ... zajrzyj do sklepów z kolumnami zgodnie z sugestiami!
Nick.McDermaid