Read Microsoft Word - 17 Jezierski2.doc text version

XI Konferencja PLOUG Kocielisko Padziernik 2005

Porównanie wydajnoci hurtowni danych ROLAP i MOLAP w Oracle 10g

Bartosz Bbel, Julusz Jezierski, Robert Wrembel Politechnika Poznaska, Instytut Informatyki {Bartosz.Bebel, Juliusz.Jezierski, Robert.Wrembel}@cs.put.poznan.pl

Streszczenie

Istotnym czynnikiem branym pod uwag przy wyborze technologii skladowania i przetwarzania danych w hurtowni danych jest wydajno. Do dyspozycji stoj dwa rozwizania: wykorzystanie relacyjnego serwera bazy danych ogólnego przeznaczenia (ROLAP) albo dedykowanego serwera przetwarzania danych wielowymiarowych (MOLAP). System Oracle od kilku wyda wspiera oba te rozwizania. Celem tego artykulu jest przestawienie wyników testów wydajnoci przetwarzania danych z wykorzystaniem obu rozwiza, przeprowadzonych w oparciu o baz danych z testu wydajnociowego TPC-H.

Informacja o autorach

Bartosz Bbel jest pracownikiem naukowym Instytutu Informatyki Politechniki Poznaskiej; obszar zainteresowa to magazyny danych i projektowanie systemów informatycznych. Kieruje projektem Sokrates - system wspierania dydaktyki na wyszej uczelni. Od 2000 r. prowadzi szkolenia w Oracle University. Juliusz Jezierski urodzil si w roku 1968 roku w Poznaniu. W roku 1992 ukoczyl studia na Wydziale Elektrycznym Politechniki Poznaskiej. Po zakoczeniu studiów zostal zatrudniony w Instytucie Informatyki swojej macierzystej uczelni. Obecnie prowadzi zajcia dydaktyczne, bierze udzial w szeregu prac naukowych z zakresu baz danych oraz administruje systemy informatyczne dzialajce w oparciu o serwery Oracle. Robert Wrembel pracuje na stanowisku adiunkta w Instytucie Informatyki Politechniki Poznaskiej. Zawodowo zajmuje si bazami danych i magazynami (hurtowniami) danych. W latach 1996-2002 bral udzial w realizacji 7 projektów informatycznych zarówno naukowo-badawczych, jak i typowo komercyjnych opartych o Oracle. Od 1998 roku prowadzi szkolenia w Centrum Edukacyjnym Oracle Polska. Jest autorem ponad 70 publikacji, krajowych i zagranicznych, w tym trzech ksiek dotyczcych systemu Oracle. Od roku 1999 zasiada w Zarzdzie Stowarzyszenia Polskiej Grupy Uytkowników Systemu Oracle.

Porównanie wydajnoci hurtowni danych ROLAP i MOLAP w Oracle 10g

217

1. Wprowadzenie

Na efektywno przetwarzania zapyta analitycznych w hurtowni ma wplyw m.in. zastosowany model danych, czyli reprezentacji danych w systemie. W praktyce wykorzystuje si dwa podstawowe modele reprezentacji i przechowywania danych w hurtowni: relacyjny, zwany równie ROLAP (ang. Relational OLAP) i wielowymiarowy, zwany równie MOLAP. Hurtownia danych w technologii ROLAP jest implementowana w postaci tabel, których schemat posiada najczciej struktur gwiazdy (ang. star schema) lub platka niegu (ang. snowflake schema) lub konstelacji faktów (ang. fact constellation) [BWZ04]. W technologii MOLAP do przechowywania danych wykorzystuje si wielowymiarowe tablice, popularnie zwane kostkami (ang. multidimensional arrays, datacubes). Tablice te zawieraj wstpnie przetworzone (m.in. zagregowane) dane pochodzce z wielu ródel. Przykladowa 3wymiarowa tablica zostala przedstawiona na rysunku 1. Zawiera ona trzy wymiary: Lokalizacja, Czas i Samochody VW, a poszczególne komórki kostki, tzw. miara (ang. measure), przechowuj informacj np. o lcznej liczbie sprzedanych sztuk wybranych modeli w poszczególnych latach, w wybranych miastach.

