Die Architektur der CortexDB im Vergleich

Als Multi-Model Datenbank ist die CortexDB so konzipiert, dass sie die Daten auf Basis verschiedener Datenbank-Paradigmen verwaltet. Damit bietet sie einfache Möglichkeiten für den breiten Einsatz in verschiedenen Bereichen.

Dieser Artikel entstand mit der Unterstützung der Cortex AG und ist auch in Englisch verfügbar.

Überblick

Im Kern der CortexDB arbeiten ein schemaloser Document-Store und ein mehrdimensionaler Key/Value-Store. Für die Nutzung durch Anwender und Entwickler stehen Graph-Funktionalitäten, die zeitliche Gültigkeit je Feldinhalt, die mehrfache Nutzung einfacher Felder zur Verfügung und auch die Ablage von Binärdaten (Dateien) und JSON-Objekten sind möglich.

Die CortexDB unterscheidet sich daher erheblich von relationalen Datenbanken. Gleichzeitig bietet sie im Kern die Funktionalitäten, die auch von Suchmaschinen und Volltext-Suchfunktionen genutzt werden. Dadurch bietet die CortexDB flexible und agile Funktionen zur Umsetzung von Datenbank-Anwendungen für eine Vielzahl unterschiedlicher Bereiche.

Die Basis heutiger Datenbank-Anwendungen: Relational.

Im Bereich der Datenbanken können mehrere Arten unterschieden werden. Die bekannteste sind relationale Datenbanken, die auf Basis von Tabellen arbeiten. Die Spalten geben immer den selben Aufbau (das Schema) für jeden Datensatz vor. Wenn Inhalte nicht vorhanden sind, bleiben die entsprechenden Felder eines Datensatzes leer. Warum sich die CortexDB hiervon sehr unterscheidet und welche Vorteile dadurch entstehen, soll durch die folgende (kurze) Zusammenfassung verdeutlicht werden:

Um Speicherplatz durch doppelte Inhalte (Redundanzen) zu sparen und um Abfragen und Aktualisierungen zu beschleunigen, werden Datensätze auf mehrere Tabellen aufgeteilt (“normalisiert”). Nur über den Inhalt eines Feldes ist dann ersichtlich, um welchen Datensatz es sich in der anderen Tabelle handelt (über den sog. Fremdschlüssel, der in der anderen Tabelle als eindeutige ID vorliegt).

Das Feld “Company” ist der Fremdschlüssel und kann mehrfach genutzt werden; das Feld ID ist in jeder Tabelle eindeutig einem Datensatz zugeordnet. So ist in der zweiten Tabelle der “Ziel-Datensatz” erkennbar.

Für relationale Datenbanken wurde ursprünglich die Abfragesprache SQL (“structured query language”) entwickelt. Je nach Hersteller liegt diese Sprache in verschiedenen Dialekten (“Derivaten”) vor, so dass ein Austausch von Datenbanken meistens mit sehr hohem Aufwand verbunden ist, wenn der jeweilige SQL-Dialekt und auch andere Funktionen angepasst werden müssen.

Sollen weitere Informationen in einer relationalen Datenbank gespeichert werden, müssen ggf. entsprechend viele Tabellen gebildet oder angepasst werden. Informationen zu unterschiedlichen Objekten werden daher grundsätzlich in verschiedenen Tabellen gespeichert.

Die Komplexität der Tabellen steigt daher mit der Vermeidung von Redundanzen, mit der Anzahl unterschiedlicher Datensatztypen und den Informationen, die ggf. miteinander in Verbindung stehen. Dabei ist zu beachten, dass keine einheitliche Vorgabe zum Aufbau relationaler Datenbanken existiert und nur die Stufen der “Normalisierung” eine Möglichkeit der Orientierung geben. Diese aber keinesfalls verpflichtend zu nutzen sind.

Zu dem erläuterten relationalen Ansatz gehört noch das Thema “Index”. Hierbei handelt es sich um eine weitere Struktur, in der nur ausgesuchte Spalten einer Tabelle sortiert abgelegt werden (häufig in Kombination als sog. “combined index”). Ein solcher Index dient zur schnellen Suche von Datensätzen mit Hilfe verschiedener Algorithmen. Liegt ein solcher Index nicht vor, müsste jeder Datensatz der Reihe nach (“sequentiell”) gelesen werden, um bestimmte Inhalte zu finden.

Für den Index in relationalen Datenbanken gilt, dass es auch hier keine einheitliche Vorgabe gibt und kein universelles Schema existiert. Datenbank-Manager (oder auch Entwickler) sind daher auf eine möglichst genaue Definition der Endanwendung angewiesen, um eine passende Architektur zu finden und um Änderungen in bestehenden Datenbanken möglichst ideal umsetzen zu können.

