Der Wert und Nutzen des relationalen Datenbankmanagementsystems (RDBMS) von Oracle steht außer Frage. Für einen Großteil von Unternehmensanwendungen ist Oracle zu Recht die richtige Datenbanklösung. Wahr ist allerdings auch: Big Data verlangt mehr Agilität und höhere Performance, damit auch stark vernetzte Daten, problemlos abgefragt werden können.
Ob beim Stammdatenmanagement, bei Suchabfragen oder bei Kundenanwendungen – unterschiedliche Daten aus verschiedenen Quellen müssen flexibel und in Echtzeit verwaltet werden. Oracle und andere RDBMS können dies nur bedingt leisten. Zudem verlangen Unternehmen mehr Funktionalitäten bei Anwendungen. Der Schlüssel dazu liegt in den Datenbeziehungen.
Relationale Datenbanken – Der Name täuscht
Relationale Datenbanken führen zwar das Wort “relational” im Namen, für den Umgang mit Beziehungen sind sie jedoch nicht optimal geeignet. Beziehungen lassen sich grundsätzlich mit JOINs verknüpfen. Je tiefer man allerdings geht und je mehr JOINs man benötigt, umso langsamer wird die Arbeit mit relationalen Datenbanken.
Der Begriff “relational” verweist lediglich auf die mathematische Notation einer “Relation”. Eine solche Relation besteht aus Attributen und Tupeln und wird üblicherweise als Tabelle aus Spalten (Attributwerten) und Zeilen (Tupeln) beschrieben.
In diese vordefinierten Spalten speichern relationale Datenbanken stark strukturierte Daten, wobei die Zeilen den gleichen Typ an Informationen enthalten. Wird auf dieser Basis eine Anwendung entwickelt, müssen auch diese Daten der Struktur des Tabellenformats entsprechen. Für definierte Aufgaben und für vorbestimmte Schemata ist dieser Typ Datenbank ideal. Für die Echtzeitsuche in mehrschichtigen, komplexen Daten sind sie jedoch weniger geeignet.
Graphdatenbank – Schnellere Entwicklung
Bei Graphdatenbanken stehen Datenbeziehungen hingegen an erster Stelle. So ist Neo4j eine ACID-kompatibles, transaktionale Datenbank, dessen CRUD-Operationen (Create, Read, Update und Delete) nativ in einem Graphdatenmodell arbeiten. Dieses Modell stellt Entitäten als Knoten (“nodes”) sowie deren Beziehungen (“edges”) dar und fügt sie einfach abstrahiert zu vernetzten Strukturen zusammen. Das ermöglicht den Aufbau ausgefeilter Modelle, die eine Problemdomäne genau abbilden.
Für Entwickler bringt das ein hohes Maß an Agilität und eine schnellere Bereitstellung von Anwendungen. Da es sich um eine schema-optionale Datenbank handelt, ist es nicht notwendig, komplexe Datenmodelle vorzudefinieren. Stattdessen werden das Datenmodell und die Validierung auf der Anwendungsschicht abstrahiert. Dennoch behält man die nötige Kontrolle über die Definition der eingehenden Daten.
Von Fall zu Fall entscheiden
Es gibt Szenarien, in denen es sinnvoll ist, ein RDMBS einer Graphdatenbank vorzuziehen und umgekehrt. Oracle zum Beispiel eignet sich sehr gut für tabellarische, strukturierte Daten. nstrukturierte, stark vernetzte oder dynamische Daten, wie beispielsweise Hierarchien und Netzwerke, verlagert man besser nach Neo4j. Es gibt aber noch einen Mittelweg: Bei richtig konzipierter Koexistenz beider Datenbanken verbessert sich die Anwendungsleistung, da schnelle Traversals (Suchvorgänge) anhand des Graphen mithilfe von Neo4j erfolgen können, während sich Transaktionsdaten aus Oracle auslesen lassen.
Aus dem Zusammenwirken von Neo4j und Oracle RDBMS ergeben sich mehrere Vorteile. Oracle ist eine bewährte und etablierte Technologie. Da viele Unternehmensanwendungen auf Oracle laufen, ist es einfach nicht sinnvoll, die vorhandenen Investitionen in die Infrastruktur, Tools und Trainings über Bord zu werfen. Bei der Einführung von Neo4j können alle Anwendungen weiter ohne Unterbrechung mit Oracle laufen.
Studie zu Filesharing im Unternehmen: Kollaboration im sicheren und skalierbaren Umfeld
Im Rahmen der von techconsult im Auftrag von ownCloud und IBM durchgeführten Studie wurde das Filesharing in deutschen Unternehmen ab 500 Mitarbeitern im Kontext organisatorischer, technischer und sicherheitsrelevanter Aspekte untersucht, um gegenwärtige Zustände, Bedürfnisse und Optimierungspotentiale aufzuzeigen. Jetzt herunterladen!
Neo4j kann mit Oracle auf verschiedene Weise zusammenarbeiten. Welchen Ansatz man wählt, hängt davon ab, was man erreichen will. Wenn Anwendungen bestimmte Fragestellungen aufgrund der Tiefe und Komplexität der Datenbeziehungen nicht effizient beantworten können, sollten die relevanten Daten nach Neo4j migriert werden. Neo4j ist für diesen Teil der Daten dann der transaktionale und ACID-kompatible Datenspeicher.
Es gibt auch Szenarien, in denen es Sinn macht alle Daten nach Neo4j zu migrieren. Das ist zum Beispiel der Fall, wenn eine Vielzahl von Systemen aus zugekauften Unternehmen in eine einzige Anwendung integriert werden sollen. In manchen Fällen ist es zudem notwendig eine bestimmte Anwendung zu ersetzen, zum Beispiel bei unzumutbaren Wartezeiten oder bei Verknüpfung von wechselnde Datenmengen und Datentiefen für Echtzeitabfragen.
Daten können aus dem RDBMS mit Neo4j zudem teilweise oder komplett synchronisiert werden. Ein gängiges Szenario für eine vollständige Synchronisierung sind Anwendungen mit Daten aus mehreren Datenquellen oder wenn mehrere vorhandene Anwendungen in eine Oracle-Datenbank schreiben und eine Änderung dieser Anwendungen aus Kostengründen nicht infrage kommt.
Man muss die Situation realistisch betrachten: Relationale Datenbanken können nicht alles leisten, was ein Unternehmen heute braucht. Wer seine Investitionen in seine RDBMS schützen will, braucht aber nicht auf die Funktionalität einer Graphdatenbank zu verzichten. Vielmehr können Entwickler und Systemarchitekten beide Datenbanktypen gemeinsam nutzen und von den Vorteilen beider Systeme profitieren.
