ProjINF - Reduzierung der Netzwerklast von CEP unter Zuhilfenahme von Datenbanken

Transkript

1 ProjINF - Reduzierung der Netzwerklast von CEP unter Zuhilfenahme von Datenbanken Benjamin Braun, Karsten Schatz, und Vethiga Srikanthan Abstract Die Bedeutung von Complex Event Processing (CEP) nimmt heutzutage immer weiter zu. Sei es bei der Analyse bzw. Überwachung von Börsendaten oder bei der Beobachtung von Geschäftsprozessen. Für solche Fälle verwendet man meist stark verteilte Systeme, da zum Beispiel bei der Überwachung des Weltmarktes Daten aus vielen verschiedenen Quellen weltweit benötigt werden. In aktuellen CEP-Systemen werden jedoch zumeist alle erzeugten Daten übertragen, um die Verfügbarkeit aller relevanten Werte zu gewährleisten. Dies kann unter Umständen eine sehr hohe Netzwerklast verursachen. In dieser Arbeit präsentieren wir einen Ansatz, der die anfallenden Daten in Klassen von hochfrequenten und niederfrequenten Datenströmen einteilt, um mit Hilfe dieser Einteilung die Netzwerklast zu verringern. Hierbei werden die hochfrequenten, also für die Netzwerklast schlechteren, Datenströme nicht versandt, sondern in einer Datenbank zurückgehalten. Wird das Eintreffen von niederfrequenten Daten detektiert, werden die relevanten hochfrequenten Daten aus der Datenbank abgefragt. Bei entsprechendem Verhältnis von niederfrequenten zu hochfrequenten Daten kann dies die Netzwerklast um über 90% vermindern, wie wir auch in einigen Experimenten zeigen. Index Terms Complex Event Processing, Verringerung von Netzwerklast. 1 EINFÜHRUNG Complex Event Processing (kurz CEP) bezeichnet Techniken, Methoden und Werkzeuge, die Ereignisse zeitnah verarbeiten. Dabei werden sogenannte Events bearbeitet. Es gibt zwei Arten von Events: Einfache Events und komplexe Events. Einfache Events enthalten Werte von z.b. Sensoren. Werden diese Events vom CEP-System gefiltert, zusammengefügt und miteinander verglichen, stellen die Ergebnisse dann komplexe Events dar. Diese komplexen Events können wiederum zu einem komplexen Event weiterverarbeitet werden. Das CEP- System verarbeitet Eventströme von einer oder mehreren Informationsquellen. Diese Eventströme enthalten zeitlich geordnete Werte, also Events, die sowohl eine fachliche Information, als auch einen Zeitstempel enthalten. Abbildung 1: Beispiel für CEP Betrachten wir nun folgende Situation: Der Winterdienst möchte anhand von Wetterdaten bestimmen, ob Schneegefahr besteht. Dazu benötigt man die aktuelle Temperatur und die Menge des Niederschlags. Diese Werte werden als einfache Events empfangen. Man muss jedoch festsetzen, bei welchen Werten Schnee möglich ist. Dazu verwendet man komplexe Events, die z.b. aussagen, dass der Niederschlag über 10l/m 2 und die Temperatur unter 4 C sein muss. Um komplexe Events zu berechnen, werden Operatoren verwendet. Ein Operator nimmt einfache Events entgegen und überprüft, ob die Bedingungen für komplexe Events erfüllt sind. Sind diese Bedingungen erfüllt, so meldet der Operator das Eintreten des komplexen Events. Um Operatoren zu beschreiben, werden in der Praxis Event Processing Languages (EPLs) verwendet, die in der Regel ähnlich zu SQL sind. Operatoren wiederum werden in CEP-Engines ausgeführt. In dieser Arbeit wird als CEP-Engine Esper verwendet. Das ge- samte CEP-Systems besteht aus einem Netzwerk von mehreren CEP- Engines, die miteinander kommunizieren. Bei ständiger Übertragung der Events ist die Netzwerklast sehr hoch. Im System werden Events übertragen, die für die Erkennung von komplexen Events nicht notwendig sind. Es muss eine Lösung gefunden werden, durch die die Last im Netzwerk reduziert werden kann, ohne relevante Informationen zu verlieren, indem man diese nicht relevanten Events nicht überträgt. In unserem Anwendungsbeispiel soll die Temperatur das hochfrequente Event und der Niederschlag das niederfrequente Event sein. Ein Niederschlagswert über 10l/m 2 tritt nicht so häufig auf, wie ein Temperaturwert unter 4 C. Es entstehen also viele Temperaturwerte, die nicht relevant für den Schneefall sind, da der Niederschlag nicht so häufig über 10l/m 2 ist. Es müsste also genügen die Temperatur nur bei einem Niederschlagswert über 10l/m 2 auszulesen und auf die Bedingung für ein komplexes Event hin zu prüfen. Um die Netzwerklast zu reduzieren, müssen wir also einen Weg finden, bei dem Ereignisse, die häufig auftreten, abgespeichert und bei Bedarf entnommen werden. Ereignisse, die nicht so häufig auftreten, sollen kontinuierlich weitergeleitet werden. In unserem Fall sollte der Temperaturwert nicht verloren gehen, aber auch nicht ständig übertragen werden. Hier führen wir eine Datenbank ein. In dieser Datenbank werden Temperaturwerte gespeichert. Sie werden also abrufbereit gelagert. Tritt dann ein Niederschlagswert ein, bei dem Schneefall möglich ist, wird die Temperatur aus der Datenbank erfragt. So werden nur die Events übertragen, die relevant sein könnten. Im Folgenden klären wir in Sektion 2 (Systemmodell) einige grundlegenden Begriffsbedeutungen und die allgemeine Funktion unseres Systems. In Sektion 3 geben wir eine genaue Erklärung für unser System wie Datenbank und Trigger genau funktionieren. Zusätzlich erläutern wir auch Hindernisse, die wir dabei entdeckt haben. In Sektion 4 stellen wir unsere Testergebnisse für unser System dar. Hierbei betrachten wir sowohl die Netzwerklast, als auch die Berechnungsdauer unseres Systems im Vergleich zur Methode ohne Datenbank. In Sektion 5 geben wir noch einen Überblick über verwandte Arbeiten auf diesem Gebiet und stellen dar, wie die aktuelle Situation aus wissenschaftlicher Sicht ist. In Sektion 6 fassen wir unsere Arbeit zusammen und geben einen kurzen Ausblick auf Dinge, mit der wir unsere Arbeit erweitern könnten. Benjamin Braun Karsten Schatz Vethiga Srikanthan 2 SYSTEMMODELL Das System, das uns vorliegt, ist ein CEP-System. Es ist ein Netzwerk von Operatoren, welche durch Eventströme verbunden sind. Über diese Eventströme werden Events verschickt. Sowohl der Sender, als auch 1

