Rozdział 5 Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU Streszczenie. Niniejszy rozdział opisuje projekt Materializowanej Listy Agregatów (MAL) rozbudowanej o bufory LRU. Przedstawia on architekturę listy i jej charakterystykę. Zaprezentowana została analiza możliwości przyspieszenia działania mechanizmu MAL poprzez wykorzystanie buforowania odczytywanych danych. Zostały przedstawione dwa rodzaje buforów LRU dostosowane do efektywnego działania MAL: podstawowy i hierarchiczny. Ostatecznie zaprezentowane zostały wyniki analizy wydajnościowej zaimplementowanego rozwiązania MAL/LRU. 1 Wstęp Szybkie reagowanie na zewnętrzne i wewnętrzne czynniki wpływające na sferę ekonomiczną, finansową czy gospodarczą jest w obecnych czasach podstawą działania i decyduje o konkurencyjności przedsiębiorstw. Nie można tego osiągnąć bez wiarygodnej informacji. Jak wskazuje praktyka czasami jednak nadmiar informacji może być równie niepożądany jak jej brak, dlatego ważne jest umiejętne segregowanie i filtrowania zbiorów danych przedsiębiorstw, by na ich podstawie można było podejmować właściwe decyzje. Obecnie dynamika rozwoju przedsiębiorstw jest tak duża, ze klasyczne metody pozyskiwania wiedzy stają się zbyt wolne i nieopłacalne. Dotychczas stosowane systemy przechowywania danych nie zapewniają decydentom odpowiedniego poziomu zadowolenia z dostarczanych informacji. Odpowiedzią na dzisiejsze potrzeby zarządzania są technologie wielowymiarowych struktur danych, których celem jest wspomaganie zarządzania przez dostarczenie właściwej informacji, właściwym ludziom, we właściwym czasie. Szybka reakcja na żądanie użytkownika jest jednym z podstawowych czynników określających jakość rozwiązania informatycznego. W przypadku systemów operujących na niewielkiej liczbie danych zagadnienie nie stanowi problemu. Rosnąca jednak liczba danych koniecznych do przetworzenia wymusza opracowywanie coraz bardziej efektywnych sposobów ich przechowywania i analizowania. Zwykle po przekroczeniu pewnej granicy liczebności danych wydajność systemów informatycznych ulega gwałtownemu pogorszeniu. Kolejną kwestią jest również dostarczenie szybkich i efektywnych mechanizmów dostępu do danych w wyżej wymienionych strukturach. Jednymi z najpopularniejszych sposobów usprawnienia dostępu do przechowywanych danych są indeksowanie i agregacja Marcin Gorawski, Marcin Grzanka Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice, Polska email: Marcin.Gorawski@polsl.pl, Marcin.Grzanka@mensa.org.pl
M. Gorawski, M. Grzanka danych [1]. Indeksowanie w większości przypadków polega na specyficznym grupowaniu obiektów na najniższym poziomie struktury hierarchicznej. Wyższe poziomy tej struktury przechowują informacje katalogowe umożliwiające szybki dostęp do szczegółowych obiektów leżących na niższych poziomach. Agregowanie danych polega natomiast na wyliczeniu jednej lub wielu statystyk, takich jak średnia, minimum, maksimum itp., dla grup obserwacji wyznaczonych przez kategorie zmiennych grupujących. W wyniku tej procedury powstaje nowy zbiór danych, w którym jedna obserwacja odpowiada jednej kategorii zmiennej grupującej. Agregowanie w połączeniu z indeksowaniem zapewnia szybszą obsługę zapytań w systemach decyzyjnych. Kolejnym procesem podniesienia efektywności tych systemów jest materializacji agregatów polegająca na zachowywaniu raz wyliczonych agregatów do ponownego użytku [6], [7], [8]. 2 Materializowana Lista Agregatów Czas obliczania zapytań (czas uzyskania odpowiedzi na zapytanie) może zostać zoptymalizowany przez użycie mechanizmów materializacji. Materializacja to proces wstępnego wyliczania agregatów w celu minimalizacji kosztów obliczania (wykonywania) zapytań dla danego obciążenia i ograniczenia przestrzeni dyskowej. Równocześnie analiza danych w hurtowniach danych często wymaga dostarczenia zagregowanych i posortowanych danych. Są to takie operacje jak budowanie modeli dla procesów eksploracji danych (data miningowych), wsparcie dla operacji drill-down jak również wyświetlanie danych w usługach raportujących. W przypadku danych czasowych zbieranych w systemie przestrzennej hurtowni danych telemetrycznych - SDW(t) (ang. Spatial Telemetric Data Warehouse) agregaty posortowane są względem osi czasu. Najsłabszym punktem rozwiązania SDW(t) było stworzenie i zarządzanie długą listą agregatów, czyli listą odczytów liczników zagregowanych zgodnie z odpowiednim oknem czasowym. Okno czasowe jest to przedział czasu, w którym chcemy badać zużycie mediów. Stworzenie posortowanej listy jest nieskomplikowanym zadaniem w momencie, kiedy liczba danych w liście jest nieduża. Nawet, jeżeli wyliczanie agregatu jest operacją prostą polegająca na zsumowaniu kilku wartości to całkowity czas utworzenia listy może okazać się zbyt duży biorąc pod uwagę liczbę agregatów, jaką należy wyliczyć w pojedynczej liście. Złożoność ta rośnie wraz ze wzrostem liczby obliczanych danych oraz wzrostem stopnia skomplikowania procedury wyliczania agregatu. W wielu przypadkach brana jest pod uwagę częściowo lub całkowita materializacja już wyliczonych agregatów. Biorąc pod uwagę powyższe czynniki został opracowany i zaproponowany nowy sposób składowania i materializacji agregatów, który pozwala na sekwencyjne przeglądanie zagregowanych danych [2], [3], [4]. 2.1 Architektura Materializowanej Listy Agregatów Zaproponowane rozwiązanie składowania i materializacji agregatów zaprojektowane zostało w oparciu o wzorzec projektowy listy dostępnej w języku java [9], [2]. Rozwiązanie to zostało nazwane Materializowaną Listą Agregatów MAL (ang. Materialized Aggregate List). Wzorzec listy umożliwia owi przeglądanie danych za pomocą a. Klient ma również możliwość ingerencji w zawartość listy poprzez wstawiania i usuwania ele- 72
Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU mentów, jak również bezpośredniego komunikowania się z listą bez wykorzystania a. Schemat architektury listy reprezentowany przez interfejs java.util.list [10] został przedstawiony na rys. 1. Lista java.util.list Rys. 1. Schemat architektury klasycznej listy dostępnej w języku Java W odróżnieniu od architektury klasycznej listy architektura Materializowanej Listy Agregatów została znacznie bardziej rozbudowana. Schemat architektury został przedstawiony na rys. 2. Materializowana Lista Agregatów Interfejs AggregateRetriever Database Aggregate Retriever Index Aggregate Retriever źródła danych Baza danych Struktura indeksująca / cache Rys. 2. Schemat podstawowej architektura Materializowanej Listy Agregatów Główną różnicą Materializowanej Listy Agregatów jest źródło danych. Klienci nie mają możliwości wstawiania danych do listy. Dane są pobierane do listy ze źródła danych, które jest przeźroczyste dla a listy i definiowane jest dla konkretnej instancji listy. Źródłem danych dla MAL może być: baza danych - dane potrzebne do zasilenia listy pobierane są bezpośrednio z bazy danych tworząc agregaty poprzez przeliczenie surowych danych, struktura indeksująca - MAL będąc składnikiem węzłów struktury indeksującej pobiera listy agregatów z niższych warstw struktury indeksującej i sumuje je. Kolejnym elementem odróżniającym Materializowaną Listę Agregatów od standardowej architektury listy jest ograniczenie bezpośredniego dostępu do danych zawartych w liście na rzecz komunikowania się z listą za pośrednictwem a. Klient MAL może komunikować się z listą tylko i wyłącznie za pośrednictwem a. Obiekt listy nie przechowuje również żadnych danych (agregatów). Jest tylko pośrednikiem pomiędzy em komunikującym się poprzez ze źródłem danych. Klient MAL tylko i wyłącznie przegląda listę, pobiera z niej agregaty i przetwarza. 73
M. Gorawski, M. Grzanka 3 Modyfikacja architektury Materializowanej Listy Agregatów W poprzednim rozdziale przedstawiona została dotychczasowa architektura Materializowanej Listy Agregatów. Na podstawie przeprowadzonej analizy schematu architektury MAL, wynika, iż możliwe jest przyspieszenie działania listy z wykorzystaniem buforów LRU. Aspektem, nad którym należy się zastanowić jest odpowiednie umiejscowienie bufora w architekturze Materializowanej Listy Agregatów tak, aby zagwarantować poprawne i wydajne jej działanie. Materializowana Lista Agregatów może korzystać w dotychczasowej implementacji z dwóch źródeł danych (rys. 2). Pierwszym z dostępnych źródeł jest baza danych. Jest ona wykorzystywana zarówno do odczytu surowych danych i na ich podstawie wyliczania agregatów jak również w celu odczytywania zmaterializowanych danych oraz materializacji nowo wyliczonych agregatów. Komunikacja z bazą danych jest dwustronna (występuje zarówno odczyt, jaki zapis danych). Zauważyć można również, iż znacznie częściej odbywa się odczytywanie danych niż ich zapis. Hurtownia danych (MAL) jest, bowiem zasilana danymi przez zewnętrzny proces ETL. Obliczanie operacji, które można więc przyspieszyć jest obliczenie operacji odczytu danych poprzez zastosowania bufora. Z tego powodu została podjęta decyzja o implementacji buforowania tylko danych odczytywanych. Wpływ na podjęcie decyzji o implementacji tylko jednego bufora ma również to, iż zapis danych jest operacją zachowania danych zmaterializowanych. Jest to operacja znacznie rzadziej występująca niż odczyt danych. Jest to również operacja dodatkowa, która może zostać włączona poprzez odpowiednie skonfigurowanie MAL. Zysk z takiego rozwiązania byłby minimalny biorąc pod uwagę stosunek liczby operacji zapisu do liczby operacji odczytu z bazy danych. Materializowana Lista Agregatów Interfejs AggregateRetriever Database Aggregate Retriever Index Aggregate Retriever Bufor LRU Bufor LRU źródła danych Baza danych Struktura indeksująca / cache Rys. 3. Architektura Materializowanej Listy Agregatów rozbudowanej o bufory LRU Drugim źródłem danych, z którego MAL może korzystać jest struktura indeksująca. Indeks tworzony jest na podstawie informacji zawartych w bazie danych przed pierwszym skorzystaniem z a listy. Podczas działania a listy dane przechowywane w indeksie są tylko i wyłącznie pobierane. W tym przypadku interesuje nas również tylko buforowanie danych odczytywanych ze źródła danych. Dzięki podejściu buforowania danych odczytywanych zarówno dla źródła danych, jakim jest baza danych jak i dla struktury indeksującej można ujednolicić mechanizm tworzenia bufora gwarantując spójny interfejs dla istniejących jak i możliwych w przyszłości nowych źródeł danych. 74
3 Bufor LRU Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU Przechowywanie dużych struktur danych takich jak lista agregatów czy też różnego rodzaju indeksów w pamięci głównej komputera skutkuje pojawieniem się w pewnym momencie problemu braku wystarczającego rozmiaru pamięci głównej (operacyjnej). Rozwiązania takie, są, więc ograniczone rozmiarem pamięci w szczególności rozwiązania zaimplementowane w języku Java. Po przekroczeniu dostępnej pojemności pamięci następuje intensywna wymiana stron pamięci powodująca znaczny spadek wydajności rozwiązania lub błąd wykonania aplikacji. W przypadku MAL problem braku pamięci został rozwiązany poprzez zastosowanie trzech typów algorytmów wypełniania stron a listy oraz wprowadzenia ograniczenia, w którym nie wszystkie dane są od razu dostępne w pamięci [3]. Rozwiązanie to pozwala zaoszczędzić pamięć główną komputera. Jednakże dane pobierane są z pamięci pomocniczej, jaką jest dysk twardy, z którego odczyt jest wielokrotnie wolniejszy niż pobranie danych z pamięci głównej. Zaimplementowane rozwiązanie wykorzystuje bufor pamięciowy w celu zmniejszenia kosztów odwołania się do dysku twardego. Teoretyczne przyspieszenie, jakie można osiągnąć gwarantowane jest dzięki temu, że bufor przechowuje pewne elementy w pamięci i operacje odczytu tych danych przeprowadzone są przy jego wykorzystaniu. Jeżeli element znajduje się w buforze to odwołanie do niego polega na pobraniu go z pamięci głównej, co jest operacją znacznie szybszą. Jeżeli liczba przechowywanych w buforze elementów przekracza określony przez konfigurację limit, jeden z elementów listy jest usuwany, tak, aby kolejny element mógł zostać dodany. W najgorszym przypadku, żaden element nie będzie wykorzystywany dwukrotnie, co spowoduje, że wprowadzenie bufora pamięciowego spowolni działania systemu. Aby zapobiec temu problemowi należy zastosować jak najlepszą technikę wybierana elementów do usunięcia z bufora. W buforze muszą znajdować się elementy o największym prawdopodobieństwie ponownego wykorzystania usuwane elementy muszą być najmniej potrzebne. Jedną z takich technik, jest technika LRU [5]. Najstarszy element Operacja Czytaj -2 66 22 15 Element, który usuwany jezt z bufora brak Zapisz 15-2 66 22 15 brak Czytaj 17 15-2 66 22 brak 17 15-2 66 22 Rys. 4. Przykład działania algorytmu LRU Nazwa LRU jest skrótem od angielskiego zwrotu Least Recently Used, czyli najdawniej używany. Oznacza to, że z bufora w przypadku wystąpienia przepełnienia zostanie wybrany do usunięcia element najdawniej wykorzystywany. Implementacja programowa bufora LRU jest prosta w realizacji dzięki zastosowaniu listy i połączeniu elementów bufora w tę listę. W momencie odwołania się do elementu bufora jest on przenoszony na pierwszą pozycje listy. Jeżeli nastąpi sytuacja przepełnienia elementem usuwanym jest ostatni element listy. Przykład działania algorytmu LRU został przedstawiony na rys. 4. W pierwszym kroku odczytywana z bufora wartość to 2. Jest ona 75
M. Gorawski, M. Grzanka niedostępna w buforze zatem pobierana jest ze źródła zewnętrznego. Kolejny krok to zapisanie wartości 15 element o wartości 15 zostaje przeniesiony na pierwszą pozycję bufora. Następnie odczytywana jest wartość 17 z bufora. W tym przypadku następuje przepełnienie bufora i ostatnie element o wartości 22 zostaje z niego usunięty. 3.1 Podstawowa wersja bufora LRU Jak już zostało wspomniane implementacja programowa bufora LRU jest realizowalna programowo poprzez połączenie elementów bufora w listę. Na rysunku 5 została przedstawiono obrazowo architektura bufora. Jest to lista elementów o wielkości n. Każdy element listy zawiera k-ty agregat dla j-tego obiektu Agregat 2 dla obiektu 2 1 (obj1) 1 (obj2) 2 (obj2) 1 (obj4) empty Rys. 5. Podstawowa wersja bufora LRU W przypadku uruchomienia wątku wypełniania strony a (z wyłączonym procesem materializacji) wzbogaconego o bufor LRU algorytm rozszerzony jest o dodatkowy etap. Algorytm 1. Algorytmu wypełniania strony tablicy a MAL z wykorzystaniem bufora LRU (materializacja wyłączona). (Algorytm wzbogacony jest o etap pobierania elementów z bufora LRU. Jeżeli szukane dane nie znajdują się w buforze są do niego dodane) 1. Pobierz agregaty z bufora 2. Jeżeli nie są dostępne w buforze 3. Pobierz agregaty z bazy danych 4. Uzupełnij stronę tablicy a o pobrane elementy. 5. Sprawdź liczbę dostępnych agregatów w wypełnianej stronie. 6. Jeżeli liczba agregatów jest mniejsza od wielkości strony 7. Zmodyfikuj datę początkową wyliczania agregatów 8. Pobierz nowe agregaty ze źródła danych 9. Jeżeli liczba pobranych agregatów jest większa od 0 10. Uzupełnij stronę a o pobrane agregaty 11. Zakończ proces wypełniania strony tablicy a. Wstępne testy wydajnościowe takiego rozwiązania bufora LRU wykazały, że w przypadku uruchomienia kilku wątków, które jednocześnie przeglądały tą samą listę za pomocą różnych ów czas pobierania i przetwarzania elementów listy drastycznie spadał. Okazało się, że problemem jest przechowywanie w buforze pojedynczych agregatów. Stąd najbardziej pesymistyczny wariant zakłada, że każdy nowo uruchomiony wątek a przeglądający listę pobiera różną liczbę agregatów z bufora (zazwyczaj zmodyfikowaną przez ostatnio operujący na liście wątek) (rys. 6). W takim przypadku za każdym 76
Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU razem zapytanie do bazy jest inne, co powoduje spowolnienie działania listy w porównaniu do wersji bez bufora. Zawartość bufora 1 (obj1) Wątek 1 Zawartość bufora empty empty empty empty Zapytanie do bazy: BorderDate + TimeGap 1 (obj1) 2 (obj1) 3 (obj 1) empty empty Wątek 2 Zapytanie do bazy: BorderDate + 3 * TimeGap Rys. 6. Pesymistyczny przypadek działania algorytmu 1 z wykorzystanym buforem LRU (materializacja wyłączona) Aby zagwarantować poprawne działanie bufora i uniknąć przedstawionego przypadku została zaproponowana wersja podstawowa bufora LRU, w której jako element listy przechowywany jest obiekt zawierający kolekcję agregatów strony tablicy a. Idea przechowywania całej zawartości strony tablicy a zaczerpnięta został ze sposobu przechowywania zmaterializowanych agregatów. Materializacja, bowiem obejmuje również całą zawartość strony, a nie pojedynczego agregatu. Kolekcja agregatów strony 2 dla obiektu 2 Aggregatot Collection 1 (obj1) Aggregaor Collection 1 (obj2) Collection 2 (obj2) Collection 1 (obj4) empty Rys. 7. Zaimplementowana podstawowa wersja bufora LRU Zmaterializowane agregaty są zapisywane do bazy danych w postaci paczek danych. Każda paczka (strumień danych binarnych) przechowuje kolekcję agregatów jednej strony tablicy a. Aggregate Collection jest obiektem zawierającym wszystkie agregaty strony tablicy a. Aby nie tworzyć dwóch różnych implementacji bufora dla konfiguracji z włączoną materializacją jak i dla wyłączonej materializacji postanowiono przechowywać w elemencie listy bufora kolekcję agregatów strony tablicy a. Równocześnie z wprowadzeniem buforowania danych zmaterializowanych zmodyfikowano algorytm 1 jak niżej. Algorytm 2. 1. Pobierz dane zmaterializowane z bufora 2. Jeżeli nie są dostępne w buforze 3. Pobierz dane zmaterializowane z bazy danych 4. Uzupełnij stronę tablicy a o pobrane elementy. 5. Sprawdź liczbę dostępnych agregatów w wypełnianej stronie. 6. Jeżeli liczba agregatów jest mniejsza od wielkości strony 7. Zmodyfikuj datę początkową wyliczania agregatów 77
M. Gorawski, M. Grzanka 8. Pobierz nowe agregaty ze źródła danych 9. Jeżeli liczba pobranych agregatów jest większa od 0 10. Uzupełnij stronę a o pobrane agregaty 11. Zakończ proces wypełniania strony tablicy a. Algorytm 2 został wzbogacony o pobranie danych zmaterializowanych z bufora. Jeżeli w buforze dane zmaterializowane nie zostaną znalezione algorytm sięga po zmaterializowane agregaty do bazy danych. Jednoczesne działanie obu buforów ma miejsce jedynie w przypadku częściowej materializacji danych. W takim przypadku buforowane są zmaterializowane dane oraz w wyniku potrzeby pobrania agregatów, które nie zostały zmaterializowane wykorzystywane jest również buforowanie mechanizmu pobierania danych z bazy danych. Oba bufory są niezależne od siebie oraz posiadają własne parametry konfiguracyjne. W zależności od charakterystyki systemu, w którym Materializowana Lista Agregatów zostanie uruchomiona można za pomocą konfiguracji dostosować listę i buforowanie do odpowiedniego zastosowania. 3.2 Hierarchiczna wersja bufora LRU Dzięki zastosowaniu mechanizmu buforowania danych możemy zagwarantować przyspieszenie akcji pobierania i przeglądania listy przez jej ów. Ponieważ obiektów (liczników) w hurtowni może być bardzo duża liczba (są to rzędy wielkości tysięcy) zastanowić się można czy przedstawiona architektura podstawowej wersji bufora LRU może zostać usprawniona w celu uzyskania efektywniejszego buforowania. Modyfikacja architektury podstawowej wersji bufora była oparta na analizie problemów wydajnościowych związanych z przechowywaniem pojedynczych agregatów strony tablicy a. Rozwiązaniem problemu jest przechowywanie kolekcji agregatów jako elementu listy zamiast pojedynczego agregatu. Przenosząc ten sam problem i analizę na wyższy poziom to jest na poziom hurtowni danych i tysięcy przechowywanych w niej obiektów powstała kolejna wersja bufora nazwana hierarchiczną. Posiadając jeden bufor zawierający kolekcję elementów strony tablicy a doprowadzamy do takiej samej sytuacji jak przechowywanie pojedynczego agregatu w podstawowej architekturze bufora. Wielu działających jednocześnie ów listy, którzy będą operować na różnych licznikach będzie wzajemnie wypierać elementy z bufora na rzecz przechowywania własnych. W najgorszym przypadku doprowadzić to może do sytuacji, w której y list będą tylko i wyłącznie wstawiać nowe elementy do bufora. Bufor będzie przechowywać pojedyncze elementy (o elemencie mówimy w rozumieniu kolekcji agregatów strony tablicy a) i zanim lista dla danego obiektu spróbuje odczytać wartości z bufora zostaną one usunięte. Najlepszym rozwiązaniem w tym przypadku jest, jeżeli każdy obiekt posiada własny bufor zawierający tylko i wyłącznie elementy, które są agregatami jego odczytów. Ponieważ rozwiązanie takie nie jest niemożliwe w realizacji z powodu ilości liczników, dla których dane są przechowywane należy zagwarantować, aby w pamięci znajdowały się bufory tylko dla obiektów najczęściej wykorzystywanych. Techniką zastosowaną do wyboru elementów, które mają się znaleźć w takim buforze (dokładniej, które elementy z bufora mają zostać usunięte) jest również technika LRU. Architektura takiego buforu została przedstawiona na rysunku 8. Każdy obiekt posiada własny bufor w wersji podstawowej. Bufory dla elementów listy są zgrupowane w listę o używającą technikę LRU usuwania elementów. Korzeniem bufora jest lista LRU, której 78
Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU elementami są obiekty buforów przechowujących agregowane dane o pomiarach liczników. Bufor licznika nazwany liściem bufora hierarchicznego jest również kolejką LRU z tym, że (analogicznie jak w przypadku podstawowej architektury) jest to lista elementów będących kolekcją agregatów strony tablicy a. Lista identyfikatorów obiektów Object 1 Object 4 Object 2 Object 5 Collection 10 Collection 12 Collection 16 Collection 5 Collection 2 Collection 1 Aggregtor Collection 1 empty Collection 5 Collection 8 Aggregaor Collection 2 Collection 10 Collection 4 Collection 2 empty empty Kolekcja agregatów dla obiektu (licznika) 5 Collection 1 empty empty empty Rys. 8. Architektura hierarchicznego bufora LRU Zaprezentowana architektura gwarantuje, że agregaty danego licznika przechowywane są w jednej kolekcji. Obiekty reprezentujące bufory liczników są natomiast skupione w jedną listę, będącą zarazem korzeniem, który posiada zaimplementowaną technikę LRU usuwania najdawniej używanych elementów listy. 4 Analiza wydajnościowa W celu wykonania testów wydajnościowych należało zestawić odpowiednie środowisko testowe. W skład tego środowiska wchodzi aplikacja a MAL oraz system bazodanowy Oracle 10g. Ze względu na wymóg dość dużych mocy obliczeniowych oraz znacznej pojemności pamięci RAM rozdzielono aplikację a i serwer bazy danych na dwa komputery. Aplikacja a działa na systemie Windows Server 2003 oraz Java Sun 1.5. Część serwerowa uruchomiona została na systemie Windows Vista Business oraz bazie danych Oracle Database 10g Release 2 (10.2.0.3) (rys. 9). Przeprowadzone eksperymenty miały na celu sprawdzenie poprawy wydajności MAL poprzez wykorzystanie mechanizmu buforowania danych. Testy zostały przeprowadzone na bazie danych zawierającej ponad 24 miliony rekordów pomiarów dla 1000 liczników. 79
M. Gorawski, M. Grzanka Intel Pentium M 1.86 GHz 2048 MB RAM AMD Athlon XP 1.83 GHz 1024 MB RAM Aplikacja a MAL Rys. 9. Środowisko testowe MAL/LRU Sieć LAN Baza danych Oracle Przyspieszenie [%] 100 90 80 70 60 50 40 30 20 10 0 TRIGG SPARE RENEW 1 2 4 6 12 Liczba miesięcy Rys. 10. Porównanie przyspieszenia buforowanego działania algorytmów wypełniania stron tablicy a dla danych niezmaterializowanych Na przedstawionym rys. 10 widać tendencję zniżkową uzyskiwanego przyspieszenia działania algorytmów MAL wraz ze wzrostem okna czasowego dla zadawanego zapytania. Wraz ze zwiększeniem zakresu okna czasowego wzrasta liczba danych pobieranych ze źródła, które muszą ulec buforowaniu. Bufor posiada ograniczoną pojemność i nie jest wstanie przetrzymywać wszystkich danych, dlatego wraz ze wzrostem przetwarzanej liczby danych spada jego wydajność. Dla maksymalnego okna czasowego, jakie zostało przetestowane (12 miesięcy) zysk z wykorzystania buforowania danych jest w dalszym ciągu znaczący i wynosi średnio 22,4% co jest bardzo satysfakcjonującym wynikiem. W przypadku algorytmu RENEW [2], [3], [4] pomiary dla okna czasowego równego jeden miesiąc zostały pominięte. Przyspieszenie zarówno dla 1-ego jak i 2-óch miesięcy oscyluje w granicach 92% - 98 %. Dzieje się tak z powodu specyfiki algorytmu RENEW. Zasada jego działania polega na wypełnieniu wszystkich stron tablicy a przed przystąpieniem do przeglądania listy przez a. Dla obu podanych zakresów uzyskanie tak dużego przyspieszenie spowodowane było tym, że ustawiony rozmiar bufora pozwalał na zbuforowanie w pamięci danych potrzebnych do wypełnienia wszystkich stron. Analizując natomiast zestawienie otrzymanych wyników dla danych materializowanych nie można jednoznacznie wskazać tendencji zniżkowej wraz ze zmianą okna czasowego zapytania. Można jedynie stwierdzić, że średnie przyspieszenie dla danych materializowanych oscyluje w granicach od 5% do 10%. Porównując wyniki testów otrzymanych dla danych niezmaterializowanych z wynikami na danych zmaterializowanych widać znaczącą różnicę w uzyskanym przyspieszeniu. Dla danych zmaterializowanych średnie przyspieszenie z przeprowadzonych testów wynosi 8%. W porównaniu do rezultatu 22,4% dla danych niezmaterializowanych jest to zdecydowania słabszy wynik. Jednakże jest on dalej satysfakcjonujący. Duża różnica w uzyskanych wynikach wynika z faktu, iż w przypadku pobierania danych zmaterializowanych nie są wykonywane żadne operacje wyliczania agregatów, które mają miejsce w przypadku da- 80
Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU nych niezmaterializowanych. Najbardziej obciążającą operacją w tym przypadku jest pobranie zmaterializowanych danych z tabeli bazy danych dedykowanej do ich przechowywania. Z rys. 11 wynik znaczący spadek wydajności z wykorzystaniem buforowania danych dla algorytmu RENEW w sytuacji, gdy okno czasowe zapytania jest z zakresu 1-2 miesięcy. Dopiero przy oknie czasowym równym cztery i więcej miesięcy widoczne jest przyspieszenie działania listy. Spowodowane jest to dodatkowym narzutem czasowym potrzebnym na sprawdzenie czy dane znajdują się w buforze oraz optymalizatorem zapytań bazy danych Oracle. 15 TRIGG SPARE RENEW Przyspieszenie [%] 10 5 0-5 1 2 4 6 12-10 Liczba miesięcy Rys. 11. Porównanie przyspieszenia buforowanego działania algorytmów wypełniania stron tablicy a dla danych zmaterializowanych Po przeanalizowaniu wyników oraz przebiegu działania testu okazało się, że dodatkowy narzut czasowy związany ze sprawdzaniem czy dane znajdują się w buforze występuje podczas pierwszych odwołań do bufora (upraszczając można przyjąć, że podczas wypełniania pierwszej strony tablicy a). Dane nie znajdują się jeszcze w buforze, co skutkuje nadmiarowością czasową włączonego buforowania. Wątki uruchamiane są co 20ms, natomiast pierwszy odczyt danych z bazy trwa około 200-1200ms. Kolejne zapytania do bazy danych wykonują się ze znacznie większa prędkością rzędu od 10 do 50 ms (dzięki zastosowaniu mechanizmów optymalizacji bazy danych Oracle). Widzimy zatem, że wraz ze wzrostem liczby danych buforowanie w przypadku algorytmu RENEW jest opłacalne. Przy małej liczbie danych tracimy przyspieszenia na rzecz nadmiarowości sprawdzania występowania danych w buforze. Celem kolejnego testu było sprawdzenie wpływu pojemności bufora LRU na przyspieszenie działania listy (rys. 12). Analizując wyniki widać, że zmiana wielkości bufora ma wpływ na przyspieszenie działania MAL zarówno dla danych niezmaterializowanych, jak i materializowanych. Zwiększanie pojemności bufora powoduje wzrost przyspieszenia aż do momentu granicznego, po przekroczeniu, którego przyspieszenie już nie wzrasta, lecz ponownie maleje. W przeprowadzonym teście dla danych zmaterializowanych próg ten można określić jako rozmiar bufora równy 55. Dla danych niezmaterializowanych próg ten można określić jako wartość 75 dla rozmiaru bufora. Po przekroczeniu wskazanych wartości progowych przyspieszenie działania listy maleje z powodu coraz większego narzutu czasowego związanego z wyszukiwaniem danych w buforze. Progi te oczywiście są zależne od charakterystyki systemu, w jakim lista działa. 81
M. Gorawski, M. Grzanka Przyspieszenie [%] Buforowany MAL Buforowany MAL + mat 50 45 40 35 30 25 20 15 10 5 0 5 10 15 25 35 45 55 75 100 Pojemność bufora Rys. 12. Wpływ pojemności bufora na przyspieszenie działania listy (dla algorytmu wypełniania stron SPARE) Ostatnim testem było porównanie działania wersji hierarchicznej bufora z wersją podstawową. Wyniki zostały przedstawione na rys. 13. Wykorzystanie hierarchicznego buforowania danych dodatkowo przyspiesza działanie listy. Można zauważyć również, że wraz ze wzrostem liczby przetwarzanych danych maleje uzyskane przyspieszenie działania MAL. Jednakże nie dyskryminuje to rozwiązania hierarchicznego podejścia, wręcz przeciwnie pokazuje, że warto wykorzystać ten typ bufora. W przypadku mniejszej liczby danych do przetworzenia zyskujemy na czasie, natomiast w przypadku większej liczby danych co najważniejsze nie tracimy na wydajności MAL. 70 60 simple cache hierarchical cache 50 Czas [s] 40 30 20 10 0 1 2 4 6 12 Liczba miesięcy Rys. 13. Porównanie czasu działania MAL z wykorzystaniem podstawowej i hierarchicznej wersji bufora dla algorytmu SPARE 5 Podsumowanie W niniejszym rozdziale została przedstawiona rozbudowana architektura Materializowanej Listy Agregatów. Na bazie istniejącej architektury zaproponowana została zmodyfikowana architektura MAL wzbogacona o buforowanie danych pobieranych ze źródła danych. Przedstawione zostały dwa typy buforów LRU: podstawowy przechowujący kolekcje agregatów strony tablicy a oraz wersja hierarchiczna jako udoskonalenie wersji podstawowej przyspieszające jej działanie. W celu udowodnienia efektywności stworzonego rozwiązania przeprowadzona została analiza wydajnościowo. Systemem, w którym implementacja rozwiązania została wykonana i przeprowadzono testy jest opracowana przez zespół APAS przestrzenna hurtownia da- 82
Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU nych telemetrycznych SDW(t), w której Materializowana Lista Agregatów jest wykorzystywana. Testy jednoznacznie wskazały, że wykorzystując zaimplementowane rozwiązanie buforowania danych można oczekiwać przyspieszenia działania listy MAL/LRU rzędu od 5-ciu do nawet 50-ciu procent w przypadku wyłączonej materializacji danych oraz rzędu od 5-ciu do około 15-tu procent, jeżeli materializacja agregatów jest włączona. Została również dokonana analiza porównawcza podstawowej wersji bufora z hierarchiczną. Wyniki testów wykazały, iż wykorzystanie hierarchicznej wersji bufora może dodatkowo przyspieszyć działanie listy. Kierunkiem dalszych badań może być integracja cache z drugim typem źródła danych to jest strukturą indeksującą. Literatura 1. Golfarelli Matteo, Rizzi Stefano, Salteralli Ettore: Index Selection for data warehousing. VLDB, pp. 156-165, Athens, 1997. 2. Marcin Gorawski, Rafał Malczok: On Efficient Storing and Processing of Long Aggregate Lists. Proceedings of the 7th International Conference Data Warehousing and Knowledge Discovery (DaWak2005, LNCS 3589), Copenhagen, Denmark 2005. 3. Marcin Gorawski: Złożoność czasowa algorytmów wypełniania stron w metodzie materializowanej listy agregatów. II Krajowa Konferencja Naukowa. Technologie Przetwarzania Danych, ISBN 976-83-7143-8, Wyd. Politechniki Poznańskiej, Poznań, pp. 195-206, 2007. 4. Marcin Gorawski, Rafał Malczok: Comparison of Two Approaches to Processing of Long Aggregates Lists in Spatial Data Warehouses, Annales Universitatis Marie Curie-Skłodowska Secti AI Informatica, ISSN 1732-1360, pp.148-160, (2006). 5. Jesper Holm Olsen, Søren Christian Skov: Cache-Oblivious Algorithms in Practice. Department of Computer Science University of Copenhagen, December 2nd, 2002. 6. Theodoratos Dimitri, Bouzeghoub Mokrane: A general framework for the view selection problem for data warehouse design and evolution. DOLAP, McLean, 2000. 7. Baralis E, Paraboshi S, Teniente E: Materialized view selection in multidimensional database. VLDB, pp. 156-165, Athens, 1997. 8. Gupta Himanshu: Selection of Views to Materialize in a Data Warehouse. ICDT, pp. 98-112, 1997. 9. Bruce Eckel: Thinking In Java. Wydanie 3, Helion 2003. 10. Java 5 SDK, Standard Edition, Documentation, Sun Microsystems, 2004. 83