Data Stream Management System

Ett dataströmshanteringssystem (DSMS) är ett mjukvarusystem för hantering av kontinuerliga dataströmmar . Det är jämförbart med ett databashanteringssystem (DBMS) som används för databaser. Till skillnad från ett DBMS, där frågor om statisk data utförs kort, måste ett DSMS kunna utföra kontinuerliga frågor för dataströmmar. Särskilda frågespråk som CQL ( Continuous Query Language ) kan användas för att formulera frågor .

Dataströmshanteringssystem är fortfarande relativt nya i databasvärlden. Några initiala utvecklingar för allmänt ändamål är:

Det finns också ett växande antal mindre projekt med olika fokus. Till skillnad från icke-flytande data, som nästan uteslutande hanteras med universella databashanteringssystem, används system som är särskilt utvecklade eller anpassade för applikationen för flödande data.

Skillnader mot DBMS

Image
Databehandling i ett DBMS
Image
Databehandling i ett DSMS

I konventionella databassystem placeras kortvariga frågor i en databas som förblir densamma under datautvärderingen (se transaktionssystem ). Frågorna startas och förblir i systemet tills resultaten har beräknats och matats ut. Därefter är förfrågningarna inte längre tillgängliga i systemet. Det sägs också att data är beständiga och förfrågningarna är flyktiga. I ett dataströmshanteringssystem installeras förfrågningarna en gång och förblir i systemet tills de uttryckligen tas bort igen. Förfrågningarna utvärderas på ständigt förändrade data, nämligen på dataströmmar. Resultaten av förfrågningarna uppdateras också kontinuerligt så att de själva också resulterar i en dataström. Det sägs också att förfrågningarna är ihållande och uppgifterna är flyktiga. Dessa två kompletterande principer är också kända, till exempel vid informationshämtning som ad hoc-förfrågningar (nya förfrågningar för samma dokument) och dirigeringsuppgifter (nya dokument för angivna förfrågningar).

I följande tabell jämförs olika egenskaper hos ett databashanteringssystem (DBMS) och ett dataströmhanteringssystem (DSMS):

Database Management System (DBMS) Data Stream Management System (DSMS)
Ihållande data (relationer) Flyktiga dataströmmar
Slumpmässig tillgång Sekventiell åtkomst
Engångsförfrågningar Kontinuerliga förfrågningar
(Teoretiskt) obegränsad sekundär lagring Begränsat huvudminne
Endast aktuell status är relevant Hänsyn till inkommande order
relativt låg uppdateringshastighet möjligen extremt hög uppdateringshastighet
små eller inga tidskrav Realtidskrav
Exakta datum antas Inaktuella / felaktiga uppgifter
Planerbar bearbetning av förfrågningar Variabel datainkomst och egenskaper

Grundläggande koncept

Som redan kan ses i tabellen ovan har en DSMS några grundläggande begrepp som skiljer sig från en konventionell DBMS. De viktigaste begreppen är kontinuerliga förfrågningar såväl som fönster.

Kontinuerliga förfrågningar

En kontinuerlig begäran installeras en gång i systemet och körs tills den tas bort igen. Begäran har en eller flera inmatade dataströmmar och en eller flera utdatadataflöden. Resultatet av en sådan begäran är därför inte en engångsuppsättning av data, vilket är fallet med en begäran i ett DBMS, utan en dataström i sig. Resultaten bör skapas i nära realtid, vilket innebär att latensen mellan ankomsten av nya data och utdata från ett nytt resultat är mycket relevant.

Vid en kontinuerlig begäran är det viktigt att definiera när en ny upplaga kommer att produceras. En tidsstyrd modell genererar nya utgångar baserat på hur en klocka utvecklas över tiden, till exempel systemtiden. En ny utgåva kan genereras en gång i minuten. Ett annat tillvägagångssätt är händelsestyrda modeller (Engl. Event-driven model ) där nya utgåvor produceras när vissa händelser inträffar i dataströmmen. Så kunde z. Till exempel kommer varje nytt dataelement i en ström att generera en ny utdata, eftersom detta dataströmselement kan påverka resultatet för denna tidpunkt. Sedan talar man om en tupeldriven modell .

fönster

Dataströmmar är potentiellt oändliga, så de genererar en potentiellt oändlig mängd data. Men endast en begränsad mängd minne är tillgängligt under behandlingen av kontinuerliga förfrågningar, vilket oftast händer i huvudminnet. Windows är ett sätt att begränsa mängden data som måste lagras i minnet. En annan motivation för att använda Windows är användningen av kontinuerliga frågor. Dessa bör ge resultat för den aktuella data som flödar in i DSMS med dataströmmen. Därför är endast aktuella data ofta relevanta, medan äldre data inte längre krävs för de aktuella resultaten. För att kunna uttrycka en begränsning av dataelementens giltighet används fönster.

Windows begränsar visningen av dataströmmen till de senaste elementen i strömmen. Tidsbaserade och elementbaserade (även: tupelbaserade) fönster är utbredda. I tidsbaserade fönster hålls elementen i dataströmmen i systemet under en viss, förutbestämd tid, till exempel 30 minuter. I ett elementbaserat fönster innehåller fönstret maximalt ett förutbestämt antal element, till exempel de senaste 1000 elementen. Ett exempel på en fråga med ett tidsbaserat fönster är: "Beräkna genomsnittet för attributet 'x' för alla dataströmselement för de senaste 30 minuterna."