2 Abbildung 2: Systemmodell der Empfänger sind also Operatoren, die in CEP-Engines ausgeführt werden. Der Operator, der als Sender fungiert, verschickt die gemessenen oder erzeugten Werte. Der Empfänger erhält die in Events enthaltenen Werte und verarbeitet diese zu neuen, komplexen Events. Leitet der zweite Operator das Event erneut weiter, funktioniert in diesem Fall der Operator sowohl als Empfänger, als auch als Sender. Somit haben wir eine Verarbeitungskette. Die Verbindung zwischen allen Sendern und Empfängern ist also unser Netzwerk (Abbildung 2). Operatoren im System implementieren somit eine Funktion, die den Eingang auf den Ausgang bildet. Seien e 1 und e 2 Events, die vom Sender verschickt werden. Somit führen die Operatoren folgendes aus: f (e 1,e 2 ). Doch bei diesem System ist erkennbar, dass die Last auf den Eventströmen bei ständiger Übertragung sehr hoch ist. Unser Ziel ist es, eine Lösung zu finden, durch die bereits nahe dem Sender Events abgefangen werden und somit eine geringe Netzwerklast zu erreichen. Dazu wird für jeden Eventstrom überprüft, ob eine kontinuierliche Übertragung notwendig ist, oder ob die Netzwerklast durch zurückhalten des Stroms effektiv optimiert werden kann. 3 SYSTEMANSATZ Um unseren Ansatz zu beschreiben, betrachten wir im Folgenden einen einzelnen Operator des CEP-Systems. Sei o 3 aus Abbildung 2 der betrachtete Operator. Dieser besitzt zwei Eingangsströme, welche verarbeitet werden. Einer dieser Eingangsströme ist hochfrequent (angenommen o 1 ), der andere niederfrequent (o 2 ). Da immer Events beider Ströme gekoppelt und gemeinsam verarbeitet werden, werden nur wenige Events des hochfrequenten Stroms wirklich verwendet. Deshalb können wir alle Events des hochfrequenten Stroms in einer Datenbank abspeichern und bei Bedarf entnehmen. Niederfrequente Events werden, wie in Abbildung 3 skizziert, an einen Trigger übergeben, jedoch nicht in der Datenbank gespeichert. Zuvor werden diese Events von einer erste CEP-Engine (Engine Instanz 1) überprüft. An dieser Stelle wäre nicht zwangsläufig eine CEP-Instanz notwendig um das schlichte Eintreffen von Events zu detektieren, jedoch kann hier eine Vorfilterung durchgeführt werden, um später die Netzwerklast noch weiter einschränken zu können. Wird nun ein niederfrequentes Event festgestellt, werden sowohl das niederfrequente als auch das hochfrequente Event aus der Datenbank von einer zweiten CEP-Engine (Engine Instanz 2) überprüft, um festzustellen, ob die Bedingungen für ein komplexes Event erfüllt sind. Deren Auftreten wird dann dem System mitgeteilt. 4 SYSTEMIMPLEMETIERUNG Der in Kapitel 3 vorgestellte Ansatz wurde prototypisch implementiert. Dabei kamen die Esper Korellationsengine als CEP-Engine, und eine SQL Datenbank zum Einsatz. Dazu wurde ein Trigger erstellt, der Abbildung 3: Aufbau unseres Systems nach der ersten Esper-Instanz die Ansteuerung der Datenbank durchführt. Sobald ein niederfrequentes Event durch die erste CEP-Instanz, der Esper-Instanz, festgestellt wird, wird eine SQL-Abfrage für die Datenbank vom Trigger erstellt und durchgeführt. Diese erfragt von der Datenbank alle für die registrierten komplexen Eventbeschreibungen nötigen Events. Nach Erhalt der Events aus der Datenbank werden diese in den Eventstrom der zweiten Esper-Instanz eingespeist gefolgt vom verursachenden Event. Die zweite Esper-Instanz überprüft an den Events aus dem zweiten Eventstrom, ob die Bedingungen für ein komplexes Event erfüllt sind und teilt dem System, wie bereits erwähnt, deren Auftreten mit. Das Netzwerk ist beim verteilten CEP üblicherweise stark ausgelastet und soll mit Hilfe der Datenbank entlastet werden. Die Datenbank enthält einfache Events, die momentan nicht zur Weiterverarbeitung benötigt werden. Alle Events werden nach der Reihe, wie sie bei der Datenbank eintreffen, sortiert. Jedes Event bekommt eine ID und einen Zeitstempel, die zur Weiterverarbeitung benötigt werden. 4.1 Datenbank Die Datenbank ist in diesem Konzept einzig und allein zur Abspeicherung von schnell hintereinander eintreffenden Events ausgelegt. Esper bietet drei unterschiedliche Eventrepräsentationen an. Die am einfachsten umzusetzende dieser drei ist das Java-Objekt. Die Abspeicherung von XML-Events beispielsweise, würde eine XML-Datenbank erfordern, was nachweislich den Netzwerktraffic in die Höhe treiben würde, da zusätzlich zu den reinen Daten auch noch die XML- Beschreibung übertragen werden müsste. Es existiert eine ganze Reihe von Java-Bibliotheken, die die Abspeicherung von Objekten in Datenbanken anbieten. Unsere Wahl fiel auf EclipseLink. Die einzige Restriktion dieser Bibliothek ist die Einschränkung auf weitgehend primitive Datentypen. Events bestehen fast definitionsgemäß nur aus primitiven Werten bzw. Datentypen, somit ist dies nicht hinderlich. Außerdem muss es sich bei dem übergebenen Objekt um ein JavaBean handeln. Diese spezielle Form eines Java-Objekts stört Esper nicht in dessen Ausführung, bietet aber für die weitere Verarbeitung im Trigger noch weitere Vorteile, womit dies 2

