System zarządzania strumieniem danych

System zarządzania strumieniem danych (DSMS) to system oprogramowania do zarządzania ciągłymi strumieniami danych . Jest porównywalny z systemem zarządzania bazami danych (DBMS), który jest używany dla baz danych. W przeciwieństwie do DBMS, w którym zapytania o dane statyczne są realizowane krótko, DSMS musi mieć możliwość wykonywania ciągłych zapytań o strumienie danych. Do formułowania zapytań można używać specjalnych języków zapytań, takich jak Continuous Query Language (CQL).

Systemy zarządzania strumieniami danych są wciąż stosunkowo nowe w świecie baz danych. Niektóre wstępne opracowania ogólnego przeznaczenia to:

Rośnie również liczba mniejszych projektów o różnym ukierunkowaniu. W przeciwieństwie do danych nieprzepływających, które są zarządzane prawie wyłącznie za pomocą uniwersalnych systemów zarządzania bazami danych, do przepływających danych nadal wykorzystywane są systemy specjalnie opracowane lub przystosowane do aplikacji.

Różnice w stosunku do DBMS

Image
Przetwarzanie danych w DBMS
Image
Przetwarzanie danych w DSMS

W konwencjonalnych systemach baz danych zapytania krótkoterminowe są umieszczane w bazie danych, która pozostaje taka sama podczas oceny danych (patrz system transakcyjny ). Zapytania są uruchamiane i pozostają w systemie do momentu obliczenia i wyprowadzenia wyników. Następnie żądania nie są już dostępne w systemie. Mówi się również, że dane są trwałe, a żądania niestabilne. W systemie zarządzania strumieniem danych żądania są instalowane raz i pozostają w systemie, dopóki nie zostaną ponownie usunięte. Zapytania są oceniane na podstawie stale zmieniających się danych, a mianowicie strumieni danych. Wyniki zapytań są również na bieżąco aktualizowane, dzięki czemu same w sobie również generują strumień danych. Mówi się również, że żądania są trwałe, a dane niestabilne. Te dwie uzupełniające się zasady są również znane na przykład przy wyszukiwaniu informacji jako żądania ad hoc (nowe żądania dotyczące tych samych dokumentów) i zadaniach routingu (nowe dokumenty dla określonych żądań).

W poniższej tabeli porównano różne cechy systemu zarządzania bazą danych (DBMS) i systemu zarządzania strumieniem danych (DSMS):

System Zarządzania Bazą Danych (SZBD) System Zarządzania Strumieniem Danych (DSMS)
Trwałe dane (relacje) Ulotne strumienie danych
Losowy dostęp Dostęp sekwencyjny
Żądania jednorazowe Ciągłe zapytania
(Teoretycznie) nieograniczona pamięć dodatkowa Ograniczona pamięć główna
Ważny jest tylko aktualny stan Rozpatrzenie nadchodzącego zamówienia
stosunkowo niska częstotliwość aktualizacji prawdopodobnie bardzo wysoka częstotliwość aktualizacji
niewielkie lub żadne wymagania czasowe Wymagania w czasie rzeczywistym
Zakłada się dokładne daty Nieaktualne/niedokładne dane
Planowane przetwarzanie zapytania Zmienne przybycie i charakterystyka danych

Podstawowe koncepcje

Jak już widać w powyższej tabeli, DSMS ma kilka podstawowych koncepcji, które różnią się od konwencjonalnego DBMS. Najważniejsze pojęcia to ciągłe zapytania oraz okna.

Ciągłe zapytania

Ciągłe żądanie jest instalowane raz w systemie i działa do momentu ponownego usunięcia. Żądanie zawiera co najmniej jeden strumień danych wejściowych i co najmniej jeden strumień danych wyjściowych. Rezultatem takiego żądania nie jest zatem jednorazowy zestaw danych, jak w przypadku żądania w DBMS, ale sam strumień danych. Wyniki powinny być tworzone w czasie zbliżonym do rzeczywistego, co oznacza, że ​​bardzo istotne jest opóźnienie między nadejściem nowych danych a uzyskaniem nowego wyniku.

