Investitionsschutz: ein wichtiger Vorteil von RDF und SPARQL

Ein aktuelles Kundenprojekt hat mir wieder zwei  wichtige Vorteile der W3C-Standards um semantische Technologien und Graphdaten vor Augen geführt: 

• Stabilität, im Sinne von Übertragbarkeit der Daten und Abfragen
• Auswahl an Produkten, zwischen denen ich meine Daten und Abfragen austauschen kann
• Und damit einen Investitionsschutz, den proprietäre Graphdatenbanken nicht bieten

tl;dr

Warum RDF? Weil es Ihre Investitionen schützt! 

Im Beispiel: Datenmigration in ein neues Produkt nach 6 Jahren, Aufwand: 1 Tag. Migration bestehender Abfragen: vermutlich weniger als 4% Änderungen. Das Datenmodell bleibt, die APIs und Abfragen für Kunden bleiben. Dabei konnte der Kunde zwischen drei Produkten wählen um die geänderten Anforderungen zu erfüllen.

Stabilität

Hier geht es darum, dass die Daten an sich den Wert darstellen, den RDF auch in Zukunft erhält. Es sind wahrscheinlich beträchtliche Mittel in die Strukturierung, Sammlung, Zusammenführung, Validierung und Pflege dieser Daten geflossen.

Um diesen Wert zu erhalten, ist ein stabiles Datenformat wichtig. Ich will diese Daten auch in 10 Jahren noch lesen können, sonst ist meine Investition verloren, oder fordert zumindestens erhebliche zusätzliche Mittel um die Daten in ein Format zu konvertieren, das gerade opportun oder modisch ist.

Hier hilft ein Standard wie RDF. Ja, der ändert sich langsam. Und gerade darum kann ich auch noch nach 10 Jahren mit verschiedenen Tools darauf zugreifen, damit arbeiten. Meine Investition ist geschützt.

Dazu kommt:

Viele Produkte unterstützen RDF

Es gibt inzwischen etliche Produkte um mit den Standards um RDF zu arbeiten.

Darunter fallen verschiedene Triplestores, bzw. Graphdatenbanken. Und alle bieten unterschiedliche Eigenschaften und Schwerpunkte an, die sie für verschiedene Anwendungen geeignet machen.

Ob ich nun besonders schnelle Regelverarbeitung brauche, inkrementelle Validierung von Updates auch für riesige Datenmengen, Anbindung an unstrukturierte Daten oder Volltextsuchmaschinen, Transaktionen, zeitbasierte Abfragen, ortsbasierte Abfragen, Hochverfügbarkeit oder Anbindung an die gerade bevorzugte Programmiersprache: für fast alles gibt es ein Angebot, dass die Anforderungen abdeckt.

Und ihre Daten bleiben trotzdem in einem standardisierten Format, dass sie vielleicht in 5 Jahren in einer anderen Applikation oder Datenbank weiterverarbeiten können.

Außerdem gibt es eine reichhaltige Auswahl an Werkzeugen und Verfahren um mit diesen Daten zu arbeiten, von Benutzeroberflächen, verschiedenen Inferenzsytemen, Visualisierungsbibliotheken, SQL-to-RDF-Adapter, es ist vieles vorhanden. Dabei reicht die Spanne von Open-Source über Freeware bis zu hochpreisigen enterprise-level Produkten.

Außerdem gibt es Trainingsmaterial, Beispiele, Code und geschäftliche und wissenschaftliche Artikel in Massen, und für viele Probleme gibt es eine bereits formulierte Lösung. Jeder, der sich in das Feld einarbeiten will findet mehr als ausreichend Schulungsmaterialien, sowohl um Mitarbeiter zu schulen, als auch für ein Selbststudium.

Wenn ich das etwa mit Neo4J vergleiche: ein Anbieter, eine Abfragesprache, eine Datenbankimplementation, eine begrenzte Auswahl an Tools. Das mag anfangs als Vorteil erscheinen: keine Wahl heißt auch kein Lern- und Entscheidungsprozess, nachdem einmal Neo4J gesetzt ist. Es heißt aber halt auch "keine Wahl", wenn nach längerer Laufzeit neue Fähigkeiten gefragt sind. Es heißt auch Transformation der Daten, wenn die neuen Fähigkeiten eine neue Datenbank erfordern.

Ein Beispiel

Bei meinem jetzigen Kunden wird für einen Datenbestand von 600 Millionen Tripeln, der auf 900 Millionen wachsen soll, ein neuer Triplestore gesucht. 

In der aktuellen Anwendung laufen bei jedem Update der Daten mehr als 600 Abfragen, um die Daten zu validieren.

Um die Alternativen zu testen, habe ich die 600 Millionen Triple aus der existierenden Datenbank in eine standardisiertes Format exportiert (NQuads), sie mit einem existierenden Tool in ein anderes standardisiertes Format transformiert (TriG) und in drei verschiedene Triplestores importiert.

Das lief ganz ohne Probleme ab. Aufwand für die Datenmigration in drei verschiedenen Produkte: ein Tag.

Dann habe ich die existierenden 600 Validierungsabfragen - unverändert - an alle drei Alternativprodukte geschickt, und von den 600 Validierungen sind alle akzeptiert und verarbeitet worden, und nur für 20-25 Validierungen von 600 haben die verschiedenen Stores Fehler in den - validen - Daten behauptet.

Das ist ein mehr als gutes Ergebnis, 96,x% der Abfragen laufen mit den neuen Stores ganz ohne Änderungen.

Damit bleiben die Investitionen erhalten, der Aufwand um diese 20+ Abfragen anzupassen ist sehr überschaubar, einen Aufwand um die Daten zu konvertieren gab es im Grunde nicht.

Zusammenfassung

Mein Kunde kann durch seine Entscheidung für W3C-Standards vor 6 Jahren heute:

• ohne Kosten für eine Datenmigration
• mit minimalen Kosten für die Anpassung bestehender Abfragen (<5% Änderungen)
• die Performance der bestehenden Lösung um eine Größenordnung steigern
• die Robustheit und Resilienz durch Wechsel auf eine HA-Konfiguration steigern
• die bestehende Architektur vereinfachen
• den Umfang selbstgeschriebener Services deutlich verringern

Seine Kosten sind dabei auf die Einmalkosten für die tatsächlichen Verbesserungen beschränkt: die Abfragen werden in Constraints gewandelt, die Architektur wird vereinfacht um mit einer geringeren Anzahl selbstgeschriebenen Services zu arbeiten.