Alternative zum Index relationaler Datenbanken: Invertierter Index

Insbesondere für umfangreiche Datenmengen (“big data”), für die Textsuche (z.B. bei Suchmaschinen, Wikipedia u.ä.) und auch für andere Anwendungen wird häufig auf das Konzept des “invertierten Index” zurückgegriffen (bspw. bei den Lösungen Lucene und/oder Apache Solr). Hierbei wird aus Dokumenten in einem Indizierungsprozess eine sortierte Liste mit Begriffen gebildet (Index), in der jeweils die Orte (die Dokumente) und die Positionen (der Begriffe im Text) als weitere sortierte Liste abzulesen sind.

Werden einzelne Suchbegriffe oder eine Kombination aus Begriffen gesucht, ist sehr schnell ersichtlich an welchen Stellen diese Begriffe gespeichert wurden. Je genauer zudem die Eingrenzung ist (z.B. mit einer Phrase in Anführungszeichen), desto genauer ist die Bewertung der Relevanz.

Begriffe aus verschiedenen Dokumenten werden in einem invertierten Index abgelegt, um diesen durchsuchen zu können und relevante Ergebnisse zu liefern.

Bei einem invertierten Index handelt es sich somit um einen inhaltsbasierten Index, in dem jeder Begriff nur einmal vorliegt und zu dem eine Liste der Vorkommen gespeichert wird. Dieses wird in einer angepassten Variante auch für die CortexDB eingesetzt und mit weiteren Funktionen kombiniert. Insbesondere wird der invertierte Index bei jeder Datenbankänderung aktualisiert und steht für jedes Attribut eines Datensatzes zur Verfügung.

Damit wird ersichtlich, dass “einfache” Anwendungen, die nur auf den invertierten Index setzen, nicht unbedingt transaktionssicher sind und es sich nicht um Datenbank-Anwendungen handelt. Die CortexDB und die CortexPlatform bieten genau diese Einsatzmöglichkeiten mit einfacher Konfiguration, so dass häufig Fachbereiche selbständig die Standardanwendungen der CortexPlatform konfigurieren können. Für Entwickler stehen die o.g. Datenbankfunktionen und APIs bereit, um individuelle Anwendungen zu entwickeln.

CortexDB im Vergleich zu anderen Datenbanken

Im Gegensatz zu relationalen Datenbanken speichert die CortexDB alle Datensätze in einem schemalosen Format. Es liegt also keine vorgegebene Struktur für Datensätze vor; vielmehr wird ein Speicherbereich definiert, in dem die Datensätze als eigenständige Objekte (autark) gespeichert werden (als sog. Container).

Würden alle Datensätze einer relationalen Datenbank in einer einzigen Tabelle gespeichert, so müsste für jede Information ein Feld vorliegen.

Diese Struktur widerspräche allerdings der Vermeidung von Redundanzen und der Reduktion des Speicherbedarfs. Zudem wären zu viele Felder leer, die von der Datenbank auch verwaltet werden müssten.

Durch die Vermeidung der vorgegebenen Tabellen-Struktur lassen sich die o.g. Probleme lösen. Dafür muss nur eine Ablage für die Datensätze gewählt werden, die eine freie Struktur — eine “schemalose” Speicherung — zulässt. Dieses ermöglichen Document Stores.

Als “Document” gilt jede Art von “Datensatz-Containern”, in dem Felder und Inhalte gleichermaßen gespeichert werden. Durch die fehlende Vorgabe eines Schemas, wie bei Tabellen, müssen in jedem Datensatz auch die Feld-Informationen zu jeder Information vorliegen. Dieses ist bspw. bei den Formaten XML und JSON der Fall. Daher existieren mehrere Datenbank-Lösungen, die zur Speicherung von Datensätzen auf diese Formate zurückgreifen.

Durch ihre Historie nutzt die CortexDB ein eigenes Container-Format, in dem die Informationen gespeichert werden. Eine direkte Übertragung aus einer XML- oder JSON-basierten Anwendung (oder auch csv-Dateien und anderen Datenbanken) ist daher nur mit einer Transformation möglich. Dafür stehen Import-Werkzeuge und API’s zur Verfügung, so dass Anwendungen auch direkt den Zugriff auf die Datenbank nutzen können. Die Rückgabe erfolgt dabei immer als JSON-Objekt.

Die Basis künftiger Datenbank-Anwendungen: CortexDB?

