Dataströmhanteringssystem

Ett dataströmhanteringssystem (DSMS) är ett datorprogram för att hantera kontinuerliga dataströmmar . Det liknar ett databashanteringssystem (DBMS), som dock är designat för statisk data i konventionella databaser . Ett DBMS erbjuder också en flexibel frågebehandling så att den information som behövs kan uttryckas med hjälp av frågor. Men i motsats till ett DBMS, exekverar ett DSMS en kontinuerlig fråga som inte bara utförs en gång, utan är permanent installerad. Därför körs frågan kontinuerligt tills den explicit avinstalleras. Eftersom de flesta DSMS är datadrivna, producerar en kontinuerlig fråga nya resultat så länge som ny data kommer till systemet. Detta grundläggande koncept liknar komplex händelsebearbetning så att båda teknikerna delvis sammansmälter.

Funktionsprincip

En viktig egenskap hos ett DSMS är möjligheten att hantera potentiellt oändliga och snabbt föränderliga dataströmmar genom att erbjuda flexibel bearbetning på samma gång, även om det bara finns begränsade resurser såsom huvudminne. Följande tabell ger olika principer för DSMS och jämför dem med traditionella DBMS.

Databashanteringssystem (DBMS) Dataströmhanteringssystem (DSMS)
Beständiga data (relationer) flyktiga dataströmmar
Slumpmässig tillgång Sekventiell åtkomst
Engångsfrågor Kontinuerliga frågor
(teoretiskt) obegränsad sekundär lagring begränsat huvudminne
Endast det nuvarande tillståndet är relevant Beaktande av inmatningsordningen
relativt låg uppdateringshastighet potentiellt extremt hög uppdateringshastighet
Lite eller inga tidskrav Realtidskrav
Förutsätter exakta data Förutsätter inaktuella/felaktiga data
Planerbar frågebehandling Variabel dataankomst och dataegenskaper

Bearbetnings- och streamingmodeller

En av de största utmaningarna för ett DSMS är att hantera potentiellt oändliga dataströmmar med en fast mängd minne och ingen slumpmässig tillgång till data. Det finns olika tillvägagångssätt för att begränsa mängden data i ett pass, som kan delas in i två klasser. Å ena sidan finns det komprimeringstekniker som försöker sammanfatta data och å andra sidan finns det fönstertekniker som försöker dela upp data i (ändliga) delar.

Sammanfattningar

Tanken bakom komprimeringstekniker är att endast upprätthålla en sammanfattning av data, men inte alla (rå) datapunkter i dataströmmen. Algoritmerna sträcker sig från att välja slumpmässiga datapunkter som kallas sampling till summering med histogram, vågor eller skissning. Ett enkelt exempel på en komprimering är den kontinuerliga beräkningen av ett medelvärde. Istället för att memorera varje datapunkt, innehåller synopsis bara summan och antalet objekt. Genomsnittet kan beräknas genom att dividera summan med talet. Det bör dock nämnas att synopser inte kan återspegla uppgifterna korrekt. Således kan en bearbetning som är baserad på synopser ge felaktiga resultat.

Windows

Istället för att använda synopser för att komprimera egenskaperna hos hela dataströmmarna, tittar fönstertekniker bara på en del av datan. Detta tillvägagångssätt motiveras av tanken att endast de senaste uppgifterna är relevanta. Därför skär ett fönster kontinuerligt ut en del av dataströmmen, t.ex. de senaste tio dataströmselementen, och tar endast hänsyn till dessa element under behandlingen. Det finns olika typer av sådana fönster som skjutfönster som liknar FIFO- listor eller tumlande fönster som skär ut osammanhängande delar. Vidare kan fönstren även differentieras till elementbaserade fönster, t.ex. för att beakta de senaste tio elementen, eller tidsbaserade fönster, t.ex. för att beakta de senaste tio sekunderna av data. Det finns också olika metoder för att implementera fönster. Det finns till exempel metoder som använder tidsstämplar eller tidsintervall för systemomfattande fönster eller buffertbaserade fönster för varje enskilt bearbetningssteg. Frågebehandling med glidfönster är också lämplig att implementeras i parallella processorer genom att utnyttja parallellitet mellan olika fönster och/eller inom varje fönsteromfattning.

Frågebehandling

Eftersom det finns många prototyper finns det ingen standardiserad arkitektur. De flesta DSMS är dock baserade på frågebehandlingen i DBMS genom att använda deklarativa språk för att uttrycka frågor, som översätts till en operatörsplan. Dessa planer kan optimeras och genomföras. En frågebehandling består ofta av följande steg.