3 auch keine wirkliche Einschränkung darstellt. So wird für jede Art von schnellem Event eine eigene Tabelle in der Datenbank angelegt. Dies vereinfacht die spätere Abfrage der Events stark. Es ist jedoch notwendig, noch zwei weitere Restriktionen einzuführen. Da wir mit der Einspeicherung in der Datenbank quasi die Einspeisung des Events in Esper modellieren wollen und Esper sich die Ankunftszeit eines jeden Events merkt, muss jedes Event einen Zeitstempel besitzen, welcher bei Einspeicherung in die Datenbank gesetzt wird. So können später Anfragen, die sich auf die Ankunftszeit beziehen, leicht abgehandelt werden. Des weiteren fordern wir einen eindeutigen, nach der Ankunftszeit fortlaufenden Schlüssel, also einen Primary Key. Aufgrund der schnellen Verarbeitungszeiten ist dieser notwendig, da Events teils so schnell abgespeichert werden, dass sie denselben Zeitstempel besitzen und dieser somit nicht als Primary Key dienen kann. Im folgenden wird nun der Trigger beschrieben, dass Schlüsselelement des Systems. 4.2 Trigger Der Trigger ist der Hauptbestandteil unseres Konzepts. Er verwaltet eintreffende Events aus der ersten Esper-Instanz, führt die entsprechenden Datenbankanfragen durch und leitet dann die abgefragten Events and die zweite Esper-Instanz weiter Grundprinzip Der Listener, der aktiv wird, wenn in der ersten Esper-Instanz ein hereinkommendes Event detektiert wurde, leitet dieses Event komplett an den Trigger weiter, daraufhin wird dieser aktiv. Es wird überprüft, ob die zweite Instanz EPL-Statements hält, für welche das hereinkommende Event relevant wäre. Ist dies der Fall, startet das umschreiben der EPL-Statements. Hierbei machen wir uns die Ähnlichkeit der Esper-EPL zu SQL zunutze und manipulieren die Statements so, dass das Ergebnis eine äquivalente SQL-Anfrage darstellt. Soll z.b. bei Auftreten eines Events A das letzte Event B detektiert werden und B ausgegeben werden, so wäre der zugehörige EPL-Ausdruck: s e l e c t b from B. s t d : l a s t e v e n t ( ) as b, A. s t d : l a s t e v e n t ( ) as a where b. b e f o r e ( a ) Die äquivalente MySQL-Anfrage wäre nun (wenn der Timestamp von A : 45 : 23 ist): s e l e c t b from B b where b. timestamp < : 4 5 : 2 3 order by b. i d desc l i m i t 1 Befehle der Esper-Intervallalgebra wie b.be f ore(a) sind in unserem Falle redundant, da wir fordern, dass jedes Event ein Timestamp- Feld besitzt. Kennt man die Eintrittszeit der Events können alle Befehle der Intervallalgebra leicht nachgebildet werden. So kann hier z.b. where b.be f ore(a) durch where b.timestamp < a.timestamp ersetzt werden. Im Folgenden soll darauf eingegangen werden, wie wir mit den einzelnen Komponenten des Ausdrucks umgehen, um ihn in eine äquivalenten SQL-Ausdruck umzuwandeln. Zum einen wird auf Window Views eingegangen. Dies sind bestimmte EPL-Ausdrücke, die die Anzahl der betrachteten Events einschränken können. Zum anderen wird berichtet, wie man den bereits vorhandenen Where-Clause der Esper- EPL in eine SQL-Anfrage übernehmen kann Window Views Zu den Window Views zählen in der Esper-EPL Ausdrücke wie.std : lastevent(),.win : time() oder.win : length(). Diese lassen sich in zwei grundlegende Arten einteilen. Zum einen existieren Views, die sich auf die (Ankunfts-)Zeit von Events beziehen, zum anderen existieren Views die sich auf deren Anzahl beziehen. Es wäre zwar möglich gewesen deren Funktionalität auf SQL- Views abzubilden, jedoch ist das mit EclipseLink eine umständliche Aufgabe. Es erschien naheliegender, den Where-Clause der Anfrage zu erweitern bzw. die Anzahl der Ergebnisse einzuschränken, was jedoch zu ganz eigenen Problemen führt. So fordert z.b. die Verwendung von B.win : length(4) nicht die letzten 4 Events für die der Where-Clause gilt, sondern es schränkt den Sichtbereich prinzipiell im Vorhinein auf die Anzahl 4 ein. Die SQL-Anfrage hingegen, bei der mittels order by B.id desc limit 4 die letzten 4 Ergebnisse angezeigt werden, gibt als Ergebnis nicht die letzten 4 Events aus und überprüft dann, ob der Where-Clause gilt. Sie überprüft vielmehr zuerst den Where-Clause und schränkt dann die Anzahl der Ergebnisse auf die letzten 4 ein. Somit würden beide Varianten unterschiedliche Ergebnisse produzieren. Gelöst wird dieses Problem, indem zunächst die maximale Event-Id aus der spezifischen Datenbank abgefragt wird, um diese dann für den Where-Clause weiterzuverwenden. Da dieser zuerst überprüft wird, erhält man nun das gewollte Ergebnis. Das produziert zwar einen leichten Netzwerk-Overhead, jedoch ist dieser so gut wie vernachlässigbar, da nur die verhältnismäßig sehr kleine Id und die Anfrage danach übertragen wird. Die Handhabung von Views, die sich nicht auf die Anzahl der Events sondern auf die Zeit beziehen, in der sie ankamen, unterscheidet sich davon stark. Da wir fordern, dass jedes Event einen Zeitstempel mit sich führt, kann beispielsweise bei dem View B.win : time(5 min 3 sec) der Zeitausdruck geparst werden und ein neuer Zeitstempel berechnet werden. Dieser liegt dann die geforderten 5 Minuten und 3 Sekunden vor der Ankunftszeit des auslösenden langsamen Events und kann nun mit den Zeitstempeln der in der Datenbank befindlichen Events verglichen werden Where-Clauses Nicht nur die Views sondern auch die Where-Clauses fordern hier eine Bearbeitung. So kann in einer EPL-Anweisung eine Referenz auf ein langsames Event enthalten sein, dessen Eventklasse nicht in der Datenbank abgespeichert wird. So würde die Datenbank versuchen, mit ihr unbekannten Daten zu arbeiten, was natürlich unmöglich ist. Es ist also erforderlich, die vom langsamen Event schon bekannten Werte in die Anfrage anstatt der zugehörigen Variablen einzusetzen. Das erfordert eine Erkennung der Aliase die im f rom-teil des Ausdrucks beschrieben werden. Diese ist recht einfach zu implementieren. Wie schon in Abschnitt präsentiert wird dann der Platzhalter (a.timestamp) durch den bekannten Wert ersetzt ( : 45 : 23 ). Die leicht abgeändert Anfrage von dort sei hier nochmal aufgeführt: s e l e c t b from B. s t d : l a s t e v e n t ( ) as b, A. s t d : l a s t e v e n t ( ) as a where b. timestamp < a. timestamp and a. n i e d e r s c h l a g > 5 and b. t e m p e r a t u r e < 4 Die Where-Clauses können auch, wie der eben gezeigte, nach dem Einsetzen der bekannten Werte überflüssige Abschnitte erhalten. Beispielsweise könnte unser Verfahren den Ausdruck and 3 > 5 produzieren. Dieser kann augenscheinlich von keinem Event erfüllt werden, obwohl die komplette Datenbankabfrage zweifelsfrei korrekt ist. Sie produziert nur zusätzlichen Netzwerktraffic, ohne ein relevantes Resultat zu liefern. Für solche schon im Vorhinein bei der Erstellung des Ausdrucks erkennbaren Fälle ist die erste Esper-Instanz als Problemlösung vorgesehen. Die Erkennung solcher Fälle muss jedoch anwenderseitig geschehen. Wird hier dieser Problemfall erkannt, kann and a.niederschlag > 5 aus dem Ausdruck gestrichen werden. Jedoch muss dann bei der ersten Instanz der ursprüngliche Erkennungsausdruck select f rom A zu s e l e c t a from A a where a. n i e d e r s c h l a g > 5 3