Innerhalb der CortexDB kann mit importierten Transaktionsdaten genauso gearbeitet werden, wie auf aggregierten Daten. Eine Transformation ist also nur während des “Lade-Prozesses” notwendig und wird von den Import-Mechanismen übernommen.

Der Import-Prozess überträgt daher die Datensätze aus den Datenquellen in den Document-Store der CortexDB. Dort können Link-Strukturen (Graphen) aufgebaut werden, um bspw. Hierarchien abzubilden (Eltern-Kind-Verweise, Unternehmensbeteiligungen u.ä.).

Zu einer Transaktion beim Ändern eines Datensatzes (Anlegen, Bearbeiten, Löschen) gehört auch die Aktualisierung des Key/Value-Stores. Dieser erweitert die Möglichkeiten eines invertierten Index um weitere Dimensionen. In diesem Index werden die einzelnen Attribute (Felder), die Inhalte und zu jedem Inhalt die Liste der IDs betroffener Datensätze jeweils sortiert verwaltet.

“Zu jedem Inhalt (value) ist bekannt, in welchen Feldern (keys) und Datensätzen (Doc-ID) er existiert und zu jedem Feld ist bekannt, welche verschiedenen Inhalte existieren.”

Hierbei ist zu beachten, dass der Document Store, wie auch der Key/Value-Store auf einer Festplatte, auf einer SSD oder im Arbeitsspeicher liegen können. Eine entsprechende Konfiguration und Verlagerung ist möglich.

In dem Key/Value-Store wird jedes Feld und jeder Inhalt nur ein einziges mal verwaltet. Dieses gilt auch für vergangene (und künftige) Werte eines Feldes (Historisierung). Damit handelt es sich bei dieser Art der Architektur nicht nur um einen invertierten Index, sondern um die höchste Normalform, die in relationalen Datenbanken nicht sinnvoll eingesetzt werden kann.

Bei jeder Selektion und auch bei einfachen Analysen von Feldinhalten wird ausschließlich mit diesem Key/Value-Store (respektive Feldindex, invertierter Index) gearbeitet.

Hierbei ist zu beachten, dass Selektionen immer im Arbeitsspeicher ausgeführt werden. Die Schnittmenge von zwei ID-Listen (z.B. “Name” und “DSType”), sowie die Ergebnisliste (“Result”) müssen daher im Speicher verwaltet werden können. Die Länge der ID’s beträgt intern 12 Byte (nach außen als UTF-Zeichen dargestellt 24 Byte). Werden zwei Mengen mit je 100 und 200 IDs kombiniert, beträgt die Grundmenge also 300 x 12 Byte plus die Ergebnismenge, die jeweils im Arbeitsspeicher verwaltet werden müssen.

Dadurch, dass die Selektionen ausschließlich im Key/Value-Store der Datenbank durchgeführt werden, ist es nicht notwendig, einzelne Datensätze zu lesen. Dieses wird auch im Rechte- und Rollen-Konzept beachtet, so dass Anwendern ein Lese-, Schreib- und Selektions-Recht eingeräumt werden kann.

Als Folge des separaten Zugriffsrechts auf den Key/Value-Store können auch andere Methoden ausgeführt werden. So ist beispielsweise die Betrachtung und Analyse von Feldinhalten möglich.

Betrachten wir das o.g. Beispiel in Bezug auf das Feld “Income”, so sehen wir, dass vier verschiedene Werte vorliegen, die in fünf unterschiedlichen Datensätzen verwendet werden. Damit sind bereits grundlegende Analysen möglich.

Wie in jedem anderen Feld, ist die Verteilung der Werte in diesem Feld ersichtlich. Darüber hinaus kann beispielsweise die Summe aller Werte ermittelt werden: 287.001 oder auch der Mittelwert: 57.300.

Genauso sind weitere Analysen möglich. Beispielsweise kann zu jedem Wert die Abweichung zum Mittelwert errechnet werden: Für den Wert 65.000 beträgt die Abweichung 7.599,80 — viele weitere Analysen sind daher umsetzbar.

Fazit

Durch die Kombination unterschiedlicher Datenbankmodelle (multi-modell) bietet die CortexDB die Grundlage für schnelle und agile Projektumsetzungen und den Einsatz für umfangreiche Datenmengen. Das Potential dieser Datenbanklösung ist dabei noch nicht ausgeschöpft und lässt auch für die Zukunft noch vieles erwarten, das nicht nur vom Hersteller selbst, sondern auch von anderen Entwicklern und Partnerunternehmen umgesetzt wird.


Dieser Artikel entstand mit der Unterstützung der Cortex AG