Persistenz und Verarbeitung von energiewirtschaftlichen Daten unter Einsatz von Elasticsearch

Donnerstag, 1. März 2018 01.03.2018 von Michael Kühn 0 Kommentar

Im Marktregulierungsprozess wird ein Großteil der Nachrichten zwischen den Markteilnehmern im Nachrichtenformat EDIFACT ausgetauscht. Ein Merkmal dieses Nachrichtenformates ist, dass dieses jedes Jahr zum April und Oktober überarbeitet wird und somit auf die weitere Verarbeitung in den verwendeten IT-Systemen, je nachdem welche Informationen benötigt werden, Auswirkungen haben könnte. Ein weiteres Merkmal ist, dass diese Nachrichten viele Informationen beinhalten können und in großer Anzahl vorkommen und somit je nach benötigten Informationen und je nach eingesetzter Technologie die Speicherung aufwändiger werden kann. Stand heute werden energiewirtschaftliche Daten fast ausschließlich in relationalen Datenbanken gespeichert. Dies trifft auch auf die EDIFACT Nachrichten zu, die zur Marktkommunikation verwendet werden. 

Relationale Datenbanken haben die Eigenschaft, dass zur Speicherung von Daten ein zuvor erarbeitetes Datenmodell in Form einer Tabellenstruktur angelegt werden muss, die sich im Nachhinein nicht ohne Weiteres ändern lässt. Der Nachteil von relationalen Datenbanken in Bezug auf die EDIFACT Speicherung ist, dass durch die regelmäßigen Änderungen der Nachrichtenstruktur und je nachdem wie vollständig eine EDIFACT Nachricht gespeichert werden soll, das Datenmodell ggf. ebenfalls überarbeitet werden muss. 

Im Rahmen meiner Masterarbeit habe ich mich mit der alternativen Speicherung dieser Nachrichten befasst. Dabei habe ich die verschiedenen NoSQL-Datenbanktechnologien evaluiert und der relationalen Datenbanktechnologie gegenübergestellt. Das Ziel war es, eine möglichst gute Technologie in Bezug auf Geschwindigkeit, Skalierbarkeit und Robustheit gegen mögliche Strukturänderungen der Eingangsdaten zu finden. 

Die Entscheidung für diese Arbeit fiel auf den dokumentenbasierenden Such-Server Elasticsearch, der neben seiner auf Apache Lucene basierenden Such-Engine auch einen Dokumentenspeicher besitzt. Ein Dokumentenspeicher hat den Vorteil, dass die zu speichernden Dokumente eine unterschiedliche Struktur haben können und somit nahezu als schemafrei gelten. Ein weiterer Vorteil bei Elasticsearch ist, dass die einzelnen Felder der hinzugefügten Dokumente automatisch mithilfe eines invertierten Index indiziert werden. Ein invertierter Index beinhaltet, ähnlich wie bei einem Stichwortverzeichnis eines Buches, den jeweiligen Suchbegriff mit einer Referenz auf das jeweilige Dokument, in dem dieser Begriff vorkommt. Dadurch ist eine Suche nach allen Informationen eines Dokumentes effizient möglich. Das Ergebnis ist dann das jeweilige vollständige Dokument. 

Elasticsearch ist so aufgebaut, dass alle Interaktionen mit der Datenbank über eine REST-Schnittstelle möglich sind. Daher können Dokumente mithilfe von JSON-Konstrukten gespeichert und abgefragt werden. Neben dieser REST-Schnittstelle bietet Elasticsearch zusätzlich die Möglichkeit, über eine Java API mit der Datenbank zu kommunizieren.

Das Projekt ist in Form einer 3-Tier-Architektur aufgebaut. Eine Webseite stellt die grafische Benutzeroberfläche für die Suche nach EDIFACT Nachrichten dar. Die eigentliche Verarbeitung – also das Lesen und Schreiben der EDIFACT Nachrichten – passiert im Application Server. Die Persistenz der Daten geschieht wahlweise in einer relationalen Oracle Datenbank oder in Elasticsearch. Der Application Server stellt REST Webservices für die Kommunikation mit dem Client bereit. (Grafik über die Architektur) 

Im Anwendungsfall Elasticsearch werden die EDIFACT Nachrichten beim Eintreffen im Application Server aufbereitet und in Form von Dokumenten an Elasticsearch übergeben, die wiederum die einzelnen Felder des Dokumentes indiziert und persistiert. Zur Suche können über die GUI Suchmaske verschiedene Suchparameter gesetzt werden, die in Form einer Parameterliste im JSON Format mittels Webservice an den Application Server übermittelt, der wiederum daraus eine Elasticsearch Abfrage aufbaut und diese an Elasticsearch übergibt. Das Ergebnis dieser Abfrage wird daraufhin zurück an den Client durchgereicht. 

