2009-11-04 11 views
5

Mam bazę danych zawierającą tabele z ponad 600 milionami rekordów i zestawem procedur składowanych, które powodują skomplikowane operacje wyszukiwania w bazie danych. Wydajność procedur przechowywanych jest tak powolna, nawet z odpowiednimi indeksami w tabelach. Projekt bazy danych jest normalnym projektem relacyjnej bazy danych. Chcę zmienić projekt bazy danych na wielowymiarowy i używać zapytań MDX zamiast tradycyjnych zapytań T-SQL, ale pytanie brzmi: Czy zapytanie MDX jest lepsze niż tradycyjne zapytanie T-SQL pod względem wydajności? i jeśli tak, w jakim stopniu poprawi to wydajność zapytań?Wydajność MDX a T-SQL

Dzięki za pomoc.

+0

powiązane: http://stackoverflow.com/questions/42483/simulated-olap/42504#42504 –

Odpowiedz

13

Jabłka i pomarańcze: usługa analityczna Kostka OLAP jest zasadniczo innym typem pamięci niż baza danych SQL Server i jest zaprojektowana do robienia różnych rzeczy. Technicznie MDX nie jest "szybszy" niż T-SQL, i na odwrót - są to tylko języki, ale zaprojektowane pod kątem różnych potrzeb.

Po tym, moduł zazwyczaj najlepiej sprawdza się przy analizie danych statycznych, takich jak agregacja dużej liczby transakcji/transakcji/dowolnych rekordów w czasie. W przeciwieństwie do tradycyjnej relacyjnej bazy danych na ogół działa dobrze, jeśli schemat i indeksy są dobrze skonstruowane, do wyszukiwania. Prostym sposobem na sędziego: jeśli zapytań SQL trzeba zrobić dużo

select grock, sum/min/max/avg(foo) 
from bar 
group by grock -- Ideal Analysis Services problem 

następnie kostka może pomóc (jest ono przeznaczone dla zagregowanych funkcji matematycznych - suma() i grupy przez). OTOH jeśli zapytań zrobić wiele

select cols 
from foo 
where <complicated search> -- Not so much 

następnie kostka prawdopodobnie nie pomoże, a ja zamiast koncentrować się na strojenie schematu, zapytań i indeksowania, a może stołowego partycjonowanie jeśli dane mogą być odpowiednio podzielona.

Czy istnieje indeks klastrowy i obejmuje indeksy nieklastrowane, które pasują do zapytań?

2

„Realizacja procedur przechowywanych jest tak powolny, nawet z odpowiednimi indeksami”

byłbym zaskoczony, jeśli procedura składowana jest prawdziwy problem, może sposób wykorzystywane są procedury jest powolny, ale procedura przechowywana z definicji nie spowalnia. Czy dowiedziałeś się, że twoje procedury są powolne? Czy masz profilowane? Zanim przeprojektuję swoją bazę danych, przyjrzę się temu dokładnie. Wielowymiarowe bazy danych dla OLAP to Twoja baza danych wyłącznie jako baza danych OLAP lub czy jest to hybryda OLAP i OLTP? A może potrzebujesz znormalizować i zreplikować dane w projekcie OLTP w strukturę normalizacyjną? 600 milionów rekordów w tabeli nie jest w żadnym razie ogromne, nie jest małe, ale nie pozwala mi wierzyć, że upuszczenie zapisanych procedur spowoduje magiczne przyspieszenie. Zapoznaj się z przechowywanymi procami i zobacz, gdzie znajdują się wąskie gardła wydajności, zanim przejdziesz do większego projektu, aby rozwiązać problem.

+0

proste zapytanie jak: [wybierz ID z artykułów, w których NazwaKategorii się ('A' "B", "C")] z indeksem na CategoryName zajmuje około 60 sekund, aby uzyskać wynik. Przy okazji baza danych zawiera tylko statyczne dane, ale została zaprojektowana jako baza danych OLTP. –

+0

Co to za plan zapytania? Ile wierszy powraca? Czy indeks kolumny jest indeksowany? Wejście IN ("A", "B", "C") nie będzie mogło korzystać z indeksu. – Kuberchaun

+0

Oto link zawierający porady na wysokim poziomie, które mogą być przydatne http://blogs.techrepublic.com.com/datacenter/?p=173 – Kuberchaun

6

MS SSAS kostki OLAP mogą być wykorzystywane w kilku trybach składowania:

  1. relacyjne (OLAP) - dane i metadane pozostaje w DB i niewiele więcej zmaterializowane perspektywy są dodawane. Może lub nie może być szybciej.

  2. Hybryd (HOLAP) - agregacje metadanych i (wstępnie obliczone) są przechowywane na nowym serwerze z uruchomioną instancją SSAS. Powinno to przyspieszyć wszystkie zapytania przy użyciu agregacji, np. "Całkowite godziny pracy za ostatni rok po miesiącu", ale zapytania, które przewiercą dane do konkretnych rekordów, mogą być takie, jak wcześniej.

  3. Wielowymiarowy OLAP (MOLAP), w którym wszystkie dane oraz metadane i agregacje są kopiowane na serwer SSAS. Jest to zwykle najszybszy, ale zduplikowany magazyn.

Przed rozpoczęciem tego należy wziąć pod uwagę optymalizację ci tabela układu do raportowania i analiz, innymi słowy używać hurtowni danych (DW) - umieścić swoje dane w wymiarze gwiazdy Kimball i faktycznych tabel. Następnie ładujesz plik DW za pomocą ETL (SSIS) okresowo i kierujesz raporty i analizy do pliku DW. Może się zdarzyć, że nie musisz w ogóle korzystać z SSAS - zapytania SQL działające w oparciu o układ tabel gwiazdowych są zwykle znacznie szybsze niż w przypadku znormalizowanej DB - operacyjnej bazy danych. Jeśli to nadal trwa zbyt wolno, zbuduj kostki SSAS na górze DW. Po rozpoczęciu ładowania pliku DW można usunąć rekordy z operacyjnej bazy danych, co przyspieszy codzienne użytkowanie.
Podsumowując, moja zasada brzmi:
1. Zbuduj DW i ustaw proces ETL
2. Spróbuj raportów T-SQL przeciwko DW, może to być wystarczająco dobre.
3. Jeśli nadal działa wolno, buduj kostki SSAS (na górze DW) w trybie HOLAP i używaj MDX do ich odpytywania.