Wir bewegen uns in einer extrem vernetzten, digitalisierten Welt. Es gibt praktisch keinen Lebensbereich mehr, der nicht an das Netz angedockt hätte. Ob Industrie und Handel, Arbeitswelt oder Privatleben: Wir alle sind ins Netz gegangen. Mit jeder Aktion, die wir dort ausführen, hinterlassen wir Daten. Und das massenweise: Verbindungsdaten, Gerätedaten, persönlich Daten; Textdateien, Bilddateien, Audiodateien – ein riesiges Datenvolumen. Mehr noch: Neben dem reinen Umfang steigt auch die Anzahl der Verknüpfungen zwischen den Daten selbst sowie die Anzahl verschiedener Datentypen.
Relationale Datenbanken (RDBMS) stoßen vor diesem Hintergrund zunehmend an ihre Grenzen, da sie Daten getrennt nach Datentyp speichern, sprich: in Tabellen. Damit sind sie statisch und konzeptionell nicht für verknüpfte Daten ausgelegt. Die Folge: Mit der steigenden Anzahl von Verbindungen steigt auch die Anzahl der Tabellen, die betrachtet werden müssen. Ein Umstand, der sie angesichts immer dynamischer werdender Daten unübersichtlich, schwer wartbar und langsam macht.
Eine weitere Problematik ist das limitierte Datenmodell: eine Ableitung von Datentypen ist in den meisten RDBMS nicht vorgesehen. Kommen neue Anforderungen hinzu, müssen oft neue Tabellen hinzugefügt werden, die dann wiederum mit bestehenden Tabellen zu verknüpfen sind. Dies löst man zwar, indem man entweder für jeden Datentyp eine neue Tabelle anlegt (Normalisierung), oder die bestehende Datentabelle bis zum Abwinken mit Feldern der abgeleiteten Typen vollstopft. Beides sorgt auch für eine Entlastung des Datenbanksystems, ist aber für den Datenanalysten gleichermaßen ein Graus, da für ihn bald nicht mehr klar ist, welche Felder zu welcher Ableitung gehören bzw. wie er Daten über mehrere Tabellen hinweg aggregieren kann oder warum Tabellen genau in einer bestimmten Konstellation zusammenhängen, also was der Hintergrund für die Verbindung einer Tabelle mit einer anderen ist.
Not only SQL
Die NoSQL-Bewegung („Not only SQL“) war deshalb ein notwendiger Schritt, aus dem Tabellenschema klassischer Datenbanken auszubrechen. Dafür wurden und werden verschiedene Ansätze ausprobiert: vom Key Value Store über die Verbesserung von RDBMS-Systemen* bis hin zu Graphdatenbanken, um die es in diesem Text gehen soll.
*anhand der Stellschrauben Konsistenz (C), Verfügbarkeit/Lastverteilung (A) und Performance (P)
*durch Atomisierung, Auslagerung und dgl.
Graphdatenbanken
Seit mittlerweile 15 Jahren sind sie für den digitalen Erfolg zahlreicher Unternehmen verantwortlich – nicht nur, weil sie Datenzusammenhänge sichtbar machen, sondern auch, weil sie ein schnelles Handeln ermöglichen. Im Gegensatz zu relationalen DB können sie Daten nämlich als Graphen persistieren und sind so in der Lage, diese als Beziehungsgeflecht abzubilden und zu bewerten. Das bedeutet nicht nur, dass deren Komplexität erhalten bleibt, sondern auch, dass diese DB Datenbankabfragen viel schneller bedienen können – ganz ohne Join Operation, ohne Map/Reduce-Algorithmus. Das wohl sinnfälligste Beispiel für den Nutzen einer solchen Funktionsweise ist Google, deren Pagerank auf Graphentechnologie beruht.
Anwendungsbereiche
Identity & Access Management (IAM): Die Vielschichtigkeit von IT-Landschaften nimmt mit Größe, Verzweigung und Diversifizierung von Unternehmen deutlich zu. Die Sprunghaftigkeit der Märkte und die Digitalisierung sorgen ihrerseits dafür, dass die Dynamik auch innerhalb der Unternehmen wächst: Innovationsdruck, neue Geschäftsbereiche, Umstrukturierungen, Flexibilisierung, mobiles Arbeiten. Systeme müssen häufiger zu- und abgeschaltet, Rollen und Rechte angepasst, neue Stakeholder oder Anlagen sowie externe Örtlichkeiten wie Home Office etc. zugelassen werden. Ein Szenario, in dem klassische Directory Services oft nicht mit der gebotenen Effizienz mitskalieren können.
Anders Graphdatenbanken. Denn sie helfen, komplexe und dicht verwobene Strukturen mit allen Personen, Rollen und Ressourcen als Geflecht im Überblick zu behalten, Änderungen in der Organisation an einer Stelle zentral vorzunehmen und dann automatisiert über die betroffenen Netzwerke auszurollen, beliebig viele neue Directories ohne Performanceverluste aufzuschalten. Das macht sie zu hervorragenden Partnern angesichts immer agiler werdender Anforderungen.
- Metadatenmodell: Vogelperspektive auf alle Zusammenhänge und Abhängigkeiten
- Rollen und Rechte: Schnellere Anpassung an volatile Arbeitsstrukturen
- Eine für alle: Mitarbeiter, Lieferanten, Partner, Kunden und Dienstleister – alle unter einem Dach
Betrugserkennung: Um die Reichweite von Betrugsversuchen und Cyberkriminalität insgesamt zu mindern, ist es entscheidend, kompromittierte Daten so schnell wie möglich zu erkennen. Früher fokussierte man die Suche nach Manipulationsversuchen auf einzelne Datensätze wie Nutzer, Accounts, Geräte oder IP-Adressen. Heute, wo die Angriffe smarter werden, muss die Detektivarbeit es ebenfalls: So haben wir es etwa im Bereich Finanzen oder E-Commerce zunehmend mit Third Party Frauds zu tun, sprich mit einem Angreifer oder ganzen Angreiferring, der sich gestohlener, künstlicher oder synthetischer Identitäten bzw. ferngesteuerter Rechner bedient. Mit Graphdatenbanken lassen sich solche Machenschaften viel leichter feststellen – mit fast keinem zeitlichen Versatz zum tatsächlichen Geschehen. Das ist ausgesprochen hilfreich im Kampf gegen Geldwäsche, Steuerhinterziehung, Kreditkartenbetrug. Das weltweit bekannteste Beispiel für einen solchen Verwendungszweck ist der Betrugsfall „Panama Papers“, der 2016 mit Hilfe der Graphtechnologie aufgedeckt werden konnte.
Außerdem helfen Graphdatenbanken der IT-Sicherheit in Sachen Prävetion und Abwehr: Welche Angriffsszenarien gibt es? Wie entwickeln sie sich weiter? Welche Sicherheitslücken nutzen sie aus? Und welche Gegenmaßnahmen sind zu ergreifen?
Routenplanung: Der Aufbau von Graphdatenbanken macht sie zum idealen Werkzeug für jede Art von Netzwerkplanung. In der Logistik wird das an den Anforderungen einer intelligenten Netzwerkplanung besonders deutlich: Um die beste Kombination zu finden, sind in der Transportlogistik viele verschiedene Parameter zu bedenken: Frachtgut, Entfernung, Verkehrsmittel, Verkehrswege, Verkehrslage, Transportzeiten, Ladezeiten, Be- und Entladungspunkte, Knotenpunkte, Flottenverfügbahrkeit und dergleichen mehr. Für Graphdatenbanken ist es kein Problem, der Optimierung und Simulation alle Variablen und Konstanten der Routenplanung, mitsamt kausalen Zusammenhängen und schnell wechselnden Abhängigkeiten, zur Verfügung zu stellen. Selbstverständlich können diese Daten später auch zum Dispatching herangezogen werden.
Netzwerke & IT Operations: IT-Landschaften sind sehr heterogen: Hardware, Software, Server, Schnittstellen, Router, Browser, virtuelle und analoge Komponenten – ein vielschichtiges IT-Gelände. So ist es leicht vorstellbar, welche Arbeit Systemadministratoren darauf verwenden, diese Landschaften zu betreuen und immer auf dem neuesten Stand zu halten. Ebenfalls leicht vorstellbar, wie hilfreich ihnen Graphen dabei sein können, weil sie diese Landschaften als vielschichtiges Datenmodell abbilden und es der Administration so erleichtern können, alle Abhängigkeiten im Blick zu behalten, z. B. bei der Ursachen- und Fehleranalyse. Auch und vor allem vor dem Hintergrund, dass diese Landschaften einem permanenten Wandel unterworfen sind.
Marketing & Sales: Insbesondere im Onlinehandel sind Graphdatenbanken heute unerlässlich. Sie werden hier für ein zielorientiertes und bedarfsgerechtes Empfehlungsmanagement genutzt. Etwa in Form einer Recommendation Engine: „Kunden, die dieses Produkt gekauft haben, interessieren sich auch für …“. Früher mussten Kauftipps noch via Batch Jobs (Stapelverarbeitung) über Nacht vorbereitet und angestoßen werden. Heute ist neben der Individualisierung von Angeboten Echtzeit ein maßgebliches Kriterium, um am Markt erfolgreich zu sein.
Drei Graphdatenbanken im Vergleich
- Neo4j: ist die bekannteste aller Graphdatenbanken. Ihr wichtigster Benefit ist ihre mächtige Cypher Query Language zur Abfrage selbst komplexester Datenzusammenhänge mit guter Performance.
- OrientDB: ist keine reine Graphdatenbank, sondern vielmehr eine Multimodelldatenbank mit Graphfunktionen, die sich insbesondere zur Archivierung und Abfrage von Dokumenten anbietet, weil man sie auch als reinen Document- oder Key-Value-Store anwenden kann. Sowohl Neo4j als auch OrientDB können embedded, als Stand- alone-Lösung oder verteilt eingesetzt werden.
- JanusGraph: ist sehr stark auf Verteilung und große Datenmengen ausgelegt und besitzt verschiedene Storage Backends, ist also eine Art Graphaufsatz auf bestehende Datenbanken und Technologien. Schon ein kleines Beispiel-Setup bringt die Datenbank Cassandra als Storage und Elasticsearch für Indizierungen mit und macht JanusGraph damit für eine Stand-alone- oder clientseitige Verwendung definitiv zu umfangreich.
(jw, su)