Rys. 1. Przykladowa trójwymiarowa tablica opisujca miar liczba_sztuk w trzech wymiarach: Lokalizacji, Czasu i Modelu

Wybór wlaciwego modelu do wlaciwego rodzaju analizy danych bdzie mial wplyw na szybko przetwarzania danych. W ramach niniejszego artykulu zostan przedstawione charakterystyki efektywnociowe modelu ROLAP i MOLAP w implementacji Oracle10g.

2.

MOLAP w Oracle10g

2.1. Obiekty modelu wielowymiarowego

Logicznymi skladnikami modelu wielowymiarowego Oracle OLAP s: zmienne potocznie zwane kostkami, miary, wymiary, hierarchie, poziomy i atrybuty. Kostka jest zbiorem komórek, okrelanych mianem faktów i reprezentujcych elementarne jednostki informacji, bdce przedmiotami analiz (np. sprzeda produktu). Atrybutami faktów s miary, bdce najczciej wartociami numerycznymi (np. cena jednostkowa sprzeday). Miary, umieszczone w tej samej kostce, maj identyczne powizania do innych logicznych obiektów schematu wielowymiarowego i mog by razem analizowane i prezentowane. Wymiary tworz krawdzie kostki i s informacjami referencyjnymi, okrelajcymi kontekst analiz miar. W modelu wielowymiarowym kada miara jest powizana z kilkoma wymiarami, dlatego kada warto miary jest okrelana przez kilka wystpie (instancji) wymiarów. Wymiar najczciej posiada struktur hierarchiczn, okrelajc sposób agregacji wartoci skojarzonych z nim miar. Typowa hierarchia wymiaru sklada si z poziomów, jednak s sytuacje, w których

218

Bartosz Bbel, Julusz Jezierski, Robert Wrembel

hierarchia wymiaru nie posiada poziomów, gdy powizania referencyjne typu nadrzdnypodrzdny pomidzy wystpieniami wymiaru nie pozwalaj na zdefiniowanie poprawnych poziomów. Taki wymiar okrelany jest czsto mianem wymiaru bazujcego na wartociach (ang. valuebased dimension). Jeli wymiar nie posiada hierarchii i poziomów, nosi nazw wymiaru plaskiego (ang. flat dimension). Ostatni element modelu wielowymiarowego, atrybut, dostarcza dodatkowych informacji o instancjach wymiaru.

2.2. Przestrze analityczna

Dane modelu wielowymiarowego Oracle OLAP umieszczane s w tzw. przestrzeniach analitycznych (ang. analytic workspaces). W instancji bazy danych moe istnie wiele przestrzeni analitycznych, kada z nich jest wlasnoci okrelonego uytkownika bazy danych, natomiast pozostali uytkownicy mog uzyska dostp do przestrzeni po nadaniu im odpowiednich uprawnie. Oracle10g skladuje przestrzenie analityczne w tabelach specjalnego schematu relacyjnego, tabele te mog by zarzdzane w taki sam sposób jak zwykle tabele bazy danych. Obiekty fizyczne, implementujce obiekty logiczne, obecne w modelu wielowymiarowym danej przestrzeni analitycznej, umieszczane s w rekordach tabel jako wartoci atrybutów typu LOB. Firma Oracle dostarcza narzdzie o nazwie Analytic Workspace Manager, które przy wykorzystaniu graficznego interfejsu uytkownika umoliwia tworzenie i zarzdzanie przestrzeniami analitycznymi. Opis tych przestrzeni jest realizowany wg. standardu CWM2 (Common Warehouse Metamodel) [OMG, VVS00]. Dostp do metadanych z poziomu SQL jest moliwy przy wykorzystaniu Aktywnego Katalogu (ang. Active Catalog), bdcego zbiorem perspektyw relacyjnych. Proces tworzenia przestrzeni analitycznej sklada si z nastpujcych kroków: 1. Zdefiniowanie przestrzeni analitycznej: okrelenie nazwy nowej przestrzeni oraz wskazanie schematu, w którym przestrze bdzie utworzona; po zatwierdzeniu podanych informacji nastpuje utworzenie we wskazanym schemacie zbioru relacji i innych obiektów w standardowej formie bazodanowej, 2. Zdefiniowanie obiektów logicznych, które utworz wielowymiarowy schemat: kostek, miar, wymiarów, poziomów, hierarchii i atrybutów, obiekty logiczne zostaj zaimplementowane w postaci fizycznych obiektów bazy danych, 3. Okrelenie ródel danych dla poszczególnych obiektów modelu (tabel lub perspektyw schematów relacyjnych), 4. Zaladowanie danych ze ródel danych bezporednio do schematu wielowymiarowego (krok ten jest powtarzany cyklicznie, w miar zachodzenia zmian danych w ródlach modelu). Ponisze sekcje omawiaj dokladnie procesy definiowania logicznych obiektów przestrzeni analitycznej, okrelania ródel danych dla obiektów oraz ladowania danych ze ródel.

