Technische Konsequenzen großer Datenmengen

EnterpriseTales: Für alle Daten die richtige Speichertechnologie

Arne Limburg

Big Data ist in aller Munde. Durch immer günstigeren Speicherplatz und aufkommende alternative Speichertechnologien hat in den letzten zehn Jahren ein massiver Wandel im Umgang mit Daten stattgefunden. In dieser Folge der Kolumne EnterpriseTales klärt JAX-Sprecher Arne Limburg, welche Konsequenzen das für die Softwareentwicklung und die entstehende Software hat.

Technische Konsequenzen großer Datenmengen

Technologiehistoriker George Dyson sagt zu Big Data: „Big data is what happened when the cost of storing information became less than the cost of making the decision to throw it away“. Noch vor ein paar Jahren wurde extrem zwischen wichtigen und unwichtigen Daten unterschieden. Die wichtigen Daten wurden in einer (relationalen) Datenbank abgelegt, wohingegen die vermeintlich unwichtigen in Logdateien landeten – wenn sie überhaupt gesammelt wurden.

In den vergangenen Jahren haben allerdings verschiedene technologische Entwicklungen stattgefunden, die dieses Vorgehen nicht mehr optimal erscheinen lassen. Diese Entwicklungen haben in verschiedenen Bereichen parallel stattgefunden, z. B. in der Datenspeicherung. NoSQL-Datenbanken kamen auf, aber auch die Datensuche, -aggregation und -aufbereitung machten Fortschritte, z. B. das neue Programmiermodell MapReduce. Der ELK-Stack (bestehend aus Elasticsearch, Logstash und Kibana) ist ein gutes Beispiel für diese neuen Technologien. Mit ihm lassen sich unstrukturierte Daten effizient aufbereiten, durchsuchen und visualisieren.

Blockchain Whitepaper 2018

Free: Blockchain Technology Whitepaper

If building a blockchain from scratch is beyond your current scope, the blockchain technology whitepaper is worth a look. Experts from the field share their know-how, tips and tricks, development advice, and strategy for becoming a blockchain master.

Interessant wäre, ob diese neuen technologischen Möglichkeiten Ursache oder Ergebnis des neuen Umgangs mit Daten sind. Auf jeden Fall haben sie zur Folge, dass die Unterscheidung in wichtige und unwichtige Daten und vor allem darauf basierende Entscheidungen über die Speichertechnologie veraltet sind. Um bei Dyson zu bleiben: Es ist vielleicht sogar günstiger, diese Unterscheidung gar nicht vorzunehmen.

Für alle Daten die richtige Speichertechnologie

Bis zum Anfang dieses Jahrtausends war ein relationales Datenbanksystem immer die erste Wahl, wenn es darum ging, Daten konsistent und dauerhaft zu speichern. Die Frage, ob ein RDBMS für den jeweiligen Anwendungsfall geeignet war, wurde in der Regel gar nicht gestellt, auch weil es wenige Alternativen gab. Aufkommende objektorientierte Datenbanken orientierten sich zwar am verwendeten Programmiermodell – nämlich Objektorientierung –, aber nicht daran, wie die betroffenen Daten sinnvoll gespeichert und wieder geladen werden konnten. Das änderte sich erst mit dem Aufkommen von NoSQL-Datenbanken. Dabei ist zu betonen, dass NoSQL keine (einzelne) Datenbanktechnologie ist, sondern gleich ein ganzer Strauß an Datenspeichertechnologien, die lediglich gemeinsam haben, dass sie kein SQL unterstützen. In der Regel enthalten sie eine eigene nicht standardisierte Abfragesprache. Da einige dieser Abfragesprachen SQL sehr ähneln und auch Teile der SQL-Syntax enthalten, wird NoSQL mittlerweile auch häufig als Abkürzung für „Not only SQL“ bezeichnet.

Was hat man also davon, sich von einem Standard wie SQL wegzubewegen? Ganz einfach: Man hat die Möglichkeit, eine Technologie zu verwenden, die besser zu den zu speichernden Daten passt. Je nach Datenstruktur und -verteilung und nach den Anforderungen an die Abfragemöglichkeiten gibt es mittlerweile unterschiedliche Technologien. So gibt es dokumentenorientierte Datenbanken für das Speichern von unstrukturierten Dokumenten, grafenbasierte Datenbanken zum Speichern von grafenartigen Strukturen und zeitserienbasierte Datenbanken, um Daten zu speichern, bei denen der zeitliche Verlauf relevant ist.