W przypadku prośby ciągłej ważne jest określenie, kiedy zostanie wyprodukowane nowe wydanie. Modelu czas napędzane generuje nowe wyjść w oparciu o postępie zegara w czasie, na przykład czas systemowy. Raz na minutę można było wygenerować nowy numer. Innym podejściem są modele sterowane zdarzeniami (ang. Event-driven model ), w których nowe edycje są tworzone po wystąpieniu określonych zdarzeń w strumieniu danych. Więc może z. Na przykład każdy nowy element danych w strumieniu wygeneruje nowe dane wyjściowe, ponieważ ten element strumienia danych może wpływać na wynik w tym momencie. Następnie mówi się o modelu krotkowym .

okno

Strumienie danych są potencjalnie nieskończone, więc generują potencjalnie nieskończoną ilość danych. Jednak podczas przetwarzania ciągłych żądań dostępna jest tylko ograniczona ilość pamięci, co najczęściej ma miejsce w pamięci głównej. Windows to jeden ze sposobów ograniczania ilości danych, które muszą być przechowywane w pamięci. Kolejną motywacją do korzystania z okien jest użycie ciągłych zapytań. Powinny one dostarczyć wyników dla bieżących danych, które wpływają do DSMS ze strumieniem danych. Dlatego często istotne są tylko aktualne dane, podczas gdy starsze dane nie są już wymagane do bieżących wyników. Aby móc wyrazić ograniczenie ważności elementów danych stosuje się okna.

Okna ograniczają widok strumienia danych do najnowszych elementów strumienia. Okna oparte na czasie i elementach (również: oparte na krotkach) są szeroko rozpowszechnione. W oknach czasowych elementy strumienia danych są utrzymywane w systemie przez określony, z góry określony czas, na przykład 30 minut. W oknie opartym na elementach okno zawiera maksymalnie określoną liczbę elementów, na przykład ostatnie 1000 elementów. Przykład zapytania z oknem czasowym to: „Oblicz średnią atrybutu „x” wszystkich elementów strumienia danych z ostatnich 30 minut”.

Okna oparte na elementach i oknach czasowych można definiować w różny sposób. Tutaj znajduje się głównie pomiędzy przesuwanymi (ang. Sliding ) a przewracaniem się lub odbijaniem (ang. Tumbling ) wyróżniającymi się oknami. Różnica polega na wielkości kroku okna, zwanej również okresowością. Przesuwane okno przesuwa się wraz z postępem strumienia danych w taki sposób, że rozmiar kroku jest minimalny. W oknie opartym na elementach dokładnie jeden element zostałby usunięty dla nowego elementu, który zostanie dodany do okna. Rozmiar kroku można zmienić, o ile jest to rozmiar okna, nazywa się to wtedy oknem bębnowania (ang. Tumbling window ). Tutaj okno jest wypełnione do określonego rozmiaru. Kiedy nadejdzie kolejny element, który przekroczyłby określony rozmiar okna, wszystkie poprzednie elementy stają się jednocześnie nieważne, a nowe okno jest budowane krok po kroku, aż ponownie osiągnie maksymalny rozmiar. Odbywa się to analogicznie w oknach czasowych. Na przykład chybotliwe okno byłoby 30-minutowym oknem z 30-minutowym przyrostem.

Paradygmat jednoprzebiegowy

Zasoby w zakresie czasu obliczeniowego i miejsca na przechowywanie do obliczania wyników na strumieniach danych są ograniczone. Dlatego algorytmy przetwarzające strumienie danych zazwyczaj nie zapisują danych najpierw w całości, a następnie iterują cały zestaw danych w celu wygenerowania wyników, ale przetwarzają każdy pojedynczy element w strumieniu danych tylko raz. Nazywa się to paradygmatem jednoprzebiegowym: element danych przechodzi przez algorytm tylko raz. Jeśli nowy element dotrze do algorytmu, wynik obliczeń jest dostosowywany i nie jest potrzebny nowy dostęp do elementu w późniejszym czasie. Dlatego algorytm nie musi zapisywać żadnych starych elementów, a jedynie bieżący wynik pośredni.

Działa to na przykład w przypadku prostego licznika. Należy policzyć liczbę obiektów. Jeżeli do algorytmu dotrze nowy element, licznik jest zwiększany o jeden, zapisywany i element może zostać usunięty. Tylko aktualny odczyt licznika musi zostać zapisany.

Przetwarzanie przepływów i relacji

Image
Struktura DSMS