2.3. Definiowanie obiektów logicznych przestrzeni analitycznej

2.3.1. Definiowanie wymiarów

Pierwszym krokiem procesu definiowania logicznych obiektów przestrzeni analitycznej jest utworzenie wymiarów. Wyróniamy dwa rodzaje wymiarów: wymiary uytkownika oraz wymiary czasowe. Wymiar uytkownika jest standardowym wymiarem przestrzeni analitycznej, okrelajcym kontekst analiz i moe by wymiarem plaskim, wymiarem bazujcym na wartociach lub standardowym wymiarem z hierarchi poziomów. Kade wystpienie wymiaru musi by unikaln wartoci, natomiast sam wymiar do zapewnienia unikalnoci moe wykorzystywa klucze naturalne lub klucze sztuczne. Klucze naturalne s wartociami pobieranymi bezporednio z tabel ródlo-

Porównanie wydajnoci hurtowni danych ROLAP i MOLAP w Oracle 10g

219

wych bez adnych zmian, wartoci te musz by unikalne w zbiorze wszystkich poziomów wymiaru. Unikalno nie musi by jednak wymuszana w tabelach ródlowych dla wymiaru, gdy kady poziom moe by polczony z inn kolumn tabeli ródlowej. Klucze naturalne s wymagane dla wymiarów plaskich i bazujcych na wartociach. Z kolei klucze sztuczne wymuszaj unikalno instancji poziomów przez dodanie do wartoci pobranej z kolumny tabeli ródlowej przedrostka bdcego nazw poziomu docelowego dla wartoci. Wymiar z kluczem sztucznym musi posiada przynajmniej jedn hierarchi poziomów. Specjalnym rodzajem wymiaru jest wymiar czasowy. Jeli przestrze analityczna ma wspiera analizy przebiegów czasowych (ang. time-series analysis), np. porównania z wczeniejszymi okresami czasowymi, wymiar czasowy musi umoliwia peln definicj okresów czasowych. To pociga za sob konieczno istnienia w tabeli ródlowej dla wymiaru czasowego kolumn, okrelajcych dat koca oraz rozpito okresu czasowego (ang. time span). Jeli te informacje nie s dostpne, wówczas wymiar przechowujcy czas moe zosta zdefiniowany jako zwykly wymiar uytkownika, jednak w tym przypadku nie bdzie moliwoci realizacji analiz bazujcych na czasie.

2.3.2. Definiowanie poziomów

Definiowanie poziomów przebiega tylko w przypadku, gdy ju zdefiniowany wymiar jest wymiarem bazujcym na poziomach. W tej sytuacji poziomy mog by powizane zalenociami typu nadrzdny-podrzdny lub jeden-do-wielu. Dla kadego poziomu konieczne jest zidentyfikowanie ródla danych dla instancji wymiaru na tym poziomie.

2.3.3. Definiowanie hierarchii

Wymiar moe posiada jedn lub wicej hierarchii (jak ju wspomniano, mog równie istnie wymiary nie posiadajce hierarchii). Najczstszym typem hierarchii jest hierarchia bazujca na poziomach. Dla tego rodzaju hierarchii Oracle OLAP wspiera nastpujce typy hierarchii:

