Data Stream Management System - Versionsgeschichte

Aka: /* Literatur */ falsches Komma entfernt

2024-11-15T14:55:41Z

Literatur: falsches Komma entfernt

← Nächstältere Version		Version vom 15. November 2024, 16:55 Uhr
Zeile 98:		Zeile 98:
	== Literatur ==		== Literatur ==
	* Brian Babcock, Shivnath Babu, Mayur Data, Rajeev Motwani, Jennifer Widom. ''[http://newdbpubs.stanford.edu:8090/pub/2002-19 Models and Issues in Data Stream Systems]''. In: Proceedings of 21st ACM Symposium on Principles of Database Systems (PODS 2002)		* Brian Babcock, Shivnath Babu, Mayur Data, Rajeev Motwani, Jennifer Widom. ''[http://newdbpubs.stanford.edu:8090/pub/2002-19 Models and Issues in Data Stream Systems]''. In: Proceedings of 21st ACM Symposium on Principles of Database Systems (PODS 2002)
	* Don Carney, Ugur Centintemel, Mitch Cherniack, et al.: ''[http://www.cs.brown.edu/research/aurora/aurora_tr.pdf Monitoring Streams - A New Class of Data Management Applications] (PDF; 685 kB)''. (VLDB 2002)		* Don Carney, Ugur Centintemel, Mitch Cherniack et al.: ''[http://www.cs.brown.edu/research/aurora/aurora_tr.pdf Monitoring Streams - A New Class of Data Management Applications] (PDF; 685 kB)''. (VLDB 2002)
	* Sandra Geisler: ''[http://drops.dagstuhl.de/opus/volltexte/2013/4297/pdf/ch10-geisler.pdf Data Stream Management Systems]''. Dagstuhl Follow-Ups. Vol. 5. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2013.		* Sandra Geisler: ''[http://drops.dagstuhl.de/opus/volltexte/2013/4297/pdf/ch10-geisler.pdf Data Stream Management Systems]''. Dagstuhl Follow-Ups. Vol. 5. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2013.
	* Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Manku, Chris Olston, Justin Rosenstein und Rohit Varma: ''[http://newdbpubs.stanford.edu:8090/pub/2002-41 Query Processing, Resource Management, and Approximation in a Data Stream Management System]''. Stanford, 2002 (CIDR 2003)		* Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Manku, Chris Olston, Justin Rosenstein und Rohit Varma: ''[http://newdbpubs.stanford.edu:8090/pub/2002-41 Query Processing, Resource Management, and Approximation in a Data Stream Management System]''. Stanford, 2002 (CIDR 2003)

Thomas Dresler: Tippfehler korrigiert

2022-02-23T23:19:17Z

Tippfehler korrigiert

← Nächstältere Version		Version vom 24. Februar 2022, 01:19 Uhr
Zeile 107:		Zeile 107:

	== Weblinks ==		== Weblinks ==
	* [http://www-db.stanford.edu/stream STREAM], [http://www-db.stanford.edu/sdt/ Stream Team ~~HomePage~~]		* [http://www-db.stanford.edu/stream STREAM], [http://www-db.stanford.edu/sdt/ Stream Team Homepage]
	* [http://www.cs.brown.edu/research/aurora/ AURORA], [http://www.streambase.com/ StreamBase Systems, Inc.]		* [http://www.cs.brown.edu/research/aurora/ AURORA], [http://www.streambase.com/ StreamBase Systems, Inc.]
	* [http://telegraph.cs.berkeley.edu/telegraphcq/ TelegraphCQ]		* [http://telegraph.cs.berkeley.edu/telegraphcq/ TelegraphCQ]

Aka: /* Literatur */ falschen Punkt aus Abkürzung entfernt

2021-07-17T10:33:08Z

Literatur: falschen Punkt aus Abkürzung entfernt

← Nächstältere Version		Version vom 17. Juli 2021, 12:33 Uhr
Zeile 98:		Zeile 98:
	== Literatur ==		== Literatur ==
	* Brian Babcock, Shivnath Babu, Mayur Data, Rajeev Motwani, Jennifer Widom. ''[http://newdbpubs.stanford.edu:8090/pub/2002-19 Models and Issues in Data Stream Systems]''. In: Proceedings of 21st ACM Symposium on Principles of Database Systems (PODS 2002)		* Brian Babcock, Shivnath Babu, Mayur Data, Rajeev Motwani, Jennifer Widom. ''[http://newdbpubs.stanford.edu:8090/pub/2002-19 Models and Issues in Data Stream Systems]''. In: Proceedings of 21st ACM Symposium on Principles of Database Systems (PODS 2002)
	* Don Carney, Ugur Centintemel, Mitch Cherniack, et.al.: ''[http://www.cs.brown.edu/research/aurora/aurora_tr.pdf Monitoring Streams - A New Class of Data Management Applications] (PDF; 685 kB)''. (VLDB 2002)		* Don Carney, Ugur Centintemel, Mitch Cherniack, et al.: ''[http://www.cs.brown.edu/research/aurora/aurora_tr.pdf Monitoring Streams - A New Class of Data Management Applications] (PDF; 685 kB)''. (VLDB 2002)
	* Sandra Geisler: ''[http://drops.dagstuhl.de/opus/volltexte/2013/4297/pdf/ch10-geisler.pdf Data Stream Management Systems]''. Dagstuhl Follow-Ups. Vol. 5. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2013.		* Sandra Geisler: ''[http://drops.dagstuhl.de/opus/volltexte/2013/4297/pdf/ch10-geisler.pdf Data Stream Management Systems]''. Dagstuhl Follow-Ups. Vol. 5. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2013.
	* Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Manku, Chris Olston, Justin Rosenstein und Rohit Varma: ''[http://newdbpubs.stanford.edu:8090/pub/2002-41 Query Processing, Resource Management, and Approximation in a Data Stream Management System]''. Stanford, 2002 (CIDR 2003)		* Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Manku, Chris Olston, Justin Rosenstein und Rohit Varma: ''[http://newdbpubs.stanford.edu:8090/pub/2002-41 Query Processing, Resource Management, and Approximation in a Data Stream Management System]''. Stanford, 2002 (CIDR 2003)

31.209.89.182: /* Unterschiede zu DBMS */

2020-01-24T09:18:41Z

Unterschiede zu DBMS

← Nächstältere Version		Version vom 24. Januar 2020, 11:18 Uhr
Zeile 14:		Zeile 14:
	[[Datei:DSMS-Prinzip.svg\|mini\|Datenverarbeitung in einem DSMS]]		[[Datei:DSMS-Prinzip.svg\|mini\|Datenverarbeitung in einem DSMS]]

	In herkömmlichen Datenbanksystemen werden kurzzeitig laufende Anfragen auf eine während der Datenauswertung gleichbleibende Datenbasis gestellt (siehe [[Transaktionssystem]]). Die Anfragen werden gestartet und bleiben solange im System, bis die Ergebnisse berechnet und ausgegeben wurden. Danach sind die Anfragen nicht mehr im System vorhanden. Man spricht auch davon, dass die Daten persistent und die Anfragen flüchtig sind. In einem Data Stream Management System werden die Anfragen einmalig installiert und bleiben im System bestehen, bis sie explizit wieder entfernt werden. Die Anfragen werden auf sich laufend ändernden Daten ausgewertet, nämlich auf Datenströmen. Die Ergebnisse der Anfragen werden ebenfalls kontinuierlich aktualisiert, ergeben also selbst auch einen Datenstrom. Man spricht auch davon, dass die Anfragen persistent und die ~~Anfragen~~ flüchtig sind. Diese beiden komplementären Prinzipien sind beispielsweise auch beim [[Information Retrieval]] als ''Ad-hoc-Anfragen'' (neue Anfragen an gleiche Dokumente) und ''Routing-Aufgaben'' (neue Dokumente zu vorgegebenen Anfragen) bekannt.<ref>{{cite web \| url=http://trec.nist.gov/data/topics_eng/ \| title=Data – English Test Questions (Topics) Files List \| publisher=National Institute of Standards and Technology \| language=englisch \| accessdate=2019-02-14}}</ref>		In herkömmlichen Datenbanksystemen werden kurzzeitig laufende Anfragen auf eine während der Datenauswertung gleichbleibende Datenbasis gestellt (siehe [[Transaktionssystem]]). Die Anfragen werden gestartet und bleiben solange im System, bis die Ergebnisse berechnet und ausgegeben wurden. Danach sind die Anfragen nicht mehr im System vorhanden. Man spricht auch davon, dass die Daten persistent und die Anfragen flüchtig sind. In einem Data Stream Management System werden die Anfragen einmalig installiert und bleiben im System bestehen, bis sie explizit wieder entfernt werden. Die Anfragen werden auf sich laufend ändernden Daten ausgewertet, nämlich auf Datenströmen. Die Ergebnisse der Anfragen werden ebenfalls kontinuierlich aktualisiert, ergeben also selbst auch einen Datenstrom. Man spricht auch davon, dass die Anfragen persistent und die Daten flüchtig sind. Diese beiden komplementären Prinzipien sind beispielsweise auch beim [[Information Retrieval]] als ''Ad-hoc-Anfragen'' (neue Anfragen an gleiche Dokumente) und ''Routing-Aufgaben'' (neue Dokumente zu vorgegebenen Anfragen) bekannt.<ref>{{cite web \| url=http://trec.nist.gov/data/topics_eng/ \| title=Data – English Test Questions (Topics) Files List \| publisher=National Institute of Standards and Technology \| language=englisch \| accessdate=2019-02-14}}</ref>

	Die folgende Tabelle gibt einen Vergleich verschiedener Merkmale eines Database Management Systems (DBMS) und eines Data Stream Management Systems (DSMS):		Die folgende Tabelle gibt einen Vergleich verschiedener Merkmale eines Database Management Systems (DBMS) und eines Data Stream Management Systems (DSMS):

Starkiller3010: Weblink aus Fließtext entfernt. Einzelnachweis eingefügt

2019-02-14T15:13:59Z

Weblink aus Fließtext entfernt. Einzelnachweis eingefügt

← Nächstältere Version		Version vom 14. Februar 2019, 17:13 Uhr
Zeile 14:		Zeile 14:
	[[Datei:DSMS-Prinzip.svg\|mini\|Datenverarbeitung in einem DSMS]]		[[Datei:DSMS-Prinzip.svg\|mini\|Datenverarbeitung in einem DSMS]]

	In herkömmlichen Datenbanksystemen werden kurzzeitig laufende Anfragen auf eine während der Datenauswertung gleichbleibende Datenbasis gestellt (siehe [[Transaktionssystem]]). Die Anfragen werden gestartet und bleiben solange im System, bis die Ergebnisse berechnet und ausgegeben wurden. Danach sind die Anfragen nicht mehr im System vorhanden. Man spricht auch davon, dass die Daten persistent und die Anfragen flüchtig sind. In einem Data Stream Management System werden die Anfragen einmalig installiert und bleiben im System bestehen, bis sie explizit wieder entfernt werden. Die Anfragen werden auf sich laufend ändernden Daten ausgewertet, nämlich auf Datenströmen. Die Ergebnisse der Anfragen werden ebenfalls kontinuierlich aktualisiert, ergeben also selbst auch einen Datenstrom. Man spricht auch davon, dass die Anfragen persistent und die Anfragen flüchtig sind. Diese beiden komplementären Prinzipien sind beispielsweise auch beim [[Information Retrieval]] als ''Ad-hoc-Anfragen'' (neue Anfragen an gleiche Dokumente) und ''Routing-Aufgaben'' (neue Dokumente zu vorgegebenen Anfragen) bekannt ~~(siehe~~ [http://trec.nist.gov/data/topics_eng/]).		In herkömmlichen Datenbanksystemen werden kurzzeitig laufende Anfragen auf eine während der Datenauswertung gleichbleibende Datenbasis gestellt (siehe [[Transaktionssystem]]). Die Anfragen werden gestartet und bleiben solange im System, bis die Ergebnisse berechnet und ausgegeben wurden. Danach sind die Anfragen nicht mehr im System vorhanden. Man spricht auch davon, dass die Daten persistent und die Anfragen flüchtig sind. In einem Data Stream Management System werden die Anfragen einmalig installiert und bleiben im System bestehen, bis sie explizit wieder entfernt werden. Die Anfragen werden auf sich laufend ändernden Daten ausgewertet, nämlich auf Datenströmen. Die Ergebnisse der Anfragen werden ebenfalls kontinuierlich aktualisiert, ergeben also selbst auch einen Datenstrom. Man spricht auch davon, dass die Anfragen persistent und die Anfragen flüchtig sind. Diese beiden komplementären Prinzipien sind beispielsweise auch beim [[Information Retrieval]] als ''Ad-hoc-Anfragen'' (neue Anfragen an gleiche Dokumente) und ''Routing-Aufgaben'' (neue Dokumente zu vorgegebenen Anfragen) bekannt.<ref>{{cite web \| url=http://trec.nist.gov/data/topics_eng/ \| title=Data – English Test Questions (Topics) Files List \| publisher=National Institute of Standards and Technology \| language=englisch \| accessdate=2019-02-14}}</ref>

	Die folgende Tabelle gibt einen Vergleich verschiedener Merkmale eines Database Management Systems (DBMS) und eines Data Stream Management Systems (DSMS):		Die folgende Tabelle gibt einen Vergleich verschiedener Merkmale eines Database Management Systems (DBMS) und eines Data Stream Management Systems (DSMS):

91.15.255.247: Typo

2018-08-16T17:28:21Z

Typo

← Nächstältere Version		Version vom 16. August 2018, 19:28 Uhr
Zeile 66:		Zeile 66:

	=== One-pass Paradigma ===		=== One-pass Paradigma ===
	Die Ressourcen im Sinne von Rechenzeit und Speicherplatz zur Berechnung von Ergebnissen auf Datenströmen ~~ist~~ begrenzt. Algorithmen, die Datenströme verarbeiten, speichern die Daten deshalb typischerweise nicht erst vollständig und iterieren dann über den gesamten Datensatz, um Ergebnisse zu erzeugen, sondern verarbeiten jedes einzelne Element im Datenstrom nur einmal. Dies nennt man One-Pass Paradigma: Ein Datenelement durchläuft einen Algorithmus nur einmal<ref name=Geisler2013 />. Erreicht ein neues Element den Algorithmus, wird das Ergebnis der Berechnung angepasst und es ist kein neuer Zugriff auf das Element zu einem späteren Zeitpunkt mehr notwendig. Deshalb muss der Algorithmus keine alten Elemente speichern, sondern nur das aktuelle Zwischenergebnis.		Die Ressourcen im Sinne von Rechenzeit und Speicherplatz zur Berechnung von Ergebnissen auf Datenströmen sind begrenzt. Algorithmen, die Datenströme verarbeiten, speichern die Daten deshalb typischerweise nicht erst vollständig und iterieren dann über den gesamten Datensatz, um Ergebnisse zu erzeugen, sondern verarbeiten jedes einzelne Element im Datenstrom nur einmal. Dies nennt man One-Pass Paradigma: Ein Datenelement durchläuft einen Algorithmus nur einmal<ref name=Geisler2013 />. Erreicht ein neues Element den Algorithmus, wird das Ergebnis der Berechnung angepasst und es ist kein neuer Zugriff auf das Element zu einem späteren Zeitpunkt mehr notwendig. Deshalb muss der Algorithmus keine alten Elemente speichern, sondern nur das aktuelle Zwischenergebnis.

	Dies funktioniert zum Beispiel bei einem einfachen Zähler. Die Anzahl der Objekte soll gezählt werden. Kommt ein neues Element bei dem Algorithmus an, wird der Zähler um eins erhöht, gespeichert und das Element kann gelöscht werden. Nur der aktuelle Zählerstand muss gespeichert werden.		Dies funktioniert zum Beispiel bei einem einfachen Zähler. Die Anzahl der Objekte soll gezählt werden. Kommt ein neues Element bei dem Algorithmus an, wird der Zähler um eins erhöht, gespeichert und das Element kann gelöscht werden. Nur der aktuelle Zählerstand muss gespeichert werden.

GünniX: Tippfehler entfernt

2018-07-29T10:58:26Z

Tippfehler entfernt

← Nächstältere Version		Version vom 29. Juli 2018, 12:58 Uhr
Zeile 65:		Zeile 65:
	Element- und zeitbasierte Fenster können unterschiedlich definiert werden. Hier wird hauptsächlich zwischen gleitenden (engl. ''sliding'') und taumelnden bzw. springenden (engl. ''tumbling'') Fenstern unterschieden. Der Unterschied besteht in der Schrittgröße des Fensters, auch Periodizität genannt. Ein gleitendes Fenster schreitet mit dem Fortschritt des Datenstroms so voran, dass die Schrittweite minimal ist. In einem elementbasierten Fenster würde für ein neues Element, dass in das Fenster aufgenommen wird, also genau ein Element wieder entfernt werden. Die Schrittweite kann soweit verändert werden, dass sie die Größe des Fensters hat, dies nennt man dann ein taumelndes Fenster (engl. ''tumbling window''). Hier wird ein Fenster bis zur angegebenen Größe gefüllt. Beim Eintreffen des nächsten Elementes, womit die angegebene Größe des Fensters überschritten werden würde, werden alle vorherigen Elemente gleichzeitig ungültig, und das neue Fenster wird schrittweise aufgebaut, bis es wieder die maximale Größe erreicht hat. In zeitbasierten Fenstern geschieht dies analog. Ein taumelndes Fenster wäre zum Beispiel ein Fenster der Größe von 30 Minuten und einer Schrittweite von 30 Minuten<ref name=Geisler2013 />.		Element- und zeitbasierte Fenster können unterschiedlich definiert werden. Hier wird hauptsächlich zwischen gleitenden (engl. ''sliding'') und taumelnden bzw. springenden (engl. ''tumbling'') Fenstern unterschieden. Der Unterschied besteht in der Schrittgröße des Fensters, auch Periodizität genannt. Ein gleitendes Fenster schreitet mit dem Fortschritt des Datenstroms so voran, dass die Schrittweite minimal ist. In einem elementbasierten Fenster würde für ein neues Element, dass in das Fenster aufgenommen wird, also genau ein Element wieder entfernt werden. Die Schrittweite kann soweit verändert werden, dass sie die Größe des Fensters hat, dies nennt man dann ein taumelndes Fenster (engl. ''tumbling window''). Hier wird ein Fenster bis zur angegebenen Größe gefüllt. Beim Eintreffen des nächsten Elementes, womit die angegebene Größe des Fensters überschritten werden würde, werden alle vorherigen Elemente gleichzeitig ungültig, und das neue Fenster wird schrittweise aufgebaut, bis es wieder die maximale Größe erreicht hat. In zeitbasierten Fenstern geschieht dies analog. Ein taumelndes Fenster wäre zum Beispiel ein Fenster der Größe von 30 Minuten und einer Schrittweite von 30 Minuten<ref name=Geisler2013 />.

	=== One-pass ~~Pradigma~~ ===		=== One-pass Paradigma ===
	Die Ressourcen im Sinne von Rechenzeit und Speicherplatz zur Berechnung von Ergebnissen auf Datenströmen ist begrenzt. Algorithmen, die Datenströme verarbeiten, speichern die Daten deshalb typischerweise nicht erst vollständig und iterieren dann über den gesamten Datensatz, um Ergebnisse zu erzeugen, sondern verarbeiten jedes einzelne Element im Datenstrom nur einmal. Dies nennt man One-Pass Paradigma: Ein Datenelement durchläuft einen Algorithmus nur einmal<ref name=Geisler2013 />. Erreicht ein neues Element den Algorithmus, wird das Ergebnis der Berechnung angepasst und es ist kein neuer Zugriff auf das Element zu einem späteren Zeitpunkt mehr notwendig. Deshalb muss der Algorithmus keine alten Elemente speichern, sondern nur das aktuelle Zwischenergebnis.		Die Ressourcen im Sinne von Rechenzeit und Speicherplatz zur Berechnung von Ergebnissen auf Datenströmen ist begrenzt. Algorithmen, die Datenströme verarbeiten, speichern die Daten deshalb typischerweise nicht erst vollständig und iterieren dann über den gesamten Datensatz, um Ergebnisse zu erzeugen, sondern verarbeiten jedes einzelne Element im Datenstrom nur einmal. Dies nennt man One-Pass Paradigma: Ein Datenelement durchläuft einen Algorithmus nur einmal<ref name=Geisler2013 />. Erreicht ein neues Element den Algorithmus, wird das Ergebnis der Berechnung angepasst und es ist kein neuer Zugriff auf das Element zu einem späteren Zeitpunkt mehr notwendig. Deshalb muss der Algorithmus keine alten Elemente speichern, sondern nur das aktuelle Zwischenergebnis.

GünniX: Klammern korrigiert

2018-07-29T08:36:02Z

Klammern korrigiert

← Nächstältere Version		Version vom 29. Juli 2018, 10:36 Uhr
Zeile 14:		Zeile 14:
	[[Datei:DSMS-Prinzip.svg\|mini\|Datenverarbeitung in einem DSMS]]		[[Datei:DSMS-Prinzip.svg\|mini\|Datenverarbeitung in einem DSMS]]

	In herkömmlichen Datenbanksystemen werden kurzzeitig laufende Anfragen auf eine während der Datenauswertung gleichbleibende Datenbasis gestellt (siehe [[Transaktionssystem]]. Die Anfragen werden gestartet und bleiben solange im System, bis die Ergebnisse berechnet und ausgegeben wurden. Danach sind die Anfragen nicht mehr im System vorhanden. Man spricht auch davon, dass die Daten persistent und die Anfragen flüchtig sind. In einem Data Stream Management System werden die Anfragen einmalig installiert und bleiben im System bestehen, bis sie explizit wieder entfernt werden. Die Anfragen werden auf sich laufend ändernden Daten ausgewertet, nämlich auf Datenströmen. Die Ergebnisse der Anfragen werden ebenfalls kontinuierlich aktualisiert, ergeben also selbst auch einen Datenstrom. Man spricht auch davon, dass die Anfragen persistent und die Anfragen flüchtig sind. Diese beiden komplementären Prinzipien sind beispielsweise auch beim [[Information Retrieval]] als ''Ad-hoc-Anfragen'' (neue Anfragen an gleiche Dokumente) und ''Routing-Aufgaben'' (neue Dokumente zu vorgegebenen Anfragen) bekannt (siehe [http://trec.nist.gov/data/topics_eng/]).		In herkömmlichen Datenbanksystemen werden kurzzeitig laufende Anfragen auf eine während der Datenauswertung gleichbleibende Datenbasis gestellt (siehe [[Transaktionssystem]]). Die Anfragen werden gestartet und bleiben solange im System, bis die Ergebnisse berechnet und ausgegeben wurden. Danach sind die Anfragen nicht mehr im System vorhanden. Man spricht auch davon, dass die Daten persistent und die Anfragen flüchtig sind. In einem Data Stream Management System werden die Anfragen einmalig installiert und bleiben im System bestehen, bis sie explizit wieder entfernt werden. Die Anfragen werden auf sich laufend ändernden Daten ausgewertet, nämlich auf Datenströmen. Die Ergebnisse der Anfragen werden ebenfalls kontinuierlich aktualisiert, ergeben also selbst auch einen Datenstrom. Man spricht auch davon, dass die Anfragen persistent und die Anfragen flüchtig sind. Diese beiden komplementären Prinzipien sind beispielsweise auch beim [[Information Retrieval]] als ''Ad-hoc-Anfragen'' (neue Anfragen an gleiche Dokumente) und ''Routing-Aufgaben'' (neue Dokumente zu vorgegebenen Anfragen) bekannt (siehe [http://trec.nist.gov/data/topics_eng/]).

	Die folgende Tabelle gibt einen Vergleich verschiedener Merkmale eines Database Management Systems (DBMS) und eines Data Stream Management Systems (DSMS):		Die folgende Tabelle gibt einen Vergleich verschiedener Merkmale eines Database Management Systems (DBMS) und eines Data Stream Management Systems (DSMS):

St. Neptun: Typo, Groß-/Kleinschreibung

2018-07-26T20:21:57Z

Typo, Groß-/Kleinschreibung

← Nächstältere Version		Version vom 26. Juli 2018, 22:21 Uhr
Zeile 63:		Zeile 63:
	Fenster begrenzen die Sicht auf den Datenstrom auf die neuesten Elemente des Stroms. Verbreitet sind zeit- und elementbasierte (auch: tupelbasierte) Fenster<ref name=Geisler2013 />. In zeitbasierten Fenstern werden die Elemente im Datenstrom eine gewisse, vorgegebene Zeit im System gehalten, zum Beispiel 30 Minuten. In einem elementbasierten Fenster enthält das Fenster maximal eine vorgegebene Menge an Elementen, zum Beispiel die neuesten 1000 Elemente. Ein Beispiel für eine Anfrage mit einem zeitbasierten Fenster ist: „Berechne den Durchschnitt des Attributs ‚x‘ von allen Datenstromelementen der letzten 30 Minuten.“		Fenster begrenzen die Sicht auf den Datenstrom auf die neuesten Elemente des Stroms. Verbreitet sind zeit- und elementbasierte (auch: tupelbasierte) Fenster<ref name=Geisler2013 />. In zeitbasierten Fenstern werden die Elemente im Datenstrom eine gewisse, vorgegebene Zeit im System gehalten, zum Beispiel 30 Minuten. In einem elementbasierten Fenster enthält das Fenster maximal eine vorgegebene Menge an Elementen, zum Beispiel die neuesten 1000 Elemente. Ein Beispiel für eine Anfrage mit einem zeitbasierten Fenster ist: „Berechne den Durchschnitt des Attributs ‚x‘ von allen Datenstromelementen der letzten 30 Minuten.“

	Element- und zeitbasierte Fenster können unterschiedlich definiert werden. Hier wird hauptsächlich zwischen gleitenden (engl. ''sliding'') und taumelnden bzw. springenden (engl. ''tumbling'') Fenstern unterschieden. Der Unterschied besteht in der Schrittgröße des Fensters, auch Periodizität genannt. Ein gleitendes Fenster schreitet mit dem Fortschritt des Datenstroms so voran, dass die Schrittweite minimal ist. In einem elementbasierten Fenster würde für ein neues Element, dass in das Fenster aufgenommen wird, also genau ein Element wieder entfernt werden. Die Schrittweite kann soweit verändert werden, dass sie die Größe des Fensters hat, dies nennt man dann ein ~~taumlendes~~ Fenster (engl. ''tumbling window''). Hier wird ein Fenster bis zur angegebenen Größe gefüllt. Beim ~~eintreffen~~ des nächsten Elementes, womit die angegebene Größe des Fensters überschritten werden würde, werden alle vorherigen Elemente gleichzeitig ungültig, und das neue Fenster wird schrittweise aufgebaut, bis es wieder die maximale Größe erreicht hat. In zeitbasierten Fenstern geschieht dies analog. Ein taumelndes Fenster wäre zum Beispiel ein Fenster der Größe von 30 Minuten und einer Schrittweite von 30 Minuten<ref name=Geisler2013 />.		Element- und zeitbasierte Fenster können unterschiedlich definiert werden. Hier wird hauptsächlich zwischen gleitenden (engl. ''sliding'') und taumelnden bzw. springenden (engl. ''tumbling'') Fenstern unterschieden. Der Unterschied besteht in der Schrittgröße des Fensters, auch Periodizität genannt. Ein gleitendes Fenster schreitet mit dem Fortschritt des Datenstroms so voran, dass die Schrittweite minimal ist. In einem elementbasierten Fenster würde für ein neues Element, dass in das Fenster aufgenommen wird, also genau ein Element wieder entfernt werden. Die Schrittweite kann soweit verändert werden, dass sie die Größe des Fensters hat, dies nennt man dann ein taumelndes Fenster (engl. ''tumbling window''). Hier wird ein Fenster bis zur angegebenen Größe gefüllt. Beim Eintreffen des nächsten Elementes, womit die angegebene Größe des Fensters überschritten werden würde, werden alle vorherigen Elemente gleichzeitig ungültig, und das neue Fenster wird schrittweise aufgebaut, bis es wieder die maximale Größe erreicht hat. In zeitbasierten Fenstern geschieht dies analog. Ein taumelndes Fenster wäre zum Beispiel ein Fenster der Größe von 30 Minuten und einer Schrittweite von 30 Minuten<ref name=Geisler2013 />.

	=== One-pass Pradigma ===		=== One-pass Pradigma ===
Zeile 73:		Zeile 73:
	[[Datei:DSBS-Aufbau.svg\|mini\|Aufbau eines DSMS]]		[[Datei:DSBS-Aufbau.svg\|mini\|Aufbau eines DSMS]]

	Während in herkömmlichen (~~relationale~~) Datenbanksystemen die Daten in Tabellen ([[Relation (Datenbank)\|Relationen]]) verwaltet werden, kommen in einem DSMS als grundlegende Datenobjekte Datenströme hinzu. Datenströme können als kontinuierliche Folge von Zeit-Wertepaaren aufgefasst werden. Da Datenströme prinzipiell unendlich sind, müssen sie zur Verarbeitung zwischenzeitlich in Relationen umgewandelt werden. Umgekehrt können Relationen wieder in Datenströme umgewandelt werden (siehe Abbildung). Die Verarbeitung von reinen Relationen kann mit herkömmlichen Methoden stattfinden. Die Umwandlung von Strömen in andere Ströme findet über den Umweg von Relationen statt. Die auf [[SQL]] aufbauende [[Continuous Query Language]] bietet dazu verschiedene Operatoren an.		Während in herkömmlichen (relationalen) Datenbanksystemen die Daten in Tabellen ([[Relation (Datenbank)\|Relationen]]) verwaltet werden, kommen in einem DSMS als grundlegende Datenobjekte Datenströme hinzu. Datenströme können als kontinuierliche Folge von Zeit-Wertepaaren aufgefasst werden. Da Datenströme prinzipiell unendlich sind, müssen sie zur Verarbeitung zwischenzeitlich in Relationen umgewandelt werden. Umgekehrt können Relationen wieder in Datenströme umgewandelt werden (siehe Abbildung). Die Verarbeitung von reinen Relationen kann mit herkömmlichen Methoden stattfinden. Die Umwandlung von Strömen in andere Ströme findet über den Umweg von Relationen statt. Die auf [[SQL]] aufbauende [[Continuous Query Language]] bietet dazu verschiedene Operatoren an.

	== Formulierung, Planung und Optimierung von Anfragen ==		== Formulierung, Planung und Optimierung von Anfragen ==

Aka: /* Kontinuierliche Anfragen */ Abkürzung korrigiert

2018-07-23T22:32:45Z

Kontinuierliche Anfragen: Abkürzung korrigiert

← Nächstältere Version		Version vom 24. Juli 2018, 00:32 Uhr
Zeile 56:		Zeile 56:
	Eine kontinuierliche Anfrage wird einmalig im System installiert und läuft solange, bis sie wieder entfernt wird. Die Anfrage hat einen oder mehrere Eingangsdatenströme und einen oder mehrere Ausgangsdatenströme. Das Ergebnis einer solchen Anfrage ist also kein einmaliger Satz an Daten, wie bei einer Anfrage in einem DBMS, sondern selbst ein Datenstrom. Die Ergebnisse sollten in nahezu Echtzeit erstellt werden, womit die Latenz zwischen der Ankunft neuer Daten und der Ausgabe eines neuen Ergebnisses von hoher Relevanz ist<ref name=Geisler2013>{{Literatur \|Autor=Sandra Geisler \|Titel=Data Stream Management Systems \|Hrsg=Phokion G. Kolaitis and Maurizio Lenzerini and Nicole Schweikardt \|Sammelwerk=Dagstuhl Follow-Ups \|Band=5 \|Nummer= \|Auflage= \|Verlag=Schloss Dagstuhl--Leibniz-Zentrum fuer Informatik \|Ort=Dagstuhl, Germany \|Datum=2013 \|Seiten=275-304 \|ISBN=978-3-939897-61-3 \|DOI=10.4230/DFU.Vol5.10452.275 \|Online=http://drops.dagstuhl.de/opus/volltexte/2013/4297}}</ref>.		Eine kontinuierliche Anfrage wird einmalig im System installiert und läuft solange, bis sie wieder entfernt wird. Die Anfrage hat einen oder mehrere Eingangsdatenströme und einen oder mehrere Ausgangsdatenströme. Das Ergebnis einer solchen Anfrage ist also kein einmaliger Satz an Daten, wie bei einer Anfrage in einem DBMS, sondern selbst ein Datenstrom. Die Ergebnisse sollten in nahezu Echtzeit erstellt werden, womit die Latenz zwischen der Ankunft neuer Daten und der Ausgabe eines neuen Ergebnisses von hoher Relevanz ist<ref name=Geisler2013>{{Literatur \|Autor=Sandra Geisler \|Titel=Data Stream Management Systems \|Hrsg=Phokion G. Kolaitis and Maurizio Lenzerini and Nicole Schweikardt \|Sammelwerk=Dagstuhl Follow-Ups \|Band=5 \|Nummer= \|Auflage= \|Verlag=Schloss Dagstuhl--Leibniz-Zentrum fuer Informatik \|Ort=Dagstuhl, Germany \|Datum=2013 \|Seiten=275-304 \|ISBN=978-3-939897-61-3 \|DOI=10.4230/DFU.Vol5.10452.275 \|Online=http://drops.dagstuhl.de/opus/volltexte/2013/4297}}</ref>.

	Wichtig bei einer kontinuierlichen Anfrage ist die Definition, wann eine neue Ausgabe produziert wird. Ein zeitgetriebenes Modell (engl. ''time-driven model'') erzeugt neue Ausgaben anhand des zeitlichen Fortschritts einer Uhr, zum Beispiel der Systemzeit. So könnte eine neue Ausgabe einmal pro Minute erzeugt werden. Ein anderer Ansatz sind ereignisgetriebene Modelle (engl. ''event-driven model''), bei denen neue Ausgaben erzeugt werden, wenn gewisse Ereignisse im Datenstrom auftreten. So könnte z.B. jedes neue Datenelement in einem Strom eine neue Ausgabe erzeugen, da dieses Datenstromelement das Ergebnis für diesen Zeitpunkt beeinflussen kann. Dann spricht man auch von einem tupelgetriebenen Modell (engl. ''tuple-driven model'')<ref name="Geisler2013" />.		Wichtig bei einer kontinuierlichen Anfrage ist die Definition, wann eine neue Ausgabe produziert wird. Ein zeitgetriebenes Modell (engl. ''time-driven model'') erzeugt neue Ausgaben anhand des zeitlichen Fortschritts einer Uhr, zum Beispiel der Systemzeit. So könnte eine neue Ausgabe einmal pro Minute erzeugt werden. Ein anderer Ansatz sind ereignisgetriebene Modelle (engl. ''event-driven model''), bei denen neue Ausgaben erzeugt werden, wenn gewisse Ereignisse im Datenstrom auftreten. So könnte z. B. jedes neue Datenelement in einem Strom eine neue Ausgabe erzeugen, da dieses Datenstromelement das Ergebnis für diesen Zeitpunkt beeinflussen kann. Dann spricht man auch von einem tupelgetriebenen Modell (engl. ''tuple-driven model'')<ref name="Geisler2013" />.

	=== Fenster ===		=== Fenster ===