Mój proces ETL zbiera i przekształca dane w bazie DB z faktami i wymiarami. Dlaczego więc powinienem z tego zbudować kostki? Czy istnieje więcej niż tylko szybkość zaletami zapytań i wstępnie agregacji wartości?

Dziękuję za pomoc

1
naheliegend 21 listopad 2020, 16:04

1 odpowiedź

Najlepsza odpowiedź

Fakty i wymiary są tabelami, które można zbudować w niemal każdej relacyjnej bazie danych. Aby poprawić wydajność, możesz budować agregujące tabele faktów w tej samej relacyjnej bazy danych. Tabele te są ogólne w tym, przy bardzo małym wysiłku można przenieść te stoły z Oracle do SQL Server, jako przykład.

Zgodnie z uproszczeniem, kostka jest rodzajem kruszywa tabeli faktów, ale jest zbudowana w wielowymiarowej bazie danych i jest normalnie specyficzna dla tego smaku bazy danych. Więc jeśli zbudujesz kostkę w SSA, nie możesz go przenieść do Hyperion Essbase.

W przypadku prostego zapytania, takie jak kwota transakcji sumy według daty, kostki nie dają ci wiele / żadnych korzyści na faktach. W przypadku złożonych zapytań wydajność ma tendencję do bycia znacznie lepszym niż z faktami.

Kostki zwykle wspierają swój własny język zapytań (np. SSAS i Dax), które umożliwiają znacznie bardziej złożone zapytania niż można normalnie napisać w SQL (bez dużo wysiłku)

Więc czy powinieneś zbudować kostki, zależy od wielu czynników, takich jak:

  • Czy prowadzisz wiele złożonych zapytań, które działałyby lepiej w kostce?
  • Czy poprawiła wydajność byłaby warta wysiłku / kosztów?
  • Czy istnieje przypadek kosztów / korzyści do wdrażania bazy danych MOLAP (Cube), a także bazy danych wymiarowej? Kostki są zwykle zaludnione z faktów / wymiarów, więc są one dodatkiem, a nie zamiennikiem, faktami / wymiarami
2
NickW 22 listopad 2020, 11:44