· hierarchia normalna ­ sklada si z jednego lub wikszej liczby poziomów agregacji. In-

stancje poziomu podrzdnego polczone s z instancjami poziomu nadrzdnego zalenociami wiele-do-jednego, przez co instancje poziomów podrzdnych ,,zwijaj si" do instancji poziomów nadrzdnych, które z kolei zwijaj si do instancji swoich poziomów nadrzdnych, itd. a do poziomu szczytowego,

· hierarchia wadliwa (ang. ragged hierarchy) ­ zawiera co najmniej jedn instancj poziomu

z inn baz, przez to tworzc ,,wadliwy" poziom bazowy hierarchii,

· hierarchia z brakujcym poziomem ­ zawiera co najmniej jedn instancj, której instancja

nadrzdna umieszczona jest wyej ni jeden poziom w gór w hierarchii wymiaru, przez to powstaje ,,dziura" w hierarchii. Oracle OLAP wspiera równie tworzenie hierarchii bazujcych na wartociach (takich, w których nie jest moliwe wyrónienie poprawnych poziomów), w tym wypadku naley jednak pamita, e wymiar, posiadajcy tak hierarchi, musi korzysta z kluczy naturalnych.

2.3.4. Definiowanie atrybutów

Atrybuty pozwalaj na przechowywanie dodatkowych informacji, opisujcych instancje wymiarów. Wyróniamy atrybuty definiowane automatycznie oraz atrybuty uytkownika. Atrybuty definiowane automatycznie s tworzone przez Analytic Workspace Manager podczas tworzenia wymiaru. Kady wymiar posiada atrybuty, pozwalajce na umieszczenie dlugiego oraz krótkiego opisu instancji wymiaru. Atrybuty te wykorzystywane s przez narzdzia, sluce do przeprowadzania analiz danych modelu wielowymiarowego. Wymiar czasowy jest automatycznie uzupelniany atrybutami okrelajcymi dat koca okresu oraz dlugo okresu.

220

Bartosz Bbel, Julusz Jezierski, Robert Wrembel

Atrybuty uytkownika s tworzone przez uytkownika i pozwalaj na uzupelnienie definicji wymiaru o dodatkowe informacje.

2.3.4. Definiowanie kostek

Pierwszym krokiem procesu definiowania kostki jest okrelenie jej nazwy oraz wskazanie zdefiniowanych wczeniej wymiarów, które utworz krawdzie kostki. Kolejny krok to zdefiniowanie miar, jakie maj by obecne w kostce. Oprócz zwyklych miar, których wartoci bd pobierane z kolumn tabel ródlowych, istnieje moliwo zdefiniowania w kostce tzw. miar wyliczanych. Wartoci miar wyliczanych nie s pobierane z tabel ródlowych, a s wynikiem formul zdefiniowanych przez uytkownika i skladowanych w przestrzeni analitycznej. Oracle OLAP udostpnia szeroki zestaw funkcji, pogrupowanych w zbiory:

· podstawowa arytmetyka: dodawanie, odejmowanie, mnoenie, dzielenie, proporcja; · zaawansowana arytmetyka: suma kumulowana, pozycja, wariancja, udzial, i inne; · porównania: rónica z poprzednim okresem, procentowa rónica z poprzednim okresem,

warto przyszla i inne;

· ramy czasowe: moving average, moving maximum, moving sum, i inne.

Wartoci miar wyliczanych nie s skladowane, ale wyliczane na bieco w przypadku. gdy uytkownik umieci je w zapytaniu analitycznym.

2.4. Okrelanie ródel danych dla obiektów przestrzeni analitycznej