4 erweitert werden. Dies filtert zuverlässig irrelevante Events und spart sowohl Netzwerktraffic als auch Rechenzeit, da der Trigger mit den so herausgefilterten Events nicht mehr arbeiten muss. Im nächsten Abschnitt wollen wir nun die Effizienz der soeben beschriebenen Methoden durch Messungen belegen. 5 EVALUATION Nun werden wir in Esper unterschiedliche Bedingungen testen. Wir werden evaluieren, wie man im Durchschnitt die geringste Netzwerklast erreicht, aber auch wie die geringste Rechendauer erreicht werden kann. Zu den Tests wurde als Testmaschine, auf der Esper läuft, ein Intel Core i7-2600k bei 4,0 GHz mit 16Gb RAM verwendet. Als Datenbankserver wurde ein Intel Pentium IV Rechner bei 3,0 GHz mit 1GB RAM verwendet. 5.1 Netzwerklast Zuerst werden wir unser Konzept, also die Netzwerklast von Esper mit angeschlossener Datenbanken, betrachten. Hierbei gehen wir davon aus, dass immer nur ein Event aus der Datenbank abgefragt wird, deren Netzwerklast sinkt, wenn das langsamere Event, das nicht in die Datenbank gespeichert wird, um einiges langsamer ist als das schnelle Event, welches in der Datenbank gespeichert wird. Die Kurve nähert sich immer weiter der 0 an, wie in Abbildung 4 zu sehen ist. Die zusätzliche Netzwerklast, die durch Verwendung bestimmter Window Views entsteht ist hierbei schon berücksichtigt. Hieraus sieht man nun das mit größer werdender Differenz der Häufigkeit, Esper mit Datenbank eine geringere Netzwerklast hat. Der Schnittpunkt der Netzwerklasten von Esper mit Datenbank und Esper ohne Datenbank liegt in unserem Experiment bei einem Verhältnis von einem langsamen Event zu 3 schnellen Events. Das bedeutet, dass sich die Datenbank erst ab einem Verhältnis von ca. 1:3 lohnt, wie im nachfolgenden Abbildung 6 ersichtlich wird. Abbildung 6: Kombinierter Netzwerktraffic aus Abbildung 4 und 5 Betrachtet man nun die prozentuale Einsparung von Esper mit Datenbank gegenüber Esper ohne Datenbank sieht man, dass ab einem Verhältnis von 1:3 die prozentuale Einsparung logarithmisch ansteigt. Esper mit Datenbank spart bei einem Verhältnis von 1:5 die Hälfte der Netzwerklast und bei einem Verhältnis von 1:10 werden sogar 90% an Netzwerklast eingespart, wie in Abbildung 7 ersichtlich wird. Abbildung 4: Unser Ansatz: Netzwerktraffic Abbildung 7: Unser Ansatz: Einsparung von Netzwerktraffic Dabei erkennt man, dass Esper mit Datenbank bei der Netzwerklast, mit zunehmend größerem Verhältnis zwischen schnellen und langsamen Events, konstant besser wird, als Esper ohne Datenbank. Abbildung 5: Esper: Netzwerktraffic Wenn mehr als ein Event aus der Datenbank abgefragt wird, verschiebt sich die Kurve pro Event um ca. 60 B/s nach oben. Die Netzwerklast bei Esper ohne Datenbank hingegen nimmt mit größer werdendem Unterschied der Häufigkeit der beiden Eventströme konstant zu. Was in Abbildung 5 illustriert wird. 5.2 Berechnungsdauer Die Berechnungsdauer von Esper ist kürzer wenn keine Datenbank verwendet wird, da keine zusätzliche Zeit für Datenbankabfragen benötigt wird. Hierzu haben wir Tests durch geführt und die Berechnungsdauer für eine Anzahl von 1-50 Anfragen gemessen. Diese liegen bei Esper ohne Datenbank auf unserem System im Schnitt bei etwa 2,3ms pro Anfrage, wie aus Abbildung 10 ersichtlich wird. Die hier zu sehenden Ausreißer können im Zuge der Messtoleranz und geringen Störungen vernachlässigt werden. Vergleicht man diese Messungen mit den Ergebnissen der Messung auf unserem System bei Esper mit Datenbank, sieht man sofort, dass die Variante mit Datenbank immer eine längere Berechnungszeit besitzt, was auf die zusätzliche Zeit für die Abfrage der Datenbank zurückzuführen ist. Aber im 4