Podczas gdy dane są zarządzane w tabelach ( relacjach ) w konwencjonalnych (relacyjnych) systemach baz danych, strumienie danych są dodawane jako podstawowe obiekty danych w DSMS. Strumienie danych można rozumieć jako ciągłą sekwencję par czas-wartość. Ponieważ strumienie danych są w zasadzie nieskończone, muszą w międzyczasie zostać przekształcone w relacje w celu przetworzenia. I odwrotnie, relacje można przekształcić z powrotem w strumienie danych (patrz rysunek). Przetwarzanie czystych relacji może odbywać się konwencjonalnymi metodami. Zamiana strumieni na inne strumienie odbywa się poprzez objazd relacji. Język Continuous Query Language , który bazuje na SQL , oferuje do tego celu różne operatory.

Formułowanie, planowanie i optymalizacja zapytań

Podobnie jak w konwencjonalnych systemach bazodanowych, zapytania są formułowane w języku deklaratywnym i optymalizowane pod kątem wykonania za pomocą planu zapytań. Ponieważ jak najwięcej zapytań powinno być przetwarzanych w tym samym czasie, przechowywane zapytania są łączone tak sprytnie, jak to możliwe, aby zapytania częściowe można było wykorzystać wielokrotnie.

Składnikami planu są operatorzy, kolejki i stany. Operatory odpowiadają operatorom znanym z konwencjonalnych baz danych, takim jak filtrowanie, sortowanie, łączenie, operatory matematyczne itp. oraz wejście i wyjście strumieni danych. Poszczególne operatory planu są połączone kolejkami, w których obiekty danych są zapisywane sekwencyjnie i odczytywane przez kolejnego operatora w tej samej kolejności. Jako wyniki pośrednie są stany takie jak zawartość określonego okna.

przykład

DSMS-Anfrageplan.png

Portal informacyjny chciałby wyświetlać na swojej stronie najnowsze wiadomości na tematy, które są obecnie najczęściej dyskutowane, a także ilość wiadomości na jeden dzień. Wiadomości przychodzą w jednym strumieniu danych, a aktualnie ważne tematy w innym strumieniu danych jako „ zeitgeist ”. Każda wiadomość jest przypisana do tematu. W szczególności powinny być wyświetlane tytuły wiadomości z ostatniej godziny w ostatnich 10 tematach, a także liczba wszystkich powiązanych wiadomości w ciągu ostatnich 24 godzin. Sformułowane w CQL są to dwa zapytania:

Q1: SELECT Titel FROM Nachrichten N [Range 1 HOUR], Zeitgeist Z [RANGE 10] WHERE N.Thema = Z.Thema

Q2: SELECT COUNT(*) FROM Nachrichten N [RANGE 1 DAY], Zeitgeist Z [RANGE 10] WHERE N.Thema = Z.Thema

DSMS wykorzystuje teraz te zapytania do stworzenia możliwie najbardziej wydajnego planu, który może wyglądać na przykład tak, jak pokazano na poniższej ilustracji. Tytuły i tematy wiadomości są najpierw wyświetlane i umieszczane w kolejce. Tematy są najpierw umieszczane w kolejce, a stamtąd w oknie o długości 10. Wiadomości i okna są łączone operatorem JOIN i docierają do okna, które zawiera wszystkie wiadomości z jednego dnia. Wynik zapytania Q2 jest określany z tego okna za pomocą operatora ILE.LICZB. W przypadku zapytania Q1 po większym oknie następuje mniejsze okno o długości jednej godziny.

literatura

linki internetowe

Indywidualne dowody

  1. ↑ Dane - Angielskie pytania testowe (Tematy) Lista plików ( Angielski ) Narodowy Instytut Standardów i Technologii. Źródło 14 lutego 2019.
  2. ↑ a b c d e Sandra Geisler: Systemy zarządzania strumieniem danych . W: Phokion G. Kolaitis i Maurizio Lenzerini i Nicole Schweikardt (red.): Dagstuhl Follow-Ups . taśma 5 . Schloss Dagstuhl - Leibniz Center for Computer Science, Dagstuhl, Niemcy 2013, ISBN 978-3-939897-61-3 , s. 275-304 , doi : 10.4230 / DFU.Vol5.10452.275 ( dagstuhl.de ).