ródlami danych dla logicznych obiektów przestrzeni analitycznej: wymiarów i miar, s tabele, znajdujce si w tym samym schemacie relacyjnym, lub umieszczone w rónych schematach. Okrelenie ródel odbywa si po utworzeniu definicji obiektów przy pomocy narzdzia Analytic Workspace Manager. Narzdzie pozwala na wskazanie kolumny w tabeli w schemacie relacyjnym, z której dany obiekt logiczny bdzie pobieral dane. Naley podkreli, e narzdzie nie pozwala na realizacj transformacji danych (np. okrelenie, e ródlem danych dla miary LiczbaSztuk ma by zsumowana warto kolumny LiczbaSztuk z tabeli SprzedaAktualna z kolumn LiczbaSztuk z tabeli SprzedaHistoryczna). Jeli takie transformacje s konieczne, naley w schemacie relacyjnym utworzy perspektywy, które te transformacje zrealizuj, i dopiero kolumny perspektyw wskaza jako ródla danych dla obiektów przestrzeni analitycznej. Schemat relacyjny, zawierajcy tabele ródlowe dla wymiarów, moe by schematem typu gwiazda, platek niegu lub dowolnym innym schematem relacyjnym, w którym wystpuj zalenoci typu nadrzdny-podrzdny pomidzy tabelami/perspektywami. Jeli wymiar zawiera dodatkowe atrybuty, równie dla nich definiuje si ródla danych wskazujc kolumny w odpowiednich tabelach schematu relacyjnego. Z kolei ródlem danych dla miar, tworzcych kostk, moe by dowolna tabela lub perspektywa, zawierajca odpowiednie dane.

2.5. Ladowanie danych ze ródel do przestrzeni analitycznej

Ostatnim krokiem procesu tworzenia przestrzeni analitycznej jest zaladowanie danych ze ródel relacyjnych do obiektów przestrzeni analitycznej. Po zaladowaniu danych konieczne jest równie wyliczenie agregatów (o ile s zdefiniowane w przestrzeni analitycznej). Ladowanie danych musi by powtarzane cyklicznie, aby zapewni staly doplyw aktualnych danych do schematu wielowymiarowego przestrzeni. Definicja i realizacja procesu ladowania danych odbywa si w narzdziu Analytic Workspace Manager w jednym z trzech scenariuszy. Pierwszy z nich to natychmiastowe uruchomienie procesu przez uytkownika. W tym przypadku dane, pobrane z tabel ródlowych, s natychmiast lado-

Porównanie wydajnoci hurtowni danych ROLAP i MOLAP w Oracle 10g

221

wane do obiektów przestrzeni analitycznej. Drugi scenariusz zaklada zdefiniowanie zada w kolejce zada SZBD Oracle, które bd odpowiedzialne za cykliczne uruchamianie procesu ladowania danych bez koniecznoci jego inicjacji przez uytkownika. Wreszcie trzeci scenariusz polega na utworzeniu skryptu SQL, zawierajcego polecenia ladowania danych, celem jego póniejszego uruchomienia. Po zakoczeniu procesu ladowania danych, schemat wielowymiarowy przestrzeni analitycznej jest gotowy do realizacji analiz danych.

2.6. Analizy danych