Formulering av kontinuerliga frågor

Formuleringen av frågor görs mestadels med deklarativa språk som SQL i DBMS. Eftersom det inte finns några standardiserade frågespråk för att uttrycka kontinuerliga frågor, finns det många språk och variationer. De flesta av dem är dock baserade på SQL , såsom Continuous Query Language (CQL), StreamSQL och ESP . Det finns också grafiska tillvägagångssätt där varje bearbetningssteg är en ruta och bearbetningsflödet uttrycks med pilar mellan rutorna.

Språket beror starkt på bearbetningsmodellen. Till exempel, om fönster används för bearbetningen, måste definitionen av ett fönster uttryckas. I StreamSQL ser en fråga med ett glidande fönster för de sista 10 elementen ut så här: 

             VÄLJ  AVG  (  pris  )  FRÅN  exempelström  [  STORLEK  10  ADVANCE  1  TUPLES  ]  WHERE  värde  >  100  . 0

Denna ström beräknar kontinuerligt medelvärdet av "priset" för de senaste 10 tuplarna, men tar bara hänsyn till de tupler vars priser är högre än 100,0.

I nästa steg översätts den deklarativa frågan till en logisk frågeplan. En frågeplan är en riktad graf där noderna är operatörer och kanterna beskriver bearbetningsflödet. Varje operatör i frågeplanen kapslar in semantiken för en specifik operation, såsom filtrering eller aggregering. I DSMS som bearbetar relationsdataströmmar är operatorerna lika med eller liknar operatorerna för den relationella algebra , så att det finns operatorer för urval, projicering, sammanfogning och inställningsoperationer. Detta operatörskoncept möjliggör en mycket flexibel och mångsidig bearbetning av ett DSMS.

Optimering av frågor

Den logiska frågeplanen kan optimeras, vilket starkt beror på streamingmodellen. De grundläggande koncepten för att optimera kontinuerliga frågor är lika med dem från databassystem . Om det finns relationsdataströmmar och den logiska frågeplanen är baserad på relationsoperatorer från den relationella algebra , kan en frågeoptimerare använda de algebraiska ekvivalenserna för att optimera planen. Dessa kan till exempel vara att trycka ner urvalsoperatorer till källorna, eftersom de inte är så beräkningsintensiva som joinoperatorer.

Dessutom finns det också kostnadsbaserade optimeringstekniker som i DBMS, där en frågeplan med de lägsta kostnaderna väljs från olika likvärdiga frågeplaner. Ett exempel är att välja ordningen för två på varandra följande joinoperatörer. I DBMS görs detta beslut mestadels av viss statistik från de inblandade databaserna. Men eftersom data från en dataström är okänd i förväg, finns det ingen sådan statistik i ett DSMS. Det är dock möjligt att observera en dataström under en viss tid för att få lite statistik. Med hjälp av denna statistik kan frågan även optimeras senare. Så, i motsats till en DBMS, tillåter vissa DSMS att optimera frågan även under körning. Därför behöver ett DSMS vissa planmigreringsstrategier för att ersätta en löpande frågeplan med en ny.

Transformation av frågor

Eftersom en logisk operatör endast är ansvarig för semantiken i en operation men inte består av några algoritmer, måste den logiska frågeplanen omvandlas till en körbar motsvarighet. Detta kallas en fysisk frågeplan. Skillnaden mellan en logisk och en fysisk operatörsplan tillåter mer än en implementering för samma logiska operatör. Join, till exempel, är logiskt sett densamma, även om den kan implementeras av olika algoritmer som en Nested loop join eller en Sort-merge join . Observera att dessa algoritmer också är starkt beroende av den använda strömmen och bearbetningsmodellen. Slutligen är frågan tillgänglig som en fysisk frågeplan.

Utförande av frågor

Eftersom den fysiska frågeplanen består av körbara algoritmer kan den köras direkt. För detta installeras den fysiska frågeplanen i systemet. Den nedre delen av grafen (av frågeplanen) är kopplad till de inkommande källorna, som kan vara allt som kontakter till sensorer. Den övre delen av grafen är kopplad till de utgående sänkorna, som till exempel kan vara en visualisering. Eftersom de flesta DSMS är datadrivna, exekveras en fråga genom att de inkommande dataelementen från källan genom frågeplanen skjuts till diskbänken. Varje gång ett dataelement passerar en operatör, utför operatören sin specifika operation på dataelementet och vidarebefordrar resultatet till alla efterföljande operatörer.

Exempel

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Data_stream_management_system&oldid=1083922879 "