Wnioski i uwagi

Prostota obsługi i intuicyjność logiki przetwarzania strumieniowego decyduje o jej akceptacji użycia w przemyśle. Konstrukcja takiej logiki musi oferować zarówno łatwą interpretację funkcjonalności pojedynczych operatorów jak i zapytań. Na początku w strumieniowych bazach danych [14] operator był traktowany jako czarna skrzynka, która posiada n wejść strumieniowych i m wyjść strumieniowych. Wadą takiego podejścia jest konieczność poznania szczegółów implementacyjnych operatorów w celu interpretacji działania całego zapytania. Inną konsekwencją tego podejścia jest powstanie wielu wersji strumieni. Podczas omawiania operatora agregacji zasygnalizowano, że niektóre implementacje generują krotki negatywne przed wstawieniem nowej wartości agregatu. Inne systemy przyjmują, że nowa krotka usuwa poprzednią. W skrajnym przypadku w systemie STREAM [64,4] wprowadzono trzy typy strumieni. Chcąc przetestować istniejące zapytanie na innym źródle danych dla tego systemu, może zajść konieczność przebudowy zapytania. Oznacza to, że system uniemożliwia swobodne wielokrotne korzystanie z wcześniej zbudowanego zapytania strumieniowego. Do tej sytuacji łatwo doprowadzić, gdy implementacja poszczególnych operatorów jest przedkładana nad logikę przetwarzania strumieniowego.

W tym rozdziale zaproponowałem nowe podejście do konstruowania modelu przetwarzania strumieniowego. Prace badawcze zostały skierowane na utworzenie listy reguł oraz cech, które opisują operatory i strumienie. Rdzeniem

zaproponowanego modelu przetwarzania strumieniowego jest zwięzła i niezmienna metoda interpretacji strumienia. Obecnie w literaturze możemy wyróżnić strumienie składające się wyłącznie z krotek pozytywnych, strumienie oparte na krotkach pozytywnych i negatywnych, strumienie z krotkami temporalnymi lub z krotkami tri-temporalnymi. W tej pracy zaproponowano model strumienia danych składający się z krotek temporalnych i negatywnych. Taka kompozycja pozwala na zwięzłą reprezentację wydarzenia, którego czas życia jest znany w chwili jego wystąpienia, jak i nieznany. Istnienie dwóch mechanizmów definiujących czas życia krotki sprawia, że strumienie o różnej zawartości mogą reprezentować obserwację tego samego wydarzenia. Powyższa sytuacja zmusza do zdefiniowania pojęcia podobieństwa strumieni. W przedstawionym rozwiązaniu przyjęto, że dwa strumienie są podobne, jeżeli tworzą tą samą tabele historii. Podsumowując, wprowadzona definicja strumienia łączy zalety oraz usuwa wady reprezentacji bazujących na krotkach temporalnych, pozytywnych i negatywnych, dzięki czemu nie ma potrzeby korzystać z wielu typów lub wersji strumieni w ramach jednego systemu. Własność ta ułatwia interpretację zapytań, co jest kluczowe z punktu widzenia użytkownika strumieniowej bazy danych.

Drugi obszar badawczy przedstawiony w tym rozdziale objął zagadnienie sposobu opisu operatorów strumieniowych. Problem polega na zdefiniowaniu operatora na takim poziomie abstrakcji, aby w najmniejszym stopniu ograniczyć jego sposób implementacji. Zagadnienie to można wyjaśnić następująco. Tworząc strumieniową bazę danych jesteśmy zobligowani do udostępnienia użytkownikowi operator złączenia. Gdy pojawi się nowa wydajniejsza jego realizacja, dołączenie operatora złączenia do strumieniowej bazy danych powinno wiązać się z minimalną liczbą zmian. Aby osiągnąć postawiony cel, operatory strumieniowe zostały skonstruowane uwzględniając:

• regułę przekształcania operatora logicznego w operator fizyczny, • niezmienniki stanu, przejścia i propagacji oraz

• definicję monotoniczności strumieni.

Analizując stan literatury, uwzględnienie tych trzech składników jednocześnie jest podejściem nowatorskim. Do obecnych rozwiązań konkurencyjnych można zaliczyć model stosowany w systemie CEDR [16]. Słabością niego jest jak

dotąd słabo rozpoznana problematyka monotoniczności oraz potrzeba korzystania z bardzo rozbudowanej logiki do rozwiązywania prostych zapytań strumieniowych.