Element- och tidsbaserade fönster kan definieras olika. Här är huvudsakligen mellan glidande (engl. Glidande ) och tumlande eller studsande (engl. Tumlande ) distinkta fönster. Skillnaden är fönsterstegets storlek, även kallad periodicitet. Ett skjutfönster går framåt med dataströmmen på ett sådant sätt att stegstorleken är minimal. I ett elementbaserat fönster skulle exakt ett element tas bort för ett nytt element som läggs till i fönstret. Stegstorleken kan ändras så långt att det är storleken på fönstret, detta kallas sedan ett tumlande fönster (Engl. Tumlande fönster ). Här fylls ett fönster upp till den angivna storleken. När nästa element anländer, vilket skulle överstiga fönstrets angivna storlek, blir alla tidigare element ogiltiga samtidigt, och det nya fönstret byggs upp steg för steg tills det återigen har nått den maximala storleken. Detta görs analogt i tidsbaserade fönster. Till exempel skulle ett vacklande fönster vara ett 30-minutersfönster med ett steg på 30 minuter.

Enpassad paradigm

Resurserna när det gäller datatid och lagringsutrymme för att beräkna resultat i dataströmmar är begränsade. Algoritmer som bearbetar dataströmmar sparar därför vanligtvis inte först data helt och sedan itererar över hela datamängden för att generera resultat, utan bearbetar varje enskilt element i dataströmmen bara en gång. Detta kallas en-pass-paradigmet: ett dataelement passerar bara en algoritm en gång. Om ett nytt element når algoritmen anpassas beräkningsresultatet och ingen ny åtkomst till elementet behövs vid en senare tidpunkt. Därför behöver algoritmen inte spara några gamla element, bara det aktuella mellanresultatet.

Detta fungerar till exempel för en enkel räknare. Antalet objekt ska räknas. Om ett nytt element anländer till algoritmen ökas räknaren med en, sparas och elementet kan raderas. Endast den aktuella mätaravläsningen behöver sparas.

Bearbetning av flöden och relationer

Image
Strukturen för ett DSMS

Medan data hanteras i tabeller ( relations ) i konventionella (relationella) databassystem läggs dataströmmar till som grundläggande dataobjekt i ett DSMS. Dataströmmar kan förstås som en kontinuerlig sekvens av tids-värde-par. Eftersom dataströmmar i princip är oändliga måste de omvandlas till relationer under tiden för bearbetning. Omvänt kan relationer omvandlas till dataströmmar (se bild). Bearbetningen av rena relationer kan ske med konventionella metoder. Omvandlingen av strömmar till andra strömmar sker via omvägen av relationer. Continuous Query Language , som är baserat på SQL , erbjuder olika operatörer för detta ändamål.

Formulering, planering och optimering av förfrågningar

Som i konventionella databassystem formuleras frågor på ett deklarativt språk och optimeras för körning med hjälp av en frågeplan. Eftersom så många förfrågningar som möjligt bör behandlas samtidigt, kombineras de lagrade förfrågningarna så smart som möjligt så att delvisa förfrågningar kan användas flera gånger.

Komponenterna i en plan är operatörer, köer och tillstånd. Operatörerna motsvarar de operatörer som är kända från konventionella databaser såsom filtrering, sortering, sammanfogning, matematiska operatörer etc. samt inmatning och utmatning av dataströmmar. De enskilda operatörerna för en plan är länkade av köer i vilka dataobjekt skrivs sekventiellt och läses upp av nästa operatör i samma ordning. Som mellanresultat finns tillstånd som innehållet i ett angivet fönster.

exempel

DSMS-Anfrageplan.png

En nyhetsportal vill visa de senaste nyheterna om de ämnen som för närvarande diskuteras mest samt nyhetsvolymen för en dag på sin sida. Meddelanden kommer i en dataström och de aktuella viktiga ämnena i en annan dataström som " tidsgeist ". Varje meddelande tilldelas ett ämne. Specifikt bör meddelandetitlarna från den senaste timmen om de senaste 10 ämnena samt antalet relaterade meddelanden under de senaste 24 timmarna visas. Formulerad i CQL, dessa är två frågor:

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 använder nu dessa förfrågningar för att skapa en plan som är så effektiv som möjligt, som till exempel kan se ut som den som visas i bilden nedan. Meddelandenas titlar och ämnen projiceras först och placeras i en kö. Ämnena placeras först i en kö och därifrån i ett fönster med längden 10. Meddelanden och fönster länkas av en JOIN-operatör och anländer till ett fönster som innehåller alla meddelanden under en dag. Resultatet av fråga Q2 bestäms utifrån detta fönster med COUNT-operatören. För fråga Q1 följs det större fönstret av ett mindre fönster med en längd på en timme.

litteratur

webb-länkar

Individuella bevis

  1. ↑ Data - Engelska testfrågor (ämnen) Lista över filer ( engelska ) National Institute of Standards and Technology. Hämtad 14 februari 2019.
  2. ↑ a b c d e Sandra Geisler: Data Stream Management Systems . I: Phokion G. Kolaitis och Maurizio Lenzerini och Nicole Schweikardt (red.): Dagstuhl uppföljningar . tejp 5 . Schloss Dagstuhl - Leibniz Center for Computer Science, Dagstuhl, Tyskland 2013, ISBN 978-3-939897-61-3 , s. 275–304 , doi : 10.4230 / DFU.Vol5.10452.275 ( dagstuhl.de ).