Die unlängst erfolgte Übernahme von Whole Foods durch Amazon brachte mich auf das Thema Kultur und auf die Frage, wie Menschen ihre Daten speichern. Setzt man Datenbits mit Konservendosen gleich, dann speichern die meisten ihre Daten so, wie man es aus dem Supermarkt gewohnt ist: in einer Vielzahl langer Reihen neben- und übereinander. Amazon hingegen bedient sich einer weitaus effizienteren Methode, der so genannten „chaotischen Speicherung“, die das klassische Warenlager-Paradigma (sowohl des physisch vorhandenen Warenlagers als auch des Data Warehouse) ins Wanken bringt.

Die Idee hinter dem Regalaufbau im Supermarkt besteht darin, dass der Kunde eine gewisse Ordnung braucht, um zu finden, was er sucht. Auf diese Art und Weise sind auch die meisten Data Warehouses aufgebaut. Denken wir nur an das „Scott/Tiger“-Schemamodell von Oracle, das wir alle zur Genüge kennen:

Dieses Schema ist recht einleuchtend. Mitarbeiter sind Abteilungen zugeordnet, Abteilungen sind Standorten zugeordnet usw. Zu Problemen kommt es dann, wenn Sie versuchen, ein Ergebnis zu generieren, das die Datenbank-Designer nicht eingeplant haben. Um ans Ziel zu gelangen, müssen jetzt nämlich aufwendige Verknüpfungen kreuz und quer in der gesamten Datenbank erstellt werden. Auf unser Supermarkt-Beispiel übertragen bedeutet dies: Wenn Sie Spaghetti machen wollen, dann finden Sie die Sauce normalerweise in demselben Gang wie die Pasta. Wollen Sie Ihr Rezept jedoch mit frischem Gemüse und italienischer Wurst verfeinern, dann wird aus Ihrem kurzen Zwischenstopp im Supermarkt plötzlich ein Marathon, weil diese Produkte am anderen Ende des Ladens aufbewahrt werden.

Laden von Daten im Ist-Zustand ersetzt das Zeilen-und-Spalten-Modell der Datenspeicherung

Der entscheidende Nachteil herkömmlicher, normalisierter Strukturen besteht darin, dass Entwickler und Anwender das Layout der Daten planen müssen, lange bevor die ersten Daten geladen werden. Ändern sich die Projektanforderungen, dann bleibt dem Benutzer nichts anderes übrig, als die benötigten Daten überall in der Datenbank zusammenzusuchen und miteinander zu verknüpfen.

Amazon wusste schon vor langer Zeit, dass sein Geschäft zu schnelllebig ist, um bei der Speicherung bzw. Lagerung von Daten oder Gütern auf den Zeilen-und-Spalten-Ansatz zu setzen. Das Unternehmen empfängt Waren im Ist-Zustand und legt sie in der Reihenfolge ab, in der sie hereinkommen, damit der Lagerort bekannt ist und Güter mit geringer Umschlagsdauer näher am Ausgang positioniert werden können. Ändert sich der Produktmix später, kann das Ablagesystem spontan geändert werden. Das ermöglicht maximale Flexibilität und Kosteneinsparungen.

Dies ist vergleichbar mit der Art und Weise, wie wir bei MarkLogic Entitäten bauen. Wir sammeln alle Informationen über eine Entität (Kunde, Patient, Asset) und machen daraus ein XML- oder JSON-Dokument. Wenn sich die Informationen ändern (neue Demographie, Notizen, Spezifikationen), können wir die Struktur dieses Dokuments entsprechend den neuen Informationen ändern. Wir können auch Links zu anderen Dokumenten und Daten mithilfe von semantischen Beziehungen hinzufügen, die in den Dokumenten eingebettet sind. Anwendungen, die dieses Dokument lesen, können so konfiguriert werden, dass sie die neuen Informationen entweder nutzen oder ignorieren.

NoSQL verändert unsere traditionellen Vorstellungen von relationalen Daten

Das physisch vorhandene Ladenlokal und das Data Warehouse kranken beide an der althergebrachten Vorstellung, dass der Endkunde seine Produkte gerne selbst sucht. Amazon hat bewiesen, dass die Art und Weise, wie Kunden Produkte (Daten oder physische Güter) entdecken und erwerben, und die Methode, wie diese gespeichert (oder gelagert) werden, nicht unmittelbar etwas miteinander zu tun haben müssen. Amazon nutzt einen ausgefeilten Index, um das Verhältnis zwischen Kunden und Auftragsausführung zu verwalten.

