Graphdatenbanken und -modelle gibt es seit weit mehr als einem Jahrzehnt. Sie gehören zu den einflussreichsten Technologien, die aus der NoSQL-Bewegung hervorgegangen sind.
Graphdatenmodelle sind von Grund auf darauf ausgelegt, die Beziehungen innerhalb von und zwischen Daten in den Mittelpunkt zu stellen, indem sie Daten als durch Kanten verbundene Knoten darstellen. Daher ähnelt das Graphmodell auffallend der Art und Weise, wie Menschen häufig denken und sprechen.
Das Knoten-Kante-Knoten-Muster in einem Graphen entspricht direkt dem in Sprachen wie Englisch verbreiteten Subjekt-Prädikat-Objekt-Muster. Wenn Sie also schon einmal Mindmapping-Technologie verwendet oder Ideen an einem Whiteboard visualisiert haben, haben Sie einen Graphen erstellt.
Graphdatenmodelle sind zu einem festen Bestandteil des Standardwerkzeugs für Datenwissenschaftler geworden, die künstliche Intelligenz (KI) auf alles anwenden – von der Betrugserkennung und Fertigungssteuerung bis hin zu Empfehlungssystemen und Kunden-360-Analysen.
Angesichts dieser breiten Einsatzmöglichkeiten überrascht es nicht, dass Gartner davon ausgeht, dass Graphdatenbanktechnologien eingesetzt werden in mehr als 80 % der Innovationen im Bereich Daten und Analytik, einschließlich Echtzeit-Event-Streaming, bis 2025. Doch mit zunehmender Verbreitung zeichnen sich Einschränkungen und Herausforderungen ab. Eine der bedeutendsten Einschränkungen von Graphdatenbanken ist ihre mangelnde Skalierbarkeit.
Siehe auch: Trends im Echtzeit-Datenmanagement
Volumen und Geschwindigkeit der modernen Datenerzeugung
Seit dem Aufkommen der jüngsten Generation von Graphdatenbanken vor einem Jahrzehnt hat sich vieles verändert. Unternehmen müssen mit zuvor unvorstellbaren Datenmengen umgehen, die potenziell abgefragt werden sollen. Diese Daten gelangen über verschiedenste Kanäle in das Unternehmen und durchlaufen es, und Unternehmen wollen auf diese Informationen in Echtzeit reagieren.
Die ursprünglichen Graphentwürfe konnten weder das schiere Datenvolumen von heute noch die Rechenleistung vorhersehen, die erforderlich ist, um diese Daten nutzbar zu machen. Und es ist nicht nur das Datenvolumen, das Graphdatenbanken ausbremst. Es ist auch die Geschwindigkeit dieser Daten.
Während Graphdatenbanken Berechnungen auf moderat großen Mengen ruhender Daten hervorragend durchführen können, sind sie besonders isoliert und müssen erhebliche Kompromisse eingehen, wenn Echtzeitaktionen auf Streamingdaten gewünscht sind. Beim Streaming werden Daten aktiv übertragen; sie treffen kontinuierlich aus unterschiedlichen Quellen ein.
Und Unternehmen wollen in Eventverarbeitungspipelines sofort darauf reagieren, denn wenn bestimmte Ereignisse nicht schnell erkannt werden, während sie geschehen, verschwindet die Möglichkeit zum Handeln. Beispiele sind Sicherheitsvorfälle, die Transaktionsverarbeitung (etwa Betrugs- oder Kreditprüfungen) sowie automatisierte Aktionen von Maschine zu Maschine.
Anomalien und Muster müssen mit KI- und ML-Algorithmen erkannt werden, die eine Aktion automatisieren oder zumindest eskalieren können. Diese Erkennung muss erfolgen, bevor eine automatisierte Aktion ausgeführt werden kann.
Graphdatenbanken wurden schlicht nie für dieses Szenario entwickelt. Typischerweise sind sie auf Hunderte oder Tausende Ereignisse pro Sekunde beschränkt. Unternehmen benötigen heute jedoch die Fähigkeit, Millionen von Ereignissen pro Sekunde zu verarbeiten – in einigen fortgeschrittenen Anwendungsfällen sogar zig Millionen.
Es gibt sowohl eine feste Grenze dafür, wie schnell Graphsysteme Daten verarbeiten können, als auch dafür, wie viel Komplexität sie bewältigen können (etwa wie viele Sprünge eine Abfrage umfasst). Aufgrund dieser Grenzen werden Graphsysteme häufig nicht eingesetzt. Und weil Graphsysteme nicht eingesetzt werden, bleibt Datenentwicklungsteams nichts anderes übrig, als die graphdatenbankähnliche Funktionalität in ihrer gesamten Microservices-Architektur nachzubilden.
Siehe auch: Die besten Tools für Datenanalytik
Der Aufstieg der Entwicklung kundenspezifischer Datenpipelines
Diese Umgehungslösungen, um Event-Streams in Echtzeit abzufragen, erfordern erheblichen Aufwand. Entwickler greifen typischerweise auf Event-Stream-Verarbeitungssysteme wie Flink und ksqlDB zurück. Diese ermöglichen es, die vertraute SQL-Abfragesyntax für die Abfrage von Event-Streams zu verwenden – wenn auch nicht ohne Weiteres.
Es ist nicht ungewöhnlich, dass Unternehmen Teams von Datenentwicklern monatelang oder jahrelang umfangreiche und komplexe Microservice-Architekturen entwickeln lassen, um die für Streamingdaten erforderliche Größenordnung und Geschwindigkeit zu erreichen. Diesen Systemen fehlen jedoch häufig die ausdrucksstarken Abfragestrukturen, die erforderlich sind, um komplexe Muster in Streams effizient zu finden.
Wie bereits erwähnt, mussten diese Systeme schwierige Kompromisse eingehen, um das von Unternehmen benötigte Volumen und die erforderliche Geschwindigkeit zu bewältigen – mit erheblichen Einschränkungen als Folge.
Zeitfenster können beispielsweise die Fähigkeit eines Systems einschränken, Ereignisse miteinander zu verknüpfen, die nicht innerhalb eines engen Zeitintervalls eintreffen (oft gemessen in Sekunden oder Minuten). Das bedeutet, dass ein Ereignis, das auch nur wenige Sekunden zu spät eintrifft, einfach ignoriert wird, anstatt wichtige Erkenntnisse oder geschäftlichen Mehrwert zu liefern.
Selbst mit kostspieligen Einschränkungen wie Zeitfenstern waren Event-Stream-Verarbeitungssysteme erfolgreich. Viele können sogar auf die Verarbeitung von Millionen von Ereignissen pro Sekunde skaliert werden – allerdings mit erheblichem Aufwand und Einschränkungen, die nicht die volle Leistungsfähigkeit von Graphdatenmodellen ausschöpfen.
Siehe auch: Warum die Cloud Cloud Native bedeutet
Innovationen werden die Nachfrage bedienen
Der Bedarf an Erkenntnissen aus sofort verfügbaren Eventdatenströmen und der Wert, den sie liefern, waren nie größer. Mit der zunehmenden Verbreitung sollten Unternehmen damit rechnen, dass neue Dateninfrastrukturen entstehen, die viele der Skalierungsprobleme beseitigen, welche die Leistungsfähigkeit von Graphdatenbankmodellen ausbremsen können.
Über den Autor:
Rob Malnati ist der COO von thatDot