Przestrze analityczna Oracle OLAP umoliwia realizacj szeregu analiz danych, slucych pozyskaniu wiedzy pomagajcej w podejmowaniu decyzji biznesowych. Analizy mona podzieli na analizy historyczne oraz prognozowanie przyszlych trendów. Analizy historyczne polegaj na wydawaniu zapyta do danych historycznych, zgromadzonych w schemacie wielowymiarowym. Narzdzia do realizacji analiz, dostarczane przez firm Oracle, to m.in. Oracle BI Discoverer Plus OLAP oraz Oracle BI SpreadSheet Add-In. Discoverer Plus OLAP umoliwia analitykom prezentacj danych wielowymiarowych w rónych ujciach, realizacj typowych operacji modelu wielowymiarowego, takich jak drenie, obracanie, i inne, a take wizualizacj danych w postaci rónorakich wykresów. Z kolei SpreadSheet Add-In umoliwia prac z danymi wielowymiarowymi w formie podobnej do pracy z arkuszem programu Microsoft Excel. Oba narzdzia pozwalaj na konstruowanie skomplikowanych zapyta analitycznych bez znajomoci jzyka SQL, przy wykorzystaniu szeregu kreatorów i szablonów zapyta. Do realizacji analiz, polegajcych na prognozowaniu przyszloci na podstawie danych historycznych, sluy znane ju nam narzdzie Analytic Workspace Manager oraz narzdzie OLAP Worksheet. Oracle OLAP udostpnia szereg metod prognozowania, takich jak m.in. prosta regresja liniowa, kilka metod regresji nieliniowej czy te metod Holta-Wintersa. Analityk moe wskaza, która z metod ma zosta wykorzystana w prognozowaniu, moe równie pozostawi wybór systemowi, który spróbuje dobra metod najbardziej pasujc do danego przypadku. Pierwszym krokiem przy prognozowaniu jest zdefiniowanie przyszlych okresów czasowych, dla których maj zosta znalezione prognozy. Uytkownik musi zapewni, aby wymiar czasowy w schemacie wielowymiarowym zawieral odpowiedni perspektyw czasow. Moe to zrealizowa, dodajc odpowiednie dane do tabeli ródlowej dla wymiaru czasowego (konieczne jest nastpnie uruchomienie procesu ladowania danych) lub dodajc instancje wymiaru czasowego bezporednio w narzdziu Analytic Workspace Manager. Nastpnie naley zdefiniowa miar, która przechowa znalezione podczas prognozowania wyniki. Miara moe by czci analizowanej kostki lub moe nalee do nowej kostki. Kolejnym krokiem procesu prognozowania jest utworzenie odpowiedniego programu, zawierajcego komendy sterujce analiz. Komendy te m.in. pozwalaj na okrelenie parametrów procesu prognozowania, takich jak rodzaj uytej metody, ilo okresów czasowych, uruchamiaj samo prognozowanie i powoduj skladowanie uzyskanych wyników we wskazanej miarze. Program moe by definiowany w obu wymienionych wczeniej narzdziach, jednak jego uruchomienie jest moliwe jedynie w OLAP Worksheet. Program generuje wyniki prognozy, zwykle s to dane na najniszym stopniu szczególowoci, dane mog by nastpnie zagregowane wg wskazanych cieek agregacji.

222

Bartosz Bbel, Julusz Jezierski, Robert Wrembel

3.

Testy efektywnociowe

3.1. Scenrariusz testów i rodowisko testowe

W celu porównania wydajnoci hurtowni danych ROLAP i MOLAP w Oracle10g przyjto dwa podstawowe kryteria oceny testów wydajnociowych, tj. czas ladowania danych do hurtowni oraz czas odpowiedzi na wykonanie przykladowego zapytania analitycznego. Pierwsze kryterium stanowi miar oceny efektywnoci przetwarzania z punktu widzenia administratora systemu i opisuje wielko zasobów (procesory, dyski) niezbdn do przygotowania danych do analizy. Drugie kryterium stanowi miar oceny efektywnoci z punktu widzenia uytkownika systemu i opisuje komfort pracy uytkownika za pomoc aplikacji interakcyjnych.

Rys. 2. Schemat testowej hurtowni danych wg. standardu TPC-H

Na potrzeby eksperymentu zbudowano hurtowni danych ROLAP zasilon danymi pochodzcymi z testu wydajnociowego TPC-H [TCPH]. Schemat testowej hurtowni danych przedstawiono na rysunku 2. Znaczna zloono schematu zapyta (8 tabel) dobrze eksponuje rónice w efektywnoci ROLAP i MOLAP. Naley podkreli, e zastosowanie schematu z testu TPC-H ma na celu przetestowanie MOLAP i ROLAP z wykorzystaniem realistycznego grafu polcze, liczebnoci dziedziny atrybutów oraz selektywnoci polcze. Opis schematu ródel danych dla testu TPC-H oraz rozmiary tabel przedstawiono w tablicy 1. Eksperyment uruchomiono na komputerze PC Intel 2x1200Mhz, 2 GB RAM, 2 dyski SCSI 10.000RPM, dzialajcego po kontrol Linuxa dystrybucji Fedora Core 3 na bazie danych Oracle w wersji 10.1.0.3. Parametry instancji Oracle PGA_AGGREGATE_TARGET i SGA_TARGET ustawiono odpowiednio na 192M i 580M.

