Strumieniowe bazy danych

Transkrypt

1 Strumieniowe bazy danych Rozdział 8 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. 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 doty 1 Wstęp Zygmunt Mazur: Instytut Informatyki Stosowanej, Wydział Informatyki i Zarządzania Politechniki Wrocławskiej, Wrocław, Wybrzeże Wyspiańskiego 27, zygmunt.mazur@pwr.wroc.pl Przemysław Pawluk: student Wydziału Informatyki i Zarządzania Politechniki Wrocławskiej, przemyslaw.pawluk@student.pwr.wroc.pl

2 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. 2 Model strumieniowy 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. 2.1 Definicje 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. 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

3 Relation-to-relation (relacja-relacja). Zależności między tymi operatorami przedstawia rys. 1. Strumieniowe bazy danych Rys. 1. Operatory w modelu strumieniowym [1] 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 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). Rys. 2. Ogólny widok na DSMS 79

4 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 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] 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] 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

5 2.5 Języki zapytań ciągłych Strumieniowe bazy danych 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 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ć: 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) 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] 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

6 Z. Mazur, P. Pawluk 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: Select atr_list From stream_list Where where_condition Begin begin_condition End end_condition 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 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 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 Postgre- SQL 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

7 Strumieniowe bazy danych Rys. 3. Architektura PostgreSQL [7] 3.2 Architektura TelegraphCQ 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

8 Z. Mazur, P. Pawluk 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. 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

9 Strumieniowe bazy danych 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]. 3.4 Problemy z zapytaniami ciągłymi 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]. 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

10 Z. Mazur, P. Pawluk Rys. 5. Billing Gateway widok ogólny [6] 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ła 4.2 Propozycje zmian 86

11 Strumieniowe bazy danych by już w gestii programisty, znalazłaby się natomiast wewnątrz DSMS. Spowodowałoby to ograniczenie nakładów potrzebnych na wytworzenie systemu. Rys. 7. Schemat przetwarzania w BG [6] 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 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

12 Z. Mazur, P. Pawluk 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. Literatura 1. 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 Bonnet P., G.J., Seshadri P. Towards Sensor Database Systems. In Proc. in 2nd Conf. on Mobile Data Management Chandrasekaran S. TelegraphCQ: Continuous Dataflow Processing for an Uncertain World. in CIDR Chandrasekaran S., Franklin M.J., PSoup: a system for streaming queries over streaming data. VLDB Journal (2003) 12: Chatterjee S., Krishnamurthy S., Risque: Recovery in Internet Scale Queries, University of California, Häggander D., Lundberg L. Optimizing Dynamic Memory Management in a Multithreaded Application Executing on a Multiprocessor. in ICPP Krishnamurthy, S., TelegraphCQ: An Architectural Status Report. Bulletin of the IEEE, 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Ł 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Ł 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Ł