Zusätzlich gibt es Datenbanken, die speziell der Anforderung Rechnung tragen, dass jeder Datensatz unterschiedliche Attribute haben kann und/oder dass auch ein einzelner Datensatz örtlich verteilt liegen kann – ein Teil des Datensatzes liegt auf einem Server in Amerika, ein anderer Teil liegt auf einem Server in Europa. Datenbanktechnologien in diesem Bereich sind Key-Value-Datenbanken oder spaltenbasierte Datenbanken. Wie Daten gespeichert werden, sollte also nicht mehr von der Unterscheidung wichtig oder unwichtig abhängen, sondern davon, welche Datenbank für die jeweilige Art der Daten die richtige ist. Zudem spielen auch Clustering und Datenverteilung eine Rolle. Letzteres Thema ruft einen weiteren Punkt auf den Plan.

Datenintegrität

Bei relationalen Datenbanken gelten die ACID-Eigenschaften. Diese werden durch das Konzept von Transaktionen garantiert. Durch die ACID-Eigenschaften ist sichergestellt, dass nach einem erfolgreichen Commit einer Transaktion entweder alle in ihr geschriebenen Daten gesichert sind oder gar keine. Alle in einer Transaktion durchgeführten Aktionen stellen also eine atomare Einheit dar, das A in ACID. Die weiteren Eigenschaften von ACID sind Konsistenz (Consistency), Isolation, und Dauerhaftigkeit. Nach einem erfolgreichen Commit werden also auch Datenkonsistenz, Unabhängigkeit von anderen Transaktionen und dauerhafte Sicherung der Daten garantiert.

Insbesondere, wenn das Thema verteilte Datenbanken ins Spiel kommt, wird es schwierig, die ACID-Kriterien zu garantieren. Vielmehr sagt das CAP-Theorem, dass ein System immer nur in Bezug auf zwei der drei Eigenschaften Konsistenz, Antwortzeiten und Ausfallsicherheit hin optimiert werden kann. Verteilte Systeme müssen also immer in mindestens einem der drei Punkte Abstriche machen. In der Regel wird ACID dann durch das Konzept der Eventually Consistency ersetzt. Dies bedeutet, dass das System eine Konsistenz sicherstellt, aber nicht sicherstellt, wann diese Konsistenz erreicht wird. Wenn ein Datensatz geschrieben ist, wird er asynchron auf alle Knoten verteilt. Irgendwann ist er dann überall verfügbar. In den meisten Fällen reicht diese Form der Konsistenz aus. Letztendlich geht es darum, dass dem Benutzer garantiert werden kann, dass seine Daten im System gespeichert sind. Ob es ein paar Sekunden oder Minuten dauert, bis die Daten auf allen Knoten sichtbar sind, ist meistens nicht so wichtig.

Allerdings bedeutet dieser Paradigmenwechsel auch, dass beim Entwickeln einer Anwendung diese Konsequenzen berücksichtigt werden müssen. Man muss sich z. B. die Frage stellen, ob Eventually Consistency für den jeweiligen Anwendungsfall ausreicht oder was ich in der Anwendung berücksichtigen muss, damit es ausreicht. Dabei geht es normalerweise vor allem darum, dass der Benutzer das Vertrauen in das System behält. Wenn ein Benutzer Daten ändert und sich diese Daten danach anschaut, ist es ein Problem, wenn er dann die alten unveränderten Daten zu sehen bekommt. Nur weil eventuell zum Anzeigen ein anderer Knoten verwendet wurde, auf dem die Daten noch nicht sichtbar sind. Dieses Problem könnte man aber z. B. leicht mit lokalen Caches beheben, wenn einem das Problem während der Entwicklung bewusst ist.

Auch über den Verlust der Atomarität muss sich der Entwickler beim Ändern von Datensätzen Gedanken machen. Wenn zwei Datensätze eigentlich atomar geändert werden müssten, die Datenbank aber keine Transaktionen unterstützt, muss ich eventuell ein manuelles Rollback implementieren, wenn das Speichern des einen Datensatzes zu einem Fehler führt. Häufig reicht es aber auch, sich eine geschickte Reihenfolge für das Schreiben der Datensätze zu überlegen.

Analyse