Tablica 1. Rozmiary tabel ródlowych wykorzystanego testu TPC-H

tabela

Region Nation

Liczba wierszy

5 25

objto[KB]

0.4 2

klucz podstawowy

regionkey nationkey

Porównanie wydajnoci hurtowni danych ROLAP i MOLAP w Oracle 10g

223

Supplier Customer Order Part Lineitem PartSupp

10K 150K 1,500K 200K 6,000K 800K

1,300 23,000 158,000 23,000 673,000 111,000

suppkey custkey orderkey partkey orderkey+linenumber suppkey+partkey

ROLAP zaimplementowano w postaci tabel, zgodnie z opisem z testu wydajnoci TPC-H, oraz zbioru indeksów B-drzewo zdefiniowanych na kluczach podstawowych i obcych tych tabel. W MOLAP zaimplementowano 3 glówne wymiary (czas, produkt, dostawca), kady wymiar glówny byl konkatenacj od trzech do czterech wymiarów podstawowych (np. czas byl konkatenacj wymiaru: "caly okres", rok, miesic, dzie). Konkatenacja wymiarów prostych posluyla do zamodelowania hierarchii wymiarów (np. "caly okres" sklada si z lat, rok sklada si z miesicy, miesic sklada si z dni). Fakty zostaly zaimplementowane w postaci zmiennej wykorzystujcej skompresowany kompozyt wymiarów: czas, produkt i dostawca.

3.2. Wyniki

Pierwszym testem bylo porównanie czasu ladowania danych do hurtowni (por. tablica 2). W przypadku ROLAP uzyskano czas 2,5 razy krótszy ni w przypadku MOLAP. Rónic t naley tlumaczy zloonymi strukturami danych wykorzystywanymi przez MOLAP, w szczególnoci skompresowanymi kompozytami, których kompresja znacznie obciala zasoby systemu.

Tablica 2. Wyniki testów porównawczych implementacji ROLAP i MOLAP

Kryterium [hh:mi:ss]

Ladowanie danych Materializowanie OLAP Zapytanie o pojedyncz warto w kostce

MOLAP

00:17:01 01:30:19 00:00:00.13 00:00:00.04

ROLAP

00:06:31 05:47:58 00:00:00.51 00:00:00.03 00:00:16 00:00:01 723 968

Zapytanie o wszystkie ciany i krawdzie

00:01:12 00:00:02

Objto [bloki bazy danych ­8KB]:

135 987

Drugi test obejmowal zapytanie o pojedynczy fakt na podstawie okrelonych wartoci wymiarów. Test ten wykonano dla dwóch przypadków, w pierwszym przypadku zapytanie wykonano przy pustym buforze danych, w drugim przypadku bufor byl wypelniony danymi przetwarzanymi przez poprzednie zapytanie. W obu przypadkach czas odpowiedzi zarówno MOLAP i ROLAP wynosi poniej 1 sekundy. S to wyniki wystarczajce dla wydajnej obslugi zapyta ad-hoc generowanych przez aplikacji interakcyjne. Trzeci test dotyczyl czasu materializacji agregatu. Wybrany agregat byl sum sprzeday produktów na wszystkich poziomach glównych wymiarów. W ROLAP agregat zaimplementowano w postaci zmaterializowanej perspektywy. Na perspektywie zdefiniowano indeksy bitmapowe na kadej z kolumn opisujcej wymiar. W MOLAP do przechowywania agregatów posluyla ta sama zmienna wykorzystywana do reprezentacji zbioru pojedynczych faktów. W tecie tym MOLAP charakteryzuje si ponad 3,5 razy krótszym czasem materializacji agregatu. Znacznie gorszy wynik ROLAP wynika z bardzo skomplikowanego zapytania definiujcego zmaterializowan per-

224

Bartosz Bbel, Julusz Jezierski, Robert Wrembel