5 Abbildung 8: Rechendauer von Esper Abbildung 10: Verhältnis von abgefragten Events zur Rechendauer bei einer lokalen Event-Datenbank Gegensatz zu Esper ohne Datenbank nimmt die Bearbeitungszeit bei Esper mit Datenbank, bei einer höheren Anzahl von Eventanfragen, konstant zu, wie in Abbildung 9 gut zu sehen ist. Abbildung 9: Verhältnis von abgefragten Events zur Rechendauer bei einer entfernten Event-Datenbank Obiges Diagramm zeigt nun die Ergebnisse eines Tests, in dem Esper die Events über ein Netzwerk auf einem externen Server abfragt. Da dies einiges länger dauert als ohne Datenbank, werden wir nun auch noch einen Testfall betrachten, in dem wir die Datenbank mit der Engine auf dem gleichen Rechner haben. Auch hier bekommen wir eine konstant ansteigende Kurve, genau wie beim vorigen Test mit der Datenbank, wie in Abbildung 10 deutlich zu sehen ist. Bei der lokalen Datenbank ist die Kurve flacher als bei der entfernten Datenbank, was daran liegt das die Events bei der lokalen Datenbank eine geringere Übertragungsdauer haben als die Events einer entfernten Datenbank. Eine lokale Datenbank ist die schlechteste der möglichen Lösungen, da hier natürlich keinerlei Netzwerklast durch die Datenbank gespart werden kann. Somit würde nur die Berechnungsdauer erhöht ohne weiteren Nutzen und eine Variante ohne Datenbank wäre effizienter. Deswegen sollte man die Datenbank natürlich direkt beim Sender installieren. Damit wird keine weitere Netzwerklast benötigt, um die Events in die Datenbank zu speichern. 5.3 Wertung Wenn man nun die drei Methoden vergleicht, erkennt man leicht, dass die Variante ohne Datenbank in Hinsicht auf die Rechenzeit natürlich am Effizientesten ist, wie in Abbildung 11 zu sehen ist. Ab einem bestimmten Verhältnis, in unserem Testfall ca. 1 : 3, verursacht dies mehr Netzwerklast, was es ja zu verhindern gilt. Natürlich ist Esper mit einer Datenbank langsamer, aber auch effizienter in Hinsicht auf die Netzwerklast. Deswegen ist Esper mit Datenbank bestens Abbildung 11: Verhältnis von abgefragten Events zur Rechendauer Sterne: Unser Ansatz, entfernte Datenbank Striche: Unser Ansatz, lokale Datenbank Rauten: Esper ohne Datenbankeinsatz dazu geeignet, Netzwerklast zu sparen, wenn das Verhältnis von langsamen zu schnellen Events über ca. 1 : 3 liegt. 6 RELATED WORK Die Wichtigkeit von Complex Event Processing Systemen nimmt ständig zu, somit sind diese auch ein wichtiger Forschungsgegenstand. Insbesondere nimmt hier die Bedeutung von verteilten Systemen zu, sei es zur Überwachung von Finanzmärkten oder zur schnellen Verarbeitung von Sensordaten. So wird in [5] auf CEP in Unternehmenssystemen eingegangen. Werden Events von vielen verschiedenen Quellen bezogen, kann es möglich sein, Erkennungspläne festzulegen, die die Performance des CEP-Systems erhöhen, auch bezüglich der Netzwerkauslastung. Diese können sich stark von naiven komplexen Events unterscheiden [1]. Um solche Erkennungspläne zu erstellen, können beispielsweise deterministische endliche Automaten als Hilfsmittel herangezogen werden. Ein ähnliches Ziel wird auch in [7] verfolgt, jedoch wird hier nicht die Verringerung der Netzwerklast als eines der Hauptziele angestrebt. Vielmehr wird darauf eingegangen, möglichst viele Beschreibungen komplexer Events gleichzeitig verarbeiten zu können. Bei beiden vorangegangen Ansätzen werden zwar, ebenso wie bei unserem, CEP-Queries umgeschrieben, nur wird keine Klassifikation der unterschiedlichen Events vorgenommen, wie es bei uns der Fall ist. Ein weiterer Unterschied ist, dass in dieser Arbeit der Prozess des Umschreibens einem anderen Zweck dient. Wir schreiben um, um eine SQL-Query zu erhalten, mit der man die Events aus der Datenbank auslesen kann. In den beiden Arbeiten werden die EPL-Queries 5

