pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 5
w
Przetwarzanie Materializowanej Listy Agregatów
rozbudowanej o bufory LRU
w
1 Wstęp
da
.b
w
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.
pl
s.
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: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
M. Gorawski, M. Grzanka
w
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].
w
2 Materializowana Lista Agregatów
da
.b
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].
pl
s.
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 klientowi przeglądanie danych za pomocą iteratora. Klient
ma również możliwość ingerencji w zawartość listy poprzez wstawiania i usuwania ele72
Przetwarzanie Materializowanej Listy Agregatów rozbudowanej o bufory LRU
mentów, jak również bezpośredniego komunikowania się z listą bez wykorzystania iteratora. Schemat architektury listy reprezentowany przez interfejs java.util.List [10] został
przedstawiony na rys. 1.
klient
iterator
w
Lista
java.util.List
klient
iterator
w
Rys. 1. Schemat architektury klasycznej listy dostępnej w języku Java
w
W odróżnieniu od architektury klasycznej listy architektura Materializowanej Listy
Agregatów została znacznie bardziej rozbudowana. Schemat architektury został przedstawiony na rys. 2.
iterator
źródła danych
da
.b
iterator
klient
Materializowana
Lista
Agregatów
iterator
klient
Interfejs A ggregateRetriever
klient
Database
Aggregate
Retriever
Index
Aggregate
Retriever
Baza
danych
Struktura
indeksująca /
cache
Rys. 2. Schemat podstawowej architektura Materializowanej Listy Agregatów
pl
s.
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 klienta 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 iteratora. Klient MAL może
komunikować się z listą tylko i wyłącznie za pośrednictwem iteratora. Obiekt listy nie
przechowuje również żadnych danych (agregatów). Jest tylko pośrednikiem pomiędzy
klientem komunikującym się poprzez iterator ze źródłem danych. Klient MAL tylko
i wyłącznie przegląda listę, pobiera z niej agregaty i przetwarza.
73
3 Modyfikacja architektury Materializowanej Listy Agregatów
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.
da
.b
w
w
klient
iterator
klient
Materializowana
Lista
Agregatów
klient
Database
Aggregate
Retriever
Bufor
LRU
źródła danych
Baza
danych
pl
s.
iterator
Interfe js A ggreg ateR etriever
iterator
Index
Aggregate
Retriever
Bufor
LRU
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 iteratora listy. Podczas działania klienta 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
w
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 iteratora 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].
da
.b
w
w
N a js ta rs z y e le m e n t
O p e ra c ja
C z y ta j -2
E le m e n t, k tó r y u s u w a n y
je z t z b u fo ra
b ra k
22
15
Z a p is z 1 5
-2
66
22
15
b ra k
C z y ta j 1 7
15
-2
66
22
b ra k
17
15
-2
66
22
Rys. 4. Przykład działania algorytmu LRU
pl
s.
66
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
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
w
w
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
Aggregator 1
(obj2)
w
Aggregator 1
(obj1)
Aggregator 2
(obj2)
Aggregator 1
(obj4)
empty
Rys. 5. Podstawowa wersja bufora LRU
Algorytm 1.
da
.b
W przypadku uruchomienia wątku wypełniania strony iteratora (z wyłączonym
procesem materializacji) wzbogaconego o bufor LRU algorytm rozszerzony jest
o dodatkowy etap.
pl
s.
Algorytmu wypełniania strony tablicy iteratora 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 iteratora 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ę iteratora o pobrane agregaty
11. Zakończ proces wypełniania strony tablicy iteratora.
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 iteratoró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
klienta 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
razem zapytanie do bazy jest inne, co powoduje spowolnienie działania listy w porównaniu
do wersji bez bufora.
Zawartość bufora
Aggregator 1
(obj1)
empty
Wątek 1
empty
w
empty
empty
empty
empty
Zapytanie do bazy:
BorderDate + TimeGap
Zawartość bufora
Aggregator 2
(obj1)
Aggregator 1
(obj1)
Aggregator 3
(obj 1)
w
Wątek 2
Zapytanie do bazy:
BorderDate + 3 * TimeGap
Rys. 6. Pesymistyczny przypadek działania algorytmu 1 z wykorzystanym buforem LRU
(materializacja wyłączona)
w
da
.b
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 iteratora. Idea
przechowywania całej zawartości strony tablicy iteratora 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)
Aggregator
Collection 2
(obj2)
Aggregator
Collection 1
(obj4)
empty
Rys. 7. Zaimplementowana podstawowa wersja bufora LRU
Algorytm 2.
pl
s.
Zmaterializowane agregaty są zapisywane do bazy danych w postaci paczek danych.
Każda paczka (strumień danych binarnych) przechowuje kolekcję agregatów jednej strony
tablicy iteratora. Aggregate Collection jest obiektem zawierającym wszystkie agregaty
strony tablicy iteratora.
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 iteratora.
Równocześnie z wprowadzeniem buforowania danych zmaterializowanych zmodyfikowano algorytm 1 jak niżej.
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 iteratora 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
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ę iteratora o pobrane agregaty
11. Zakończ proces wypełniania strony tablicy iteratora.
w
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.
w
w
3.2 Hierarchiczna wersja bufora LRU
da
.b
Dzięki zastosowaniu mechanizmu buforowania danych możemy zagwarantować przyspieszenie akcji pobierania i przeglądania listy przez jej klientó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
iteratora. 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 iteratora doprowadzamy do takiej samej sytuacji jak przechowywanie pojedynczego agregatu w podstawowej architekturze bufora. Wielu działających jednocześnie klientó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 iteratory 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 iteratora) 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
pl
s.
78
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 iteratora.
Lista ide ntyfik atorów obiek tó w
w
O bject 4
O bject 2
O bject 5
A ggre gator
C ollection 10
A ggre gator
C ollection 2
A ggre gator
C ollection 5
A ggre gator
C ollection 4
A ggre gator
C ollection 1 2
A ggre gator
C ollection 1
A ggre gator
C ollection 8
A ggre gator
C ollection 2
A ggre gator
C ollection 16
A ggre gtor
C ollection 1
A ggre gaor
C ollection 2
em pty
A ggre gator
C ollection 5
em pty
A ggre gator
C ollection 10
em pty
A ggre gator
C ollection 1
em pty
em pty
em pty
K olek cja agregató w
dla ob iek tu (lic znik a) 5
da
.b
w
w
O bject 1
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
pl
s.
W celu wykonania testów wydajnościowych należało zestawić odpowiednie środowisko
testowe. W skład tego środowiska wchodzi aplikacja klienta 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ę klienta i serwer bazy danych na dwa komputery. Aplikacja klienta 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
Intel Pentium M
1.86 GHz
2048 MB RAM
AMD Athlon XP
1.83 GHz
1024 MB RAM
Sieć LAN
Aplikacja klienta
MAL
Baza danych
Oracle
w
Rys. 9. Środowisko testowe MAL/LRU
SPARE
TRIGG
RENEW
100
80
70
60
50
40
30
w
w
Przyspieszenie [%]
90
20
10
0
1
2
4
Liczba miesięcy
6
12
da
.b
Rys. 10. Porównanie przyspieszenia buforowanego działania algorytmów wypełniania
stron tablicy iteratora dla danych niezmaterializowanych
pl
s.
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 iteratora przed
przystąpieniem do przeglądania listy przez klienta. 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 da80
w
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.
TRIGG
SPARE
RENEW
15
Przyspieszenie [%]
5
0
1
w
w
10
2
4
6
12
-5
-10
Liczba miesięcy
da
.b
Rys. 11. Porównanie przyspieszenia buforowanego działania algorytmów wypełniania
stron tablicy iteratora dla danych zmaterializowanych
pl
s.
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 iteratora). 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
Buforowany MAL
Buforowany MAL + mat
50
Przyspieszenie [%]
45
40
35
30
25
20
15
10
5
w
0
5
10
15
25
35
45
55
75
100
Pojemność bufora
w
Rys. 12. Wpływ pojemności bufora na przyspieszenie działania listy (dla algorytmu
wypełniania stron SPARE)
da
.b
w
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.
hierarchical cache
simple cache
70
60
Czas [s]
50
40
30
20
10
0
1
2
4
Liczba miesięcy
6
12
pl
s.
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 iteratora 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
w
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ą.
w
Literatura
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.
da
.b
w
1.
pl
s.
83
w
da
.b
w
w
pl
s.

pobierz plik referatu

Transkrypt

Podobne dokumenty

Okleiniarka Format-4 Perfect 710 e

Test wstępny Teoria Ograniczeń

SetIndexBuffer

Stripper do bufora 250µm Micro-strip MS1-06S-13

Wytwarzanie agregatów nanocząstek i diagnozowanie ich

Stripper do bufora 250µm Miller FO103S

Kraków, dn