Kluczowym elementem zaproponowanego modelu przewarzania strumieniowego jest podział na logikę opisaną przez operatory logiczne oraz algorytmy opisane przez operatory fizyczne. Relację pomiędzy tymi poziomami abstrakcji określa def. 2.8. Cechuje się ona tym, że definicja operatora logicznego nie narzuca bezpośrednio algorytmu operatora fizycznego. Taka definicja operatorów logicznych pozwala w czytelny sposób przenieść definicję operatorów relacyjnych baz danych do środowiska strumieniowego. Wyjątek stanowią operatory, których definicja jest ściśle związana z własnościami strumieni, przykładowo do grupy tej należy okno liczebnościowe.

Drugie kryterium uwzględniane przy budowie operatorów to niezmienniki [88]. Formalizują one własności, jakie musi spełnić każdy operator strumieniowy. Dotąd przy budowie operatorów strumieniowych kierowano się zasadą, aby operator był nie blokowalny oraz przechowywał ograniczony stan. Systematyka niezmienników definiuje dodatkowo własności, jakimi muszą charakteryzować się operatory, aby można było je swobodnie łączyć w złożone zapytania.

Ostatnim elementem uwzględnionym przy budowie operatorów jest monotoniczność strumieni. Zwróćmy uwagę na dwie podstawowe różnice pomiędzy strumieniem a relacją. Strumień jest kolejką krotek, z kolei relacja jest zbiorem krotek bez ustalonego uporządkowania. Ponadto w wielu systemach przyjmuje się, że strumień zawiera krotki uporządkowane względem znacznika czasowego. Powyższe założenia wskazują, że konstrukcja strumieniowej bazy danych jest bliższa temporalnej bazie danych aniżeli relacyjnej bazie danych. W szczególności metody optymalizacji uwzględniające uporządkowanie danych zostały szerzej zbadane dla optymalizatorów temporalnych baz danych [67,78,77]. Rezultatem tych obserwacji jest klasyfikacja monotoniczności strumieni [37]. Monotoniczność jest to cecha, która zawęża możliwe wartości krotek występujące w strumieniu. O ile przepustowość i selektywność operatora mogą ulegać zmianą w trakcie działania systemu, monotoniczność strumienia jest cechą stałą. Własność ta mówi, jakiego typu dane

na wejściu się nigdy nie pojawią, bazując na tej przesłance można skorzystać z odpowiednio uproszczonej i wydajniejszej wersji operatora.

Rozdział ten stanowi fundament dla badań mających na celu zweryfikowanie tez pracy. Teza pierwsza dotyczy rozwoju języka deklaratywnego obsługującego zapytania strumieniowe. Aby móc skonstruować język deklaratywny, konieczny jest model logiczny operatorów. Problemem otwartym jest opis operatorów strumieniowych na takim poziomie abstrakcji, aby można było skonstruować elastyczny deklaratywny język zapytań. Teza druga dotyczy zagadnienia synchronizacji, która w znaczący sposób wpływa na wydajność systemów wielowątkowych. Tutaj opis modelu logicznego operatorów odgrywa kluczową rolę. Czym definicja operatora logicznego w mniejszym stopniu determinuje algorytm operatora fizycznego, tym większy istnieje wachlarz algorytmów jego realizacji. Co w konsekwencji pozwala zastosować większą liczbę wersji synchronizacji oraz metod zarządzania zasobami. Powyższa sytuacja sprawiła, że przed przystąpieniem do właściwych badań, została zbudowana algebra operatorów strumieniowych, której nowatorskie elementy opisano powyżej.

Aby potwierdzić poprawność i kompletność omówionej logiki operatorów, każdy z omówionych operatorów zaimplementowano i przeprowadzono testy w prototypowym systemie StreamAPAS. Operatory stanowe zostały dodatkowo przeanalizowane pod kątem uproszczeń wynikających ze znajomości monotoniczności strumieni zasilających. Uproszczenia te są wykorzystywane przez optymalizator warunkowy opisany w sekcji 2.10. Opis każdego z operatorów zawiera definicje algorytmu podstawowego. Wydajność poszczególnych operatorów nie jest przedmiotem tych badań. W chwili, kiedy istnieje wiele prac poświęconych algorytmom operatorów agregacji, łączenia, eliminacji duplikatów i innych. Problem stanowi sposób definiowania operatorów strumieniowych oraz weryfikacja ich poprawności, tak aby dysponując kilkoma operatorami fizycznymi X1, …, Xn móc odpowiedzieć na pytanie czy są to te same operatory logiczne.