6 in äquivalente EPL-Queries umgeschrieben, um eine bessere Performance zu erzielen. Die Wichtigkeit der Platzierung von Operatoren wie unserer Datenbank in Netzwerken wird in [6] untersucht. Es wird eine Erweiterung für eine Netzwerkschicht präsentiert, die die Platzierung der Operatoren eigenständig regeln kann. Wichtig für diese Arbeit ist jedoch nur die Methodik, nach der dies geschieht. Mit der Übertragung von Dateien im Allgemeinen (in unserem Fall sind dies natürlich Events) beschäftigt sich [3]. Hierbei wird nicht nur auf das titelgebende Publish/Subscribe eingegangen, welches einen wichtigen Mechanismus für CEP-Systeme darstellt, sondern auch auf Techniken wie Remote Procedure Calls oder Message Queuing. Nichtsdestotrotz waren bei unserem Ansatz andere Kommunikationswege vonnöten, um das angestrebte Ziel zu erreichen. Relevant für diese Arbeit waren natürlich auch die Dokumentationen der verwendeten Software bzw. Bibliotheken. In [2] wird eine komplette Beschreibung der Funktionsweise von Esper und der Esper- EPL vorgenommen. Auch wird eine Einführung in Complex Event Processing präsentiert. Die Beschreibung von EclipseLink und der Technik der Abspeicherung von Objekten in Datenbanken wird in [4] getätigt. [1] M. Akdere, U. Çetintemel, and N. Tatbul. Plan-based complex event detection across distributed sources. Proc. VLDB Endow., 1(1):66 77, Aug [2] EsperTech. Esper Reference Documentation Version reference/en/pdf/esper_reference.pdf, [Online; accessed 15-April-2012]. [3] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec. The many faces of publish/subscribe. ACM Comput. Surv., 35(2): , June [4] E. Foundation. EclipseLink Documentation. eclipse.org/eclipselink/documentation_center, [Online; accessed 15-April-2012]. [5] D. C. Luckham. The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, [6] P. Pietzuch, J. Ledlie, J. Shneidman, M. Roussopoulos, M. Welsh, and M. Seltzer. Network-aware operator placement for stream-processing systems. In Data Engineering, ICDE 06. Proceedings of the 22nd International Conference on, page 49, april [7] N. P. Schultz-Møller, M. Migliavacca, and P. Pietzuch. Distributed complex event processing with query rewriting. In Proceedings of the Third ACM International Conference on Distributed Event-Based Systems, DEBS 09, pages 4:1 4:12, New York, NY, USA, ACM. 7 ZUSAMMENFASSUNG Um die Netzwerklast zu reduzieren führen wie eine Datenbank ein. Darin werden häufig auftretende Events abgespeichert und bei auftreten noch niederfrequente Events abgerufen. Dieses System kann mit zwei Esper-Instanzen erstellt werden. Hierzu entnimmt die erste Esper-Instanz ein niederfrequentes Event und leitet diese an die zweite Instanz weiter, wenn die Bedingungen für ein komplexes Event erfüllt sind. Anschließend werden die letzten hochfrequenten Events ebenfalls aus der Datenbank an die zweite Esper-Instanz weitergeleitet. Diese Methode ist bei einem Verhältnis von niederfrequenten zu hochfrequenten Events von 1 : 3 in der Netzwerklast besser als bei Esper ohne Datenbank. Dabei hat Esper mit Datenbank zwar eine längere Rechenzeit, spart jedoch signifikant viel Netzwerklast ein. Man kann noch weitere wenige Verbesserungen einführen, um Esper mit Datenbank noch effizienter zu machen. Zum Beispiel könnte man einen Eventpuffer bzw. einen Eventcache hinzufügen, damit die Events, die bereits abgefragt wurden, nicht noch ein weiteres mal abgefragt werden. Man könnte auch die gesamten Informationen aus der Datenbank auf mehrere Datenbanken verteilen oder mehrere Datenbanken unterstützen, dass jeder Event-Sender eine eigene Datenbank besitzt. Damit würde sich sowohl die Zugriffszeit als auch der Netwerktraffic noch weiter verringern. ACKNOWLEDGMENTS Zuletzt möchten wir uns noch bei unseren Betreuern, Björn Schilling und Beate Ottenwälder für die stetige Beratung und ihre schier endlos erscheinende Geduld bedanken. LITERATUR 6