Dasselbe gilt auch für die Art und Weise, wie Unternehmen ihre Daten speichern. Relationale Data Warehouses werden allmählich von flexibleren NoSQL-Lösungen abgelöst. Es gibt mehrere Varianten von NoSQL (Dokument, Schlüssel-Wert, Graph, Säule, Multi-Modell) und sie alle haben Stärken und Schwächen, wenn es darum geht, Daten zu speichern. Einige der Varianten (Schlüssel-Wert, Graph) sind besser bei der Datenanalyse als Transaktionen. Viele der Produkte beruhen auf Open-Source-Technologien und besitzen deshalb nicht die Enterprise-Funktionen, die Unternehmen benötigen.

Flexible Daten führen zu einem besseren Kundenerlebnis

MarkLogic kombiniert die Leistung einer NoSQL-Multi-Modell-Datenbank (XML- oder JSON-Dokumente, Text, Binärdateien, Metadaten aus Binärdateien, RDF, raumbezogene Daten, strukturierte Werte/Spalten) mit unternehmenstauglichen Such- und Sicherheitsfunktionen, die es dem Endanwender ermöglichen, exakt das Gesuchte zu finden, ohne zu wissen, wie die Datenstruktur aussieht. Ebenso gibt MarkLogic Data-Warehouse-Designern die Flexibilität, das Modell nach Belieben zu ändern, ohne dadurch das Kundenerlebnis zu beeinträchtigen.
Das Geheimnis besteht darin, dass jeder Datensatz in der Datenbank sein eigenes Schema besitzen kann. Die Datensätze werden zu Dokumenten geordnet, die unterschiedliche Daten, RDF-Tripel und andere Elemente enthalten, die widerspiegeln, wie die Daten verwendet werden sollen.

Denken Sie an eine einfache Transaktion: Sie kaufen die Zutaten für ein Spaghetti-Gericht:

In einem relationalen Schema würden diese Daten in vier oder mehr Tabellen aufgeteilt, wobei für die Rekonstruktion dann aufwendige Verknüpfungen erforderlich wären. In MarkLogic könnten alle für diese Transaktion erforderlichen Daten in einem einzigen Dokument gespeichert werden:

Um unsere Spaghetti-Metapher noch weiter zu treiben: Dies gibt uns die Möglichkeit, alle Zutaten für das Rezept an einem Ort zu speichern, selbst wenn die Zutaten bei einem anderen Rezept anders kombiniert werden. Die Art und Weise, wie die Daten gespeichert werden, hängt nicht von der Art und Weise ihrer Verwendung ab. Der Benutzer kann später entscheiden, wie er die Daten nutzen möchte, denn MarkLogic ist in der Lage, rasch auf diese Anforderung zu reagieren.

Für einen effektiveren Umgang mit Daten in Unternehmen

Dieser Ansatz ist natürlich mit Aufwand verbunden. Damit der Anwender nach Dingen suchen kann, müssen die Daten beispielsweise indiziert werden. MarkLogic besitzt jedoch einen Universalindex für beliebige Abfragen und eine eigene Suchmaschine, die das Auffinden von Daten zusammen einfacher und schneller machen. Der Index benötigt natürlich mehr Speicher- und Rechenleistung, dies kann jedoch durch eine ausgeklügelte Kompression und die Effizienz von kostengünstiger, handelsüblicher und skalierbarer Hardware ausgeglichen werden.

Schon seit langem besagt die gängige Meinung, dass Produkte eigentlich nur in langen Reihen wie in einem physisch vorhandenen Warenlager gelagert werden können. Aber Amazon hat uns gezeigt, dass wir die Art und Weise, wie Produkte lagern, getrennt betrachten können. So wird eine weitaus effizientere, kostengünstigere und skalierbare Lösung zur Lagerung von Produkten (egal ob physisch oder digital) denkbar, die dem Kunden außerdem hocheffektive Funktionen für Suche und Auftragserfüllung an die Hand gibt. Genau wie Amazon die herkömmlichen Methoden der Lagerhaltung revolutioniert hat, verändert auch MarkLogic die Art und Weise, wie Daten in Unternehmen gespeichert und abgerufen werden.

Natürlich wird es Widerspruch von denjenigen geben, die von der traditionellen Zeilen-und-Spalten-Denkweise nicht abweichen wollen. Aber das jüngste Beispiel für eine feste, physische Struktur, die einer flexibleren, besser skalierbaren Lösung weichen musste, wird mit Sicherheit nicht das letzte sein. Der Wandel steht kurz bevor.

Lassen Sie sich von MarkLogic zeigen, wie Sie Ihr Data Warehouse zukunftssicher machen, und warum wir bei flexiblen, leistungsstarken Datenlösungen eine führende Position innehaben.

Gibt es eine bessere Möglichkeit, Daten zu organisieren? Werfen wir einen Blick auf Amazon from MarkLogic.