pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 8
w
Strumieniowe bazy danych
1 Wstęp
da
.b
w
w
Streszczenie. Jednym z największych problemów dzisiejszych aplikacji bazodanowych staje się przetwarzanie olbrzymich ilości danych napływających
w sposób ciągły i nieprzerwany. Na bazie tych problemów wyrosła idea strumieniowych baz danych. Prezentowany rozdział ma na celu przybliżenie czytelnikowi tematyki przetwarzania strumieni danych, problemów związanych
z tym zagadnieniem oraz samych systemów zarządzania strumieniowymi bazami danych. W rozdziale zaprezentowane zostaną także możliwości zastosowania nowej technologii w systemach telekomunikacyjnych.
pl
s.
W dzisiejszym świecie łatwo jest znaleźć aplikacje bazodanowe, których zadaniem jest
przetwarzanie olbrzymich ilości danych. Przykładem takich aplikacji mogą być systemy telekomunikacyjne, monitorujące urządzenia sieciowe czy systemy billingowe. Ważną właściwością tych systemów jest ciągły napływ danych (online). Z tego powodu dane są postrzegane raczej jako nieskończone strumienie elementów niż skończone zbiory. Taka
zmiana w postrzeganiu danych była czynnikiem powodującym wzrost zainteresowania nowymi pomysłami na zarządzanie strumieniami danych. Dodatkowym czynnikiem pobudzającym środowiska naukowe do prac w tym kierunku jest brak efektywnych metod obsługi
ciągłych strumieni w tradycyjnych systemach zarządzania bazami danych.
W rozdziale przybliżymy pojęcia związane z bazami strumieniowymi. Przedstawimy też
mechanizmy, jakie zostały wprowadzone do systemów zarządzania strumieniowymi bazami danych (ang. Data Stream Management System - DSMS) oraz architekturę przykładowego systemu bazując na implementacji TelegraphCQ.
Pierwsza część pracy przedstawia teoretyczne podłoże do naszych rozważań, wprowadzając podstawowe pojęcia i definicje. W części tej przybliżymy takie pojęcia jak strumień
oraz relacja. Przedstawimy związki pomiędzy tymi pojęciami, możliwości transformacji
oraz przykładową architekturę DSMS.
W części drugiej skupimy się na przykładowej implementacji DSMS. Podstawą do naszych rozważań będzie system TelegraphCQ, bazujący na dobrze znanym i popularnym
systemie bazodanowym o nazwie PostgreSQL. Przedstawimy w tej części szczegóły dotyZygmunt Mazur: Instytut Informatyki Stosowanej, Wydział Informatyki i Zarządzania
Politechniki Wrocławskiej, 50-370 Wrocław, Wybrzeże Wyspiańskiego 27,
email: [email protected]
Przemysław Pawluk: student Wydziału Informatyki i Zarządzania Politechniki
Wrocławskiej,
email: [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Z. Mazur, P. Pawluk
czące zmian w architekturze systemu rozwiązaniami porównaniu z rozwiązaniami relacyjnymi oraz zapoznamy czytelnika z dodanymi funkcjami.
Część trzecia stanowi dyskusję możliwości zastosowania technologii strumieniowych
w systemach telekomunikacyjnych. Podstawą tej dyskusji będzie system o nazwie Billing
Gateway opracowany dla firmy Ericsson przez Blekinge Institute of Technology. Przedstawimy architekturę tego systemu oraz możliwości zastosowania w nim technologii strumieniowych.
w
2 Model strumieniowy
2.1 Definicje
da
.b
w
w
Strumień danych reprezentuje napływające nieustannie, zmienne w czasie informacje.
Źródłem tych informacji mogą być zewnętrzne urządzenia lub systemy udostępniające dane
w regularnych bądź nieregularnych odstępach czasu. Element strumienia może być pobrany
tylko raz, nie ma możliwości modyfikacji elementów strumienia, system nie ma także
wpływu na kolejność napływających danych. Elementami strumienia mogą być krotki modelowane jak w relacyjnym modelu, mogą to także być obiekty [2], [10]. W tej części pracy
przyjrzymy się teoretycznym podstawom DSMS oraz językom zapytań ciągłych.
Wprowadźmy na początek definicję strumienia oraz relacji.
Strumień danych (1) S jest to nieograniczony zbiór par postaci <s,τ>, gdzie s jest krotką
schematu danego dla S, a τ∈Γ jest znacznikiem czasowym [1], [10].
Znacznik czasowy nie jest częścią schematu strumienia, nie jest to też rodzaj klucza.
Strumień danych może zawierać wiele elementów o tym samym znaczniku czasowym.
Znacznik czasowy opisuje jedynie logiczny czas przybycia elementu do strumienia. Dla
uproszczenia jest często opisywany za pomocą kolejnych liczb naturalnych.
pl
s.
Relacja R (2) jest zależnym od czasu zbiorem krotek zgodnych z zadanym schematem. Dla
danej chwili τ∈Γ możemy zapisać ją jako R(τ) [1], [10].
Definicja (2) jest różna od tradycyjnej definicji relacji. Czynnikiem odróżniającym obie
definicje jest zależność od czasu. Mając tak zdefiniowany model możemy przejść do opisu
zależności miedzy relacją a strumieniem. Pierwszym krokiem będzie zdefiniowanie
operatorów pozwalających na transformacje relacji i strumieni.
2.2 Operatory
Opisywany model pozwala na transformacje strumieni i relacji za pomocą operatorów. Jednocześnie definiuje zapytanie jako drzewo operatorów należących do jednej z trzech klas
[1]:
− Relation-to-stream (relacja-strumień),
− Stream-to-relation (strumień-relacja),
78
− Relation-to-relation (relacja-relacja).
Zależności między tymi operatorami przedstawia rys. 1.
w
w
Rys. 1. Operatory w modelu strumieniowym [1]
w
W tym modelu nie są uwzględnione operatory klasy stream-to-stream Oczywiście możliwe
jest wykonanie operacji odpowiadającej tym operatorom, musi być ona jednak złożeniem
operatorów pozostałych grup.
2.3 Architektura
da
.b
Spojrzymy teraz na najbardziej ogólny model architektury DMSM. Zgodnie z opisanymi
wcześniej założeniami wejściem dla takiego systemu może być strumień (strumienie) danych lub relacja. Podobnie jako wyjście może zostać wyprodukowana instancja strumienia
lub relacji. Taki właśnie „widok z lotu ptaka” na system zarządzania strumieniami danych
przedstawia rys. 2, na którym są dwa rodzaje statycznych danych, jakie mogą stanowić
wejście do systemu. Są to relacje (Relations) oraz archiwum (Archive). Wprowadziliśmy to
rozróżnienie dla podkreślenia różnic w powstawaniu tych danych. Relacje możemy tu rozumieć w taki sam sposób jak miało to miejsce w modelu relacyjnym, a więc jako zapisane na
dysku lub innym nośniku pamięci zbiory krotek. Archiwum są to „utrwalone”, a więc zapisane w stałej pamięci strumienie danych, służące do zachowania ulotnego z natury strumienia w sposób jawny (explicite).
pl
s.
Rys. 2. Ogólny widok na DSMS
79
Z. Mazur, P. Pawluk
Każdy z elementów wyprodukowanych jako wyjście, zarówno strumień jak i archiwum
może zostać wykorzystany jako wejście do następnej operacji w taki sam sposób jak dzieje
się to w tradycyjnych bazach danych.
2.4 Zapytania w modelu strumieniowym
w
W tradycyjnych systemach zarządzania bazami danych obsługa zapytań polega na dostępie
do danych zapisanych trwale w pamięci. Optymalizacja zapytań polega na znalezieniu
optymalnego logicznego planu zapytania, a następnie dokonaniu wyboru najbardziej efektywnych algorytmów realizujących elementarne operacje.
Wybór ten jest dokonywany z uwzględnieniem charakterystyki danych przechowywanych w bazie. Wynikiem wykonania zapytania jest skończony zbiór elementów, np. krotek
spełniających zadane warunki [10].
w
da
.b
w
2.4.1 Zapytania ciągłe
W przypadku systemów strumieniowych to skomplikowane zadanie, jakim jest wybór
optymalnej metody realizacji zapytania, staje się jeszcze trudniejsze. Dzieje się tak z kilku
powodów. Po pierwsze, specyficzną cechą strumienia jest ulotność danych oraz ich olbrzymia ilość. Uniemożliwia to zapamiętanie całości strumienia. Dodatkowo dane napływają
w niekontrolowanej kolejności. Zmienia to charakter wyniku zapytania. Nie jest to już
skończony zbiór elementów. Zapytania są realizowane dla określonego przedziału czasowego zwanego oknem (ang. window) i zwracane w miarę napływania nowych elementów
do strumienia. Okna służą do zawężenia nieskończonego strumienia do skończonego podzbioru elementów. Celem tego zabiegu jest umożliwienie systemowi wygenerowania przybliżonego wyniku zapytania ciągłego. Metody przetwarzania zapytań ciągłych oraz ich
optymalizacji opisane zostały w pracy [9]
Czym zatem jest zapytanie ciągłe? Zgodnie z definicją zaproponowaną przez Arnasu
w pracy [1] zapytanie ciągłe (ang. continuous query) jest to drzewo operatorów, które mogą
przetwarzać strumienie lub relacje. Wynikiem zapytania ciągłego może być nowy strumień
[10]. Specyficzną cechą odróżniającą zapytania ciągłe od tradycyjnych zapytań w systemach relacyjnych jest możliwość zdefiniowania zapytania o dane, które zostaną dostarczone do systemu w przyszłości. Zapytanie takie zostanie zarejestrowane w systemie i będzie
oczekiwać na nadejście danych. Kolejną różnicą jaką możemy zauważyć jest czas wykonania zapytania. W tradycyjnych systemach zapytania wykonywane są niezwłocznie po dostarczeniu do systemu systemach wykorzystaniem danych jakie aktualnie są dostępne systemach systemie. W systemach strumieniowych zapytania są rejestrowane i w zależności od
implementacji wykonywane określoną ilość razy [7] lub przetwarzane w sposób ciągły do
momentu usunięcia zapytania [1].
pl
s.
2.4.2 Okna
Okno jest pewnym ograniczeniem nałożonym na elementy strumienia pozwalającym zawęzić go do skończonego zbioru. Ze względu na sposób definiowania początku i końca okna
wyróżniamy różne ich grupy.
Okna stałe (ang. fixed windows) są to okna, których granice zostały wyspecyfikowane za
pomocą stałych wartości. Okna ruchome (ang. sliding windows) odwołują się przy definicji
granic do zmiennych, co pozwala na przemieszczanie się okna ponad strumieniem. Innym
podziałem okien może być rozróżnienie zależne od wykorzystywanych w definicji wartości. Może to być ilość krotek - okna ilościowe (ang. count-based, tuple-based) lub czas okna czasowe (ang. time-based).
80
2.5 Języki zapytań ciągłych
w
W istniejących systemach strumieniowych baz danych dominują języki zaprojektowane jako rozszerzenie deklaratywnego języka zapytań, jakim jest SQL. Przykładami takich języków są CQL [1] lub język wykorzystany w projekcie TelegraphCQ [3]. Rozszerzenia
w tych językach umożliwiają definiowanie okien i obsługę strumieni.
Oddzielną grupę stanowią systemy implementujące proceduralne języki zapytań strumieniowych. Zakładają one wykorzystanie pewnego zbioru operatorów strumieniowych. Przez
ich odpowiednie połączenie, zbudowanie swego rodzaju sieci, użytkownik tworzy zapytania. Przykładem takiego podejścia może być system Aurora [2], [8]. W tym rozdziale skupimy się na językach deklaratywnych.
w
w
2.5.1 Język CQL
CQL (ang. Continuous Query Language) jest językiem zaprojektowanym dla systemu
STREAM. Język umożliwia deklarację okien ilościowych oraz czasowych. Dodatkowo
klauzula PARTITION BY umożliwia podział elementów strumienia na grupy, na zasadach
podobnych do działania klauzuli GROUP BY w SQL. Przykładowe zapytanie zapisane za
pomocą CQL mogłoby mieć postać:
da
.b
Select distinct
S.pojazd_id,S.nr_drogi,S.nr_odcinka
From
PozPojazduStr S
[Range 30 Seconds] A,
PozPojazduStr S
[Partition by pojazd_id Rows 1] B
Where A.pojazd_id = B.pojazd_id
W przykładzie mamy daną bazę strumieniową obsługującą dane o położeniu pojazdów. Baza zawiera jeden strumień danych:
PozPojazduStr(pojazd_id, predkosc, nr_drogi, nr_odcinka,kierunek)
pl
s.
W strumieniu rejestrowane są co 30 sekund informacje o położeniu pojazdu, prędkości
i kierunku ruchu. Przytoczone wcześniej zapytanie jako wynik poda nam pogrupowane
według pola pojazd_id ostatnie zapisy dotyczące położenia pojazdów. Okno A w tym zapytaniu jest przykładem okna czasowego wybierającego elementy ze strumienia, które zostały
dodane do niego w ciągu ostatnich 30 sekund. Okno B jest przykładem okna ilościowego
wyznaczającego ostatni zapis dla każdego z pojazdów. Operator distinct eliminuje powtórzenia [10].
2.5.2 TelegraphCQ
W projekcie TelegraphCQ zaproponowano deklarację okna w postaci pętli for z iteratorem
t, którego wartość odpowiada danej chwili (znacznik czasowy) [10]. Taki mało przyjazny
dla użytkownika zapis nie jest jednak propozycją składni zapytań, jak podają autorzy w [4],
a jedynie niskopoziomowym mechanizmem. Składnia klauzuli zawierającej deklarację okna wygląda następująco:
For(t=initial_value; continua_condition(t); change(t)){
WindowIS(Stream1; left_end(t); right_end(t));
WindowIS(Stream1; left_end(t); right_end(t));
…}
81
Z. Mazur, P. Pawluk
w
W tej implementacji nie ma możliwości definiowania okien ilościowych. Można natomiast
sterować ilością przebiegów czyli określać, ile razy zapytanie zostanie wykonane. Definiuje
to continua_condition(t) wraz ze zmianą iteratora change(t). Co ciekawe autorzy zrezygnowali z fizycznych miar czasu jakie były zastosowane w CQL na rzecz logicznej reprezentacji. Konstrukcje zaproponowane w TelegraphCQ pozwalają zmieniać strumień o określonej
granulacji czasu na strumień o innej granulacji czasu.
Składnię zaproponowaną na początku zmodyfikowano w późniejszym okresie, wprowadzając nowy procesor zapytań o nazwie Psoup [4]. Nowa składnia opisana została w pracy
[4]. Zmiany dotyczą deklaracji okien, a nowa składnia wygląda następująco:
w
Select atr_list
From stream_list
Where where_condition
Begin begin_condition
End end_condition
w
W zapytaniu takim mamy możliwość odwołania się np. do zmiennej określającej czas uruchomienia zapytania NOW. Czas, podobnie jak było to ustalone wcześniej, jest przedstawiany w reprezentacji logicznej, nie zaś jak w CQL za pomocą fizycznych miar.
3 TelegraphCQ jako przykład DSMS
da
.b
W tej części rozdziału przyjrzymy się bliżej przykładowej implementacji DSMS o nazwie
TelegraphCQ. System ten wyrósł na bazie systemu zarządzania relacyjną bazą danych
PostgreSQL. System został zaprojektowany i zaimplementowany w Berkley University. Po
nieudanych próbach napisania systemu strumieniowego od podstaw, zrodziła się idea, aby
wykorzystać doświadczenia zebrane w czasie budowania systemu relacyjnego.
3.1 Architektura PostgreSQL
pl
s.
Na początek przyjrzyjmy się architekturze systemu, będącego punktem wyjścia do budowania systemu strumieniowego. Wykorzystywana już od wielu lat idea baz relacyjnych stanowiła, jak się okazało, dobrą podstawę. Rys. 3 przedstawia schemat architektoniczny serwera
PostgreSQL. Na szaro przedstawione zostały elementy niewymagające istotnych zmian
przy implementacji systemu obsługującego strumienie danych. W implementacji PostgreSQL wykorzystany został model zwany process-per-connection. Oznacza to, że dla każdego nowego połączenia Postmaster tworzy nowy proces serwera. Następnie obsługę tego połączenia przejmuje proces Listener. Odpowiada on za akceptację połączeń oraz odbieranie
zapytań od klienta i zwracanie wyników. Kolejne zaangażowane w przetwarzanie zapytania
procesy to Parser oraz Optimizer, które odpowiadają za budowę planu zapytania i jego
optymalizację. Plan ten jest następnie wykonywany przez proces Executor, który wykorzystuje do tego różne metody dostępu do danych. Wyniki zapytań mogą być buforowane,
aby przyspieszyć wykonanie zapytań w przyszłości [7].
Idea wykorzystywana w systemach relacyjnych, zakładająca, że dane są przechowywane
w pamięci trwałej, zapytania natomiast pojawiają się i muszą zostać obsłużone, nie znalazła
zastosowania w bazach strumieniowych. Ulotność i nieograniczona ilość danych powoduje
potrzebę zmiany modelu. Pomysł na rozwiązanie tego problemu przedstawimy w kolejnej
części pracy.
82
w
da
.b
w
w
3.2 Architektura TelegraphCQ
pl
s.
Rys. 3. Architektura PostgreSQL [7]
Ze względu na inna specyfikę danych (nieograniczone, zmienne, ulotne strumienie) zmieniła się filozofia, jaką kierowali się twórcy systemu. Model process-per-connection został
zmieniony na inny, gdzie tylko część serwera jest replikowana (fork). Wprowadzono też
nowe mechanizmy mające umożliwić obsługę strumieni danych. Schemat architektury wraz
z przepływami danych przedstawiony został na rys. 4. Rysunek ten przedstawia serwer,
w skład którego wchodzą trzy podstawowe procesy: TelegraphCQ Front End (FE), TelegraphCQ Back End (BE) oraz Shared Memory Infrastructure (SMI). Jedynie proces FE jest
replikowany przy nowym połączeniu.
Proces Listener, stanowiący część procesu FE, działa podobnie jak w PostgreSQL tzn.
akceptuje połączenia, odpowiada za przechwytywanie zapytań od klienta oraz zwracanie
wyników. W tym miejscu znajdujemy pierwszą znaczącą różnicę pomiędzy TelegraphCQ
oraz PostgreSQL. W TelegraphCQ mamy dwa punkty przetwarzania zapytań w zależności
83
Z. Mazur, P. Pawluk
w
od ich charakteru. Zapytania, które nie są ciągłe zostają przetworzone przez FE a wyniki
zostają zwrócone klientowi. Zapytania o charakterze ciągłym przekazywane są do procesu
BE, którego zadaniem jest obsługa tego typu zapytań. Procesy FE oraz BE komunikują się
za pośrednictwem pamięci współdzielonej zarządzanej przez SMI. W pamięci tej znajduje
się kolejka, w której umieszczane są plany zapytań wygenerowanych przez Planner. Plany
zapytań pobierane są z kolejki i przetwarzane przez BE. BE wykonując plan zapytania skanuje bufor pamięci w poszukiwaniu nowych elementów strumienia. Nowe elementy są
przechwytywane przez mechanizm zwany Wrapper i umieszczane w buforze pamięci. Mechanizm wrapper omówimy w kolejnej części pracy. Na podstawie danych z bufora generowane są wyniki dla przetwarzanych zapytań i umieszczane w specyficznej dla klienta
kolejce. Rezultaty następnie są pobierane z kolejki przez FE i przekazywane klientowi. Tak
zaprojektowana architektura pozwala na dostosowanie systemu do specyficznej sytuacji, w
której to pytania są składowane, a dane, na których zapytania mają operować, napływają w
sposób ciągły i są ulotne.
da
.b
w
w
pl
s.
Rys. 4. Architektura TelegraphCQ [7]
3.3 Wrapper
Wrapper jest mechanizmem pozwalającym pozyskać dane z zewnętrznego źródła i wprowadzić je w postaci strumienia danych do systemu. Procesem odpowiedzialnym za obsługę
zewnętrznych źródeł danych jest TelegraphCQ Wrapper Clearing House (WCH). Wrapper
jest rodzajem funkcji zdefiniowanej przez użytkownika „tłumaczącej” dane wejściowe na
84
w
zrozumiałe dla systemu elementy. WCH odpowiada za zaakceptowanie połączenia ze źródłem, załadowanie i uruchomienie odpowiedniej funkcji wrappera, gdy dane są dostępne,
zamknięcie połączenia, gdy zakończy się interakcja ze źródłem.
W obecnym wydaniu TelegraphCQ proces WCH jest zaimplementowany jako usługa
nasłuchująca na określonym porcie w oczekiwaniu na połączenie. Ponieważ w systemie
TelegraphCQ można zadeklarować dwa rodzaje strumieni, archiwizowany i niearchiwizowany, stąd występują różnice w ich obsłudze przez WCH. Strumienie archiwizowane są
przetwarzane przez WCH, krotki zapisywane są w buforze, aby były dostępne dla innych
procesów, a po wypełnieniu bufor jest zapisywany na dysk, co umożliwia przetwarzanie
danych ze strumienia off-line. Dla strumieni, które nie wymagają archiwizacji ostatni krok
nie jest wykonywany, a dane w buforze zostają nadpisane [7].
w
3.4 Problemy z zapytaniami ciągłymi
da
.b
w
Obsługa zapytań ciągłych jest rozciągnięta w czasie. Ta nowa, nie występująca w tradycyjnych bazach danych, charakterystyka powoduje konieczność poszukiwania metod wykrywania i rozwiązywania problemów występujących w czasie przetwarzania zapytań rozciągniętych w czasie. Problem ten został szczegółowo opisany w pracy [5].
Próbując rozwiązać ten problem napotykamy na kolejne problemy związane z redundancją źródeł danych, zachowaniem ich spójności i oczywiście wydajności całego systemu.
Opis tych problemów nie jest jednak celem tej pracy. Wspominamy o nich jedynie ze
względu na to, że stanowią ciekawy i mało poznany aspekt przetwarzania rozciągniętego
w czasie.
4 Możliwości zastosowania DSMS
Podstawą do naszych rozważań w tej części pracy będzie system o nazwie Billing Gateway
(BG) zaprojektowany i zaimplementowany dla firmy Ericsson. Projekt systemu powstał
w Blekinge Institute of Technology w Ronneby w Szwecji. Architektura tego systemu została opisana w pracy [6].
pl
s.
4.1 Opis systemu Billing Gateway
BG jest systemem odpowiedzialnym za transfer, filtrowanie oraz tłumaczenie danych billingowych pochodzących z elementów sieciowych (NE, ang. Network Elements). Dane następnie są przesyłane do innych systemów, np. systemu billingowego czy wykrywających
nieprawidłowości. Ogólny widok systemu przedstawia rys. 5.
Proces wraz z dynamicznymi elementami jest przedstawiony na rys. 6. Dane są zbierane
z wejścia i składowane w buforze wejściowym. Następnie są pobierane z bufora, przetwarzane i składowane w buforze wyjściowym gdzie czekają na rozdystrybuowanie pomiędzy
inne systemy.
System BG wykorzystuje pliki jako narzędzie składowania danych tymczasowych.
W kolejnej części zaproponujemy zmianę tego procesu przez zaaplikowanie w systemie
BSMS odpowiedzialnego za filtrowanie i tłumaczenie danych pochodzących z wejścia.
85
Z. Mazur, P. Pawluk
w
w
w
da
.b
Rys. 5. Billing Gateway – widok ogólny [6]
4.2 Propozycje zmian
pl
s.
Rys. 6. Proces przetwarzania danych w BG [6]
Autorskim pomysłem na zastosowanie strumieniowych baz danych w środowisku telekomunikacyjnym jest wykorzystanie ich w systemie BG. DSMS miałby być odpowiedzialny
za filtrowanie oraz przetwarzanie danych pochodzących od NE. Obecny system działa
w sposób pokazany na rys. 7. Na danych wejściowych działają filtry, które mogą być łączone ze sobą w swego rodzaju łańcuchy filtrujące. Przefiltrowane dane poddawane są następnie formatowaniu i przesyłane dalej.
Dobrym rozwiązaniem wydaje się zastąpienie procesów filtrujących dane przez DSMS.
Filtrami w takim wypadku byłyby zarejestrowane zapytania ciągłe. Formatowanie danych,
przynajmniej częściowo mogłoby także być wykonane przez DSMS. Niewątpliwą zaletą
takiego rozwiązania byłaby olbrzymia elastyczność w definiowaniu i wymienianiu filtrów.
Zmiana kryteriów filtrowania nie wymagałaby żadnej ingerencji w system poza zarejestrowaniem lub zmianą zapytania ciągłego. Dodatkowo obsługa buforowania danych nie była86
by już w gestii programisty, znalazłaby się natomiast wewnątrz DSMS. Spowodowałoby to
ograniczenie nakładów potrzebnych na wytworzenie systemu.
w
w
w
Rys. 7. Schemat przetwarzania w BG [6]
da
.b
Trudną do oceny cechą jest w tym wypadku wydajność. Zależy ona niestety od bardzo wielu czynników, w tym od sposobu, w jaki zaimplementowany zostałby system. Bez przeprowadzenia odpowiednich testów trudno jest oceniać to rozwiązanie pod kątem wydajnościowym.
5 Podsumowanie
pl
s.
Systemy zarządzające strumieniowymi bazami danych stanowią jeszcze nowy i niezbadany
teren. Jednakże rosnące nieustannie ilości danych, z jakimi muszą radzić sobie dzisiejsze
systemy powodują coraz większe zainteresowanie tą dziedziną. Powstałe dotychczas systemy kładą nacisk na różne aspekty przetwarzania strumieni danych, są przez to trudne do
porównywania. Każdy z nich odkrywa nowe problemy i pokazuje nowe możliwości.
Systemy, jakie zostały zaprezentowane w tej pracy, w różny sposób implementują także
języki zapytań ciągłych, mimo to zaobserwować można tendencję rozszerzania znanego powszechnie języka SQL. Niemniej jednak powstają implementacje, (np. Aurora) wykorzystujące języki proceduralne.
Przedstawiona w pracy przykładowa implementacja DSMS o nazwie TelegraphCQ wyrosła na podwalinach stworzonych przez system relacyjny PostgreSQL. Dzięki temu wiele
dobrych, dobrze przetestowanych pomysłów zostało użytych w nowej implementacji.
Oczywiście olbrzymia część architektury uległa zmianie. Stało się tak ze względu na całkowicie inne spojrzenie na to, co jest składowane, dane czy zapytania. Przedstawiliśmy także
nowe mechanizmy, jakie powstały dla obsługi strumieni danych.
W ostatniej części przedstawiliśmy propozycję zastosowania DSMS w środowisku telekomunikacyjnym. Otoczenie takie wydaje się być idealne dla zastosowania technologii
strumieniowych ze względu na specyfikę danych, jakie są przetwarzane przez tego typu
systemy. Oczywiste jest, że nasze spekulacje wymagają potwierdzenia w doświadczeniach
i badaniach i nie mogą być traktowane jako panaceum na wszelkie problemy związane
z przetwarzaniem strumieni danych.
87
Z. Mazur, P. Pawluk
w
Dużą barierą dla zastosowań przemysłowych omawianej technologii jest brak systemu
komercyjnego, który by ją wspierał. Akademickie implementacje nie są przystosowane do
przetwarzania przemysłowych ilości danych i zaspokojenia wymagań zarówno funkcjonalnych jak i jakościowych dotyczących tego typu produktów.
Podsumowując możemy stwierdzić, że upłynie jeszcze sporo czasu nim systemy strumieniowe zaistnieją na rynku baz danych i będą stanowić większe zagrożenie dla obecnie
najbardziej popularnych systemów relacyjnych. Tym bardziej, że istnieje wiele nierozwiązanych dotychczas problemów związanych zarówno z efektywnością, jak i bezpieczeństwem w szerokim tego słowa znaczeniu.
w
Literatura
1.
da
.b
w
Arnasu A., B.S., Cieslewicz J., Datar M., Ito K., Motwani R., Srivastava U., Widom J. STREAM:
The Stanford Data Stream Management System. in ACM SIGMOD. 2003.
2. Bonnet P., G.J., Seshadri P. Towards Sensor Database Systems. In Proc. in 2nd Conf. on Mobile
Data Management. 2001.
3. Chandrasekaran S. TelegraphCQ: Continuous Dataflow Processing for an Uncertain World. in
CIDR. 2003.
4. Chandrasekaran S., Franklin M.J., PSoup: a system for streaming queries over streaming data.
VLDB Journal (2003) 12: 140–156.
5. Chatterjee S., Krishnamurthy S., Risque: Recovery in Internet Scale Queries, University of
California, 2002.
6. Häggander D., Lundberg L. Optimizing Dynamic Memory Management in a Multithreaded
Application Executing on a Multiprocessor. in ICPP. 1998.
7. Krishnamurthy, S., TelegraphCQ: An Architectural Status Report. Bulletin of the IEEE, 2003.
8. Widera M., Kozielski S. Strumieniowe systemy zarządzania danymi – przegląd rozwiązań. W:
Bazy danych. Modele, technologie, narzędzia. Praca zbiorowa pod red. Stanisława Kozielskiego
[i in.]. T. [1]. Architektura, metody formalne, bezpieczeństwo. Warszawa: WKŁ 2005.
9. Widera M., Kozielski S. Metody przetwarzania w strumieniowych systemach zarządzania
danymi. W: Bazy danych. Modele, technologie, narzędzia. Praca zbiorowa pod red. Stanisława
Kozielskiego [i in.]. T. [1]. Architektura, metody formalne, bezpieczeństwo. Warszawa: WKŁ
2005.
10. Wilczek A. Zapytania w strumieniowych bazach danych. W: Bazy danych. Modele, technologie,
narzędzia. Praca zbiorowa pod red. Stanisława Kozielskiego [i in.]. T. [1]. Architektura, metody
formalne, bezpieczeństwo. Warszawa: WKŁ 2005.
pl
s.
88

pobierz plik referatu

Transkrypt

Podobne dokumenty