spektyw. Zapytanie to lczy 4 tabele oraz wykonuje grupowanie wyników trzech operatorów ROLLUP z 2-3 argumentami. Trzeci test obejmowal znalezienie wartoci na wszystkich plaszczyznach i krawdziach kostki danych implementujcej agregat. Test ten wykonano dla dwóch przypadków, w pierwszym przypadku zapytanie wykonano przy pustym buforze danych, w drugim przypadku bufor byl wypelniony danymi przetwarzanymi przez poprzednie zapytanie. Przy pustym buforze ROLAP wykonywal zapytanie 4,5 razy w porównania do MOLAP. Gorszy wynik MOLAP jest spowodowany koniecznoci rozkompresowania zloonych struktur danych. Natomiast w przypadku wypelnionego bufora czas odpowiedzi byl porównywalny i wynosil 2 sekundy dla MOLAP i 1 sekund dla ROLAP. S to wyniki wystarczajce dla wydajnej obslugi zapyta ad-hoc generowanych przez aplikacji interakcyjne. Ostatnim kryterium porównania MOLAP i ROLAP byla objto przechowywanych danych. W tym przypadku, dane zgromadzone w MOLAP zajmuj ponad 5 razy mniej miejsca ni te same dane przechowywane w ROLAP. Rónica ta wynika, ze sposobu reprezentowania wymiarów danych. W MOLAP slu do tego dedykowane struktury danych, umoliwiajce jednokrotne skladowanie tej samej wartoci wymiaru. Natomiast w ROLAP wymiary s skladowane klasycznie w kolumnach tabeli co powoduje, e pojedyncza warto wymiaru jest powielana wielokrotnie, w zalenoci od liczny wystpie faktu, który jest opisywany przez dan warto wymiaru.

4.

Podsumowanie

W pracy porównano wydajno hurtowni danych ROLAP i MOLAP w Oracle 10g wykorzystujc dwa kryteria oceny testów wydajnociowych: czas ladowania danych do hurtowni oraz czas odpowiedzi na wykonanie przykladowego zapytania analitycznego. Dla pierwszego kryterium calkowity czas ladowania danych (czas ladowania danych + czas materializacji agregatów) jest ponad 3 razy krótszy dla MOLAP w porównaniu do ROLAP. Natomiast dla drugiego kryterium ROLAP charakteryzuje si co najmniej 2 krotnie krótszym czasem odpowiedzi. Naley jednak podkreli, e czas odpowiedzi zarówno dla ROLAP jak i dla MOLAP jest wystarczajco krótki (1-2 sekund) aby zapewni komfort pracy uytkownikom z wykorzystaniem aplikacji interakcyjnych. Podsumowujc uzyskane wyniki mona stwierdzi, e MOLAP moe stanowi atrakcyjn alternatyw dla ROLAP, w szczególnoci dla wielkich hurtowni danych, gdzie czas zaladownia danych jest krytycznym wymaganiem. Przykladowo: nowe dane zebrane z systemów OLTP musz by zaladowane w godzinach nocnych, tak aby byly one dostpne nastpnego dnia w hurtowni danych.

Bibliografia

[BWZ04] Bbel B., Wrembel R., Zadrona A.: Implementowanie hurtowni danych - zagadnienia technologiczne. Materialy konferencyjne Hurtownie Danych i Business Intelligence, Warszawa, marzec 2004 Jezierski J., Wrembel R.: Oracle9i Lite: rozwizanie dla mobilnych baz danych? Materialy konferencyjne PLOUG2002, Zakopane, padziernik, 2002, ISSN 1641-2117 Object Management Group. Common Warehouse Metamodel Specification, v1.1. http://www.omg.org/cgi-bin/doc?formal/03-03-02 Transaction Processing Performance Council; http://www.tpc.org/ Vetterli T., Vaduva A., Staudt M.: Metadata Standards for Data Warehousing: Open Information Model vs. Common Warehouse Metadata. SIGMOD Record, vol. 29, No. 3, Sept. 2000

[JeWr02] [OMG] [TPCH] [VVS00]

Porównanie wydajnoci hurtowni danych ROLAP i MOLAP w Oracle 10g

225

Information

Microsoft Word - 17 Jezierski2.doc

11 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

602251