Bezüglich der Speicherung der Daten lässt sich Folgendes festhalten: In der relationalen Datenbank existieren mehrere Tabellen, die die verschiedenen Teile der Nachrichten in unterschiedlichen Spalten speichern, um so die Suche nach diesen Attributen überhaupt zu ermöglichen. Für jedes neue oder entfallende Attribut müssen die Datenbankstrukturen angepasst und eine Datenmigration in relationaler Datenbank durchgeführt werden. Bei Elasticsearch haben neue oder entfallende Attribute durch die Eigenschaft der Schemafreiheit von dokumentenorientierten Datenbanken keine Auswirkungen auf die Datenbank.

Der benötigte Festplattenspeicher zur Speicherung der EDIFACT Nachrichten samt dazugehöriger Informationen war bei der relationalen Datenbank ca. 10x so groß wie für Elasticsearch. Auch der Vergleich der Suchzeiten ergab große Unterschiede zwischen den beiden Datenbanksystemen und variierte bei der relationalen Datenbank stark je nach Anzahl der Einträge. Beispielsweise betrug die durchschnittliche Suchzeit einer Suche nach einer EDIFACT-Nachricht mit allen gesetzten Suchparametern bei der relationalen Datenbank ca. 4,5 Minuten. Dabei wurde unter anderem eine Tabelle mit Lastgang-Zeitstempeln mit 200 Millionen Einträgen mit einbezogen. Eine Suchanfrage ohne Berücksichtigung der Lastgang-Zeitstempel dauerte wiederum nur wenige Sekunden. Bei Elasticsearch blieben die Suchzeiten bei der Suche nach denselben Parametern sowohl mit wie auch ohne die Lastgang-Zeitstempel konstant unter einer Sekunde. (Grafik der Messzeiten)

Aufgrund der gesammelten Erkenntnisse bezüglich der Suchzeiten und den Auswirkungen von Änderungen kann ich Elasticsearch, in Bezug auf die Speicherung von EDIFACT Nachrichten, auf jeden Fall für diesen Anwendungsfall empfehlen. Ein weiteres positives Merkmal von Elasticsearch ist, dass dieser Such-Server für die horizontale Skalierung ausgelegt ist. Sprich, dass bei steigender Datenmenge und Engpässen weitere Elasticsearch Instanzen zu einem Cluster zusammengeschlossen werden können und somit die Such- und Speicherlast auf mehrere Geräte verteilt werden kann. Dabei sind dann natürlich die Risiken, die verteilte Systeme mit sich bringen, wie z. B. die nicht zu jeder Zeit zu gewährleistende Konsistenzfreiheit, abzuwägen. 

Generell ist es von Vorteil, bei der Auswahl einer Speichertechnologie über den Tellerrand zu schauen und statt naiv die bewährte relationale Datenbank zu wählen, je nach Einsatzzweck auch die NoSQL Datenbanken, wie in diesem Fall Elasticsearch, in Betracht zu ziehen. Natürlich werden für viele Einsatzzwecke, wie z. B. die Verwaltung von Stammdaten, bei denen mehr Wert auf die redundanzfreie Verwaltung gelegt wird, die relationalen Datenbanken weiterhin die erste Wahl bleiben. Jedoch bieten sich beispielsweise für Daten, die hochfrequentiert und schnell gespeichert bzw. ausgelesen werden sollen, andere Datenbanktechnologien, die weniger Wert auf Redundanzfreiheit legen, besser an. 

Zum Beispiel lassen sich Log-Daten, die in kurzer Zeit und in hoher Anzahl eintreffen können, gut in Key-Value Datenbanken bzw. dokumentenorientierten Datenbanken speichern, die die Lese- und Schreiblast leicht auf mehrere verschiedene im Cluster laufenden Maschinen aufteilen können. Die dabei kurzzeitige Nicht-Konsistenz ist dabei Nebensache, da in der Regel solche Daten erst Tage später ausgewertet werden müssen.

Neben der Verarbeitung von EDIFACT Nachrichten ist der Einsatz von Elasticsearch generell zu Analysezwecken auf großen Datenmengen geeignet, da hier komplexe Suchoperationen performant durchgeführt werden können. Im Hinterkopf sollte man natürlich die Risiken von horizontal skalierenden Systemen haben, jedoch als Zusatzsystem zur Auswertung von Informationen ist Elasticsearch auf jeden Fall zu empfehlen. Ich bin überzeugt, dass mithilfe der Erkenntnisse aus dieser Arbeit nun weitere relevante Anwendungsfälle für diese Technologie bei der SOPTIM identifiziert und geeignet umgesetzt werden können.



Kommentar schreiben

Ihr Kontakt Stephanie Lemken Was kann ich für Sie tun?
+49 241 918 790

Direkt anrufen

Verwendung von Cookies

Cookies ermöglichen eine bestmögliche Bereitstellung unserer Dienste. Mit der Nutzung der SOPTIM-Seiten erklären Sie sich damit einverstanden, dass wir Cookies verwenden.

Weitere Informationen erhalten Sie in der Datenschutzerklärung
OK, verstanden