„In der Natur gibt es auf großer Skalierung nichts, das zentral gesteuert wird“, erklärt uns Barry Morris, Gründer und CEO von Nuodb bei unserem Besuch in der Bostoner Unternehmenszentrale – unweit der berühmten Stanford-University. „Betrachten Sie sich etwa einen Vogelschwarm oder gar die Organisation des Weltalls – nirgends gibt es so etwas wie einen zentralen Lenker“. Mit dieser Erkenntnis machte sich Morris zusammen mit seinem Partner Jim Starkey, der in der Szene seit Interbase-/Borland-Zeiten (Firebird-Projekt) als eine Art Datenbankgenius gilt, an die Schaffung einer von Grund auf neuen Architektur für relationale Datenbanken. Zunächst ging es darum, die genaue Ursache der mangelnden Skalierbarkeit traditioneller Datenbanken zu analysieren. Auf SQL-Ebene schien alles ok – intern entwickelte Testverfahren bei Nuodb hätten bewiesen, dass SQL perfekt skaliere. Als Flaschenhals wurden schließlich die Transaktionen identifiziert, die mit ihren Lock-Mechanismen „jedes Mal im Grunde den ganzen Betrieb aufhalten“, so Barry. „Die Datenbank als Dateisystem zu betrachten – das ist also das Problem“.

Kern der neuen Architektur ist ein Peer-to-Peer-System, das sich wie eine Datenbank verhält. Daten, Indizes und Transaktionsstatus werden in mehreren Nodes vorgehalten und auf Anfrage an den Nodes zur Verfügung gestellt, die diese Informationen benötigen. Nur einige spezielle Nodes speichern Daten dauerhaft. Dabei kommunizieren die Peers über ein spezielles Protokoll, das Multi Version ConcurrencyLockingunterstützt. Das Prinzip: Daten werden nicht gelöscht und auch nicht aktualisiert – jede Operation erzeugt eine neue Version der Daten, mit Zeigern auf die Vorversion. Traditionelle Locks sind nicht erlaubt, stattdessen gibt es ein asynchrones, verteiltes Permission-System.„Das Grundkonzept einer Datenbank zu ändern, ist ein heikles Unterfangen“, erinnert sich Barry. Unternehmen speichern hier die Essenz ihres Business – von daher mussten wir ausführlich und über einen längeren Zeitraum hinweg immer wieder untersuchen, ob unser Konzept den hohen Stabilitäts- und Konsistenzanforderungen standhält. Neben der elastischen Skalierbarkeit und der einfachen Administration gehörte daher strikte ACID-Konformität zu den Designzielen“. ACID steht für Atomicity, Consistency, Isolation and Durability. Diese Eigenschaften gelten in der Datenbankwissenschaft für die Verlässlichkeit von Systemen als unabdingbar.