Habe ich die Daten einmal gespeichert, bleibt die Frage, wie ich die Daten verwenden möchte. Wichtig ist hierbei, um erneut auf das Zitat von Dyson zurückzukommen, dass diese Überlegungen auch im Nachgang angestellt werden können. Wenn die benötigten Daten erst einmal vorhanden sind, kann man später durch geeignete Aggregation und Visualisierung die gewünschten Ergebnisse erzielen. Allerdings gilt es hier, die Eigenheiten der verwendeten Datenbank zu berücksichtigen. Die meisten NoSQL-Datenbanken sind auf gewisse Operationen spezialisiert, die sie besonders schnell ausführen können. Andere Operationen (z. B. gewisse Joins oder Aggregationen) können dafür sehr unperformant werden. Identifiziert man eine solche Situation, ist es sinnvoll, vor der tatsächlichen Visualisierung eine Umstrukturierung und/oder Aggregation der Daten vorzunehmen, z. B. durch Indizierung über eine Suchmaschine wie Elasticsearch. Eine solche Umstrukturierung oder Aggregation kann in der Regel asynchron erfolgen und muss dann entweder nach jeder (Bulk-)Einfügeoperation oder periodisch durchgeführt werden. Durch diese Asynchronität wird weder die Performance beim Einfügen der Daten beeinträchtigt noch die Antwortzeit der Applikation, wenn es darum geht, die Daten anzuzeigen. Allerdings wird ein gewisser Zeitraum zwischen Einfügen und Anzeigen benötigt, in dem die Daten aggregiert werden. Während dieses Zeitraums werden veraltete Daten angezeigt. Auch hier muss wieder überlegt werden, ob das für die konkrete Anforderung ein Problem ist. Wenn es die Anforderung gibt, Daten in Echtzeit anzuzeigen, müssen diese in der Regel bereits so aufbereitet in die Datenbank eingefügt werden, dass sie direkt wie gewünscht visualisiert werden können.

Wichtig ist hier, dass genau zwischen diesen beiden Szenarien unterschieden wird. Im einen Fall müssten historische Daten ausgewertet werden, bei denen zum Zeitpunkt des Sammelns der Auswertungszweck noch nicht feststand. Dies führt dazu, dass sie eventuell nicht optimal für die Auswertung abgelegt sind. Hier kann eine asynchrone Aufbereitung sinnvoll und wichtig sein, um alle Aspekte schnell visualisieren zu können. Im zweiten Fall müssen aktuelle Daten zeitnah visualisiert werden. Dies kann nur gelingen, indem die Daten bereits in der richtigen Struktur für die Visualisierung in die Datenbank eingefügt werden. Im zweiten Fall ist das aber auch kein Problem, da zum Zeitpunkt des Einfügens bereits feststeht, wofür die Daten später gebraucht werden.

Fazit

Mit dem Aufkommen von NoSQL-Datenbanken wird das effiziente Speichern und Anzeigen großer Datenmengen möglich. Die neue Technologie bringt aber neue Herausforderungen für den Entwickler. Er hat die Wahl zwischen unterschiedlichen Datenbanktechnologien und muss auf Basis der Daten und der Anforderungen entscheiden, welche der verschiedenen Technologien die richtigen Eigenschaften zur Lösung des Problems aufweist. Zusätzlich kann es je nach Use Case notwendig sein, sich bereits beim Einfügen darüber Gedanken zu machen, wie die Daten angezeigt werden müssen. Das ist allerdings nur der Fall, wenn die Daten auch in Echtzeit angezeigt werden sollen. Ansonsten können zunächst große Datenmengen gespeichert werden, die dann später über asynchrone Aufbereitung zur Verfügung gestellt werden können. Dadurch, dass die ACID-Kriterien bei den meisten NoSQL-Datenbanken nicht mehr unterstützt werden, muss sich der Entwickler zusätzlich Gedanken über Atomarität, Isolation und Konsistenz machen. Falls es in diesen Bereichen höhere Anforderungen an das System gibt, als die Datenbanktechnologie leisten kann, müssen diese von Hand umgesetzt werden. In der Regel muss eine Software aber nicht ACID garantieren, sondern hat weniger starke Anforderungen an das Datenhaltungssystem, sodass NoSQL-Datenbanken häufig eine sinnvolle, günstige und performante Alternative oder Ergänzung zu relationalen Datenbanken sind.

Geschrieben von
Arne Limburg
Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: