NoSQL Datenbanken in der Cloud – Datenbanken für Web-Services müssen neben die Geschäfte abschließenden Transaktionen vor allem die suchenden Interaktionen beherrschen – ein wichtige Herausforderung der Zukunft in diesem Genre.

Datenbanken sind seit Jahrzehnten eine Säule der Informationstechnik für die Verwaltung von Daten in Geschäftsprozessen. Das gilt besonders für das Finanzwesen (Banken und Versicherungen), aber auch für den Handel oder das Abwickeln von Dienstleistungsangeboten, etwa die Buchungen von Reiseveranstaltern.

Aufgabe war und ist das gesicherte Abwickeln und Dokumentieren von Geschäftsvorgängen. Diese reichen meist über die gesamte Wertschöpfungskette eines Händlers, von der Bestellung über die Lieferung bis zur Bezahlung oder Mahnung. Die dazu nötigen Vorgänge werden in der IT seit Jahrzenten von Transaktionen bestimmt.

In der Volkswirtschaftslehre bezeichnet man als Transaktion (von lat. trans „über“, actio zu agere „(durch)führen“) eine gegenseitige Übertragung von Verfügungsrechten an Gütern (Waren oder Dienstleistungen). Im Gegensatz zu Transaktionen sind Interaktionen Zugriffe auf eine Datenbasis ohne dabei Veränderungen zu bewirken. In der Informatik dagegen ist der Begriff der Interaktion mit dem Begriff der Kommunikation verwandt.

Anders als das Interaktionskonzept der Soziologie steht Interaktion in der Informatik für Handlungen zwischen Mensch und Computer. Dabei soll das vor über  30 Jahren erfundene Prinzip der „relationalen Datenbanken“, Transaktionen des Geschäfts- und Wirtschaftsleben informationstechnisch  garantieren.

Daher werden in der Informatik Transaktionen als eine Folge von Operationen betrachtet, die als eine logische Einheit gesehen werden. Insbesondere wird für eine Transaktion gefordert, dass sie entweder vollständig ausgeführt sein muss oder keine Veränderung bewirken darf.

Bei der Ausführung von Transaktionen muss das Transaktionssystem daher die sogenannten ACID-Eigenschaften garantieren:

Atomarität (Atomicity): Eine Transaktion wird entweder ganz oder gar nicht ausgeführt. Transaktionen sind also „unteilbar“. Wenn eine atomare Transaktion abgebrochen wird, werden die veränderten Daten zurückgesetzt und die Datenbasis bleibt unverändert, das heißt konsistent.

Konsistenz (Consistency): Nach Abschluss einer Transaktion muss der Datenbestand von einem konsistenten Zustand in einen neuen konsistenten Zustand überführt worden sein. In fast allen Transaktionen werden mehrere Veränderungen in Tabellen vorgenommen, die alle positiv abgeschlossen sein müssen, damit ein neuer konsistenter Zustand der Datenbasis erreicht ist.

Isolation (Isolation): Bei gleichzeitiger Ausführung mehrerer Transaktionen dürfen sich diese nicht gegenseitig beeinflussen.

Dauerhaftigkeit (Durability): Die Auswirkungen einer Transaktion müssen im Datenbestand dauerhaft bestehen bleiben. Die Effekte von Transaktionen dürfen also nicht „mit der Zeit verblassen“ oder „aus Versehen verloren gehen“.

Neue Herausforderungen durch das Internet

Doch diese Welt hat sich mit dem Siegeszug des Internet und der damit verbundenen Dynamik stark verändert. Dort steht eher eine Reihe von Interaktionen im Vordergrund des Handelns. Will man beispielsweise „online“ etwas kaufen, dann sucht der Kunde  erst einmal auf bestimmten Plattformen im Internet, blättert in virtuellen Katalogen und informiert sich bei entsprechenden Preisvergleichsportalen über die Preise.

Findet man  etwa bei otto.de, H&M oder bei Amazon das Gesuchte, legt man  es in den virtuellen Warenkorb, geht im Internet zur Kasse und schließt dann den Bestellvorgang mit bestimmten Vereinbarungen ab. Die Auswahl war bestimmt von einer Vielzahl von Interaktionen, der kaufmännische Bestellvorgang selbst von einigen wenigen Transaktionen.  Das gilt sowohl fürs Internet wie auch  im realen Geschäft an der Kasse („Point of Sale“, POS), an der nur der Geschäftsabschluss per Transaktionen abgewickelt wird.

Diesem einseitigen Mix aus Interaktion und Transaktion sind die klassischen relationalen Datenbanken (RDBMS – Relational Data Base Management Systems) bei Applikationen im web häufig nicht gewachsen. Sie sind streng an der Arbeit mit Transaktionen ausgerichtet.

Das Verhältnis von Interaktionen zu Transaktionen bei typischen web Applikationen kann schon mal  1000 : 1 erreichen. Überlagert wird dieses Lastprofil durch ggf. tausende von Recherchen gleichzeitig. Das funktioniert nur über horizontale Skalierung (Scale out). Vertikale Skalierung (Scale up) kommt sehr schnell an seine Grenzen. Dies zeigt, wo bei dieser Art von Applikationen der Schwerpunkt liegen muss: effiziente – simple – Datenverwaltung die extrem gut horizontal skaliert.

Diese Problemstellungen beispielsweise mit  Oracle RAC oder  IBM Sysplex Cluster mit DB2 angehen zu wollen, führt meist zu einer gewissen Schwerfälligkeit (da die volle Funktionalität der Relationalen DB wird eigentlich nur teilweise genutzt wird) und ist  vor allem für viele Nutzer viel zu teuer. Hier zeigt  sich auch ein Paradigmenwechsel in Bezug auf die vom Markt akzeptierten Kosten für Recherche-Applikationen (extrem hohe Last, viele Interaktionen), aber in vielen Fällen – damit verbunden – wenig Umsatz.

NoSQL Datenbanken gewinnen an Bedeutung

Um diese Situation zu verbessern, gewinnen sogenannte NoSQL Datenbanken zunehmend an Bedeutung. Bei NoSQL Datenbanken , das Kürzel steht für Englisch Not only SQL, handelt es sich um Datenbank Management Systeme , die einen nicht-relationalen Ansatz verfolgen und so mit der langen Geschichte von relationalen Datenbanken brechen. Sie werden häufig in der Wolke des Internets, in der „Cloud“ angeboten.

 

Diese Datenspeicher benötigen keine festgelegten Tabellenschemata.  Sie verzichten auf eine Vielzahl von Funktionen, die man bei ausgereiften RDBs als selbstverständlich erwartet. Allein schon deshalb lässt sich trefflich darüber streiten, ob diese neuen NoSQL Ansätze als „vollwertige“ Datenbanken bezeichnet werden dürfen. Dieser freiwillig geübte Verzichtist in erster Linie dadurch getrieben, eine erheblich bessere horizontale Skalierbarkeit (Scale Out) zu erreichen als dies die etablierten RDB Mitbewerber vermutlich je könnten. Dabei verfolgen die Vertreter der NoSQL Bewegung unterschiedliche technische Ansätze, um sich optimal an Applikationsanforderungen anzupassen, immer verbunden mit dem allgemeinen Ziel Scale Out. Die im akademischen Umfeld meist verwendete Bezeichnung dieser NoSQL Entwicklungen ist „strukturierte Datenspeicher“ (englisch: structured storage).

Bekannte Implementierungen sind Amazon Dynamo und Google BigTable  Darüber hinaus gibt es eine Reihe von Open-Source-Implementierungen, von denen vor allem Apache Cassandra zu nennen ist (Tabelle 1).

Der Begriff  wurde erstmals für eine 1998 erschienene leichtgewichtige Open-Source-Datenbank von Carlo Strozzi verwendet, welche keine SQL-Zugriffsmöglichkeit bereitstellte. Anfang 2009 wurde der Ausdruck NoSQL von Johan Oskarsson in einer Konferenz über verteilte strukturierte Datenspeicher neu eingeführt und etabliert sich seither langsam.

Es ging darum, einen gemeinsamen Begriffs  für die wachsende Zahl an nicht relationalen, verteilten Datenspeichersystemen zu finden, welche meist auch auf ACID-Eigenschaften verzichteten.

Dabei war das Thema nicht brandneu. Daten ohne die Einschränkungen des starren relationalen Modells zu speichern wurde  bereits früher unter dem Motto „Dokumentenorientierte Datenbank“  versucht. Wie Tabelle 2 zeigt, spielen diese Versuche auch heute noch eine gewisse, wenn auch geringe Rolle.

Flexibilität in verteilten Systemen

Viele NoSQL-Implementierungen unterstützen verteilte Datenbanken mit redundanter Datenhaltung auf vielen Servern. Damit können solche Systeme einfach horizontal skalieren und Ausfälle einzelner Server überstehen.

NoSQL-Architekturen bieten meist nur schwächer Garantien hinsichtlich Konsistenz wie beispielsweise „eventually consistent“ (siehe auch unten). Einige dieser Systeme unterstützen auch ACID, beispielsweise durch Hinzufügung spezieller Middleware wie CloudTPS.

Dieses Aufweichen des strengen Konsistenzgarantie („eventually consistent“) bedeutet nicht, dass man generell bereit ist, mit inkonsistenten Daten zu arbeiten. Man nimmt lediglich in Kauf, dass das Überführen der Datenbasis von einem konsistenten Zustand in einen anderen (das findet beim ACID Prinzip in einem nicht unterbrechbaren Vorgang statt ) beim BASE Prinzip asynchron stattfinden darf. BASE steht für Basic Availability, Soft state, Eventual Consistency…

Das heißt, es laufen Hintergrundprozesse, die die erforderlichen Updates erst dann durchführen, wenn Zeit und Ressourcen (CPU, Disc Access Capacity) dafür zur Verfügung stehen. Praktisch bedeutet das, dass eine Änderung der Daten (z.B.  bei Facebook wird ein neuer „Freund“ in mein Netzwerk eingefügt und dieser wird als solcher erst nach einer halben Stunde von anderen Nutzern in der Datenbasis gefunden) meist verzögert auf einen konsistenten Stand gebracht wird und das ist bei vielen dieser web Applikationen tatsächlich akzeptabel.An sich kennt man solche Verfahren schon seit Jahrzehnten von den Buchhaltungssystemen mit ihren „Tagesabschlüssen“.

Noch keine Standards

Da sich die gesamte Situation bei NoSQL noch in einer Entwicklungsphase befindet, gibt es noch keine Standards, auf die Entwickler und Anbieter gesichert zugreifen können. Dies hat dazu geführt, dass mächtige Internet-Player wie Amazon oder Google eigene, proprietäre Lösungen entwickelt haben und nutzen (Tabelle 1). Sie kommen sowohl in den Web Services dieser Anbieter wie auch auf ihren eigenen Vertriebslösungen zum Einsatz.

Namhafte Social Services wie Facebook, Twitter oder Digg arbeiten mit dem quelloffenen  Apache Cassandra, an dessen Entwicklung sie teilweise mitgewirkt haben. Diese Plattformen sind zwar keine „Händler“ wie beispielsweise Amazon, sondern sie bieten vorwiegend ein Kommunikations-Angebot für ihre Mitglieder. In diesem meist ständig wachsenden Daten-Pool eines solchen „Social Networks“ stecken für die Betreiber  gewaltige Geschäftspotentiale, wie fast täglich in den Wirtschaftsgazetten zu lesen ist.

Amazon Dynamo

Amazon Dynamo ist ein verteiltes Dateisystem, das in jüngster Zeit häufig im Zusammenhang  von „Infrastructure as a Service“ (IaaS)  genannt wird. Wie das Google File System ist auch Dynamo für einen konkreten Anwendungsfall optimiert. Es ist  auf die Anforderungen einiger Amazon Web Services (AWS) zugeschnitten, die eine hohe Ausfallsicherheit benötigen.

Für Amazon-Anwendungen muss das dazugehörende  Speichersystem hoch verfügbar und extrem ausfallsicher sein.

Funktionen wie der Shopping Cart Service (der Warenkorb der Amazon-Plattform) erwarten, dass auf das Speichersystem immer schreibend zugegriffen werden kann, das System hoch verfügbar ist und nur geringe Verzögerungen (Latenzzeiten) aufweist. Komplexe Datenbankabfragen werden dabei nicht unterstützt.

Dynamo ist konzipiert,um jederzeit beliebig inkrementell skalieren zu  können und um Belastungsspitzen, beispielsweise im Weihnachtsgeschäft, problemlos abdecken zu können. Komplizierte Datenbankzugriffe werden vermieden, der Zugriff erfolgt direkt über einen Schlüssel.

Dynamo baut auf einem Netz von vollständig gleichberechtigten Rechnern auf, d.h. es gibt keine zentrale Steuerung oder Verwaltung, jeder Knoten kann jede Aufgabe wahrnehmen. Diese Architektur wurde gewählt, um die Skalierbarkeit des Systems optimal gewährleisten zu können.

BigTable

Google arbeitet für seine Dienste mit dem proprietären Hochleistungs-Datenbanksystem Big Table. Es baut unter anderem auf dem Google File System (GFS) auf. Es wird zurzeit vor allem  beim Platform-as-a-Service-Dienst (PaaS) Google App Engine genutzt.

Die Entwicklung von BigTable begann 2004. Es wird mittlerweile von vielen Google-Produkten, wie etwa Google Reader, Google Maps, Google Books, YouTube oder Google Earth, genutzt.

Da BigTable-Datenbanken sehr groß werden können, wurde besonderer Wert auf Skalierbarkeit (durch Unterstützung sehr großer Computercluster) und Geschwindigkeit (durch eine nichtrelationale Struktur) gelegt. Charakteristisch für in BigTable gespeicherte Daten ist, dass sehr häufig Datensätze hinzugefügt werden, vorhandene Datensätze aber sehr selten geändert werden.

Im Gegensatz zu relationalen Datenbanken können die einzelnen  Spalten einer Datei unterschiedliche Größen annehmen. Lediglich die sogenannten „Family Columns“, die einen bestimmten Datentyp ( beispielsweise einen Link, der auf eine web Seite verweist) repräsentieren, müssen bei der Implementierung der Datenbank bekannt sein, können aber beliebig viele Instanzen pro Zeile enthalten.

Technisch spielt bei Google „MapReduce „ eine große Rolle. Das vom Internet-Primus aus Mountain View eingeführte Framework für nebenläufige Berechnungen über große (mehrere Petabyte) Datenmengen auf Computerclustern ist das strukturelle Rückgrat. 2010 wurde für MapReduce ein US-Patent erteilt.

Apache Cassandra

Unter den quelloffenen Lösungen ist Apache Cassandra der Star unter den  einfachen, verteilten NoSQL Datenbankverwaltungssystemen. Es ist auf hohe Skalierbarkeit und zur Gewährleistung von Ausfallsicherheit in großen, verteilten Systemen ausgelegt. Die Daten werden in Schlüssel-Wert-Tabellen abgelegt. Es ist offen dokumentiert und als Freie Software in Java implementiert.

Es wurde ursprünglich bei Facebook von Avinash Lakshman (einem der Autoren von Amazons Dynamo) und Prashant Malik entwickelt und im Juli 2008 freigegeben. Danach haben auch andere große Unternehmen wie IBM oder  Twitter zum Code beigetragen. Das Projekt wurde im März 2009 bei der Apache Software Foundation als Unterprojekt in den Apache Inkubator aufgenommen.

Seit dem 17. Februar 2010  Cassandra zu den „Top-Level“ Projekte der Apache Software Foundation  und ist somit kein Unterprojekt von Apache Inkubator mehr. Es bedient bei Facebook hunderte Millionen von Mitgliedern und wird außerdem bei Twitter und  Digg  genutzt.

Salesforce Database.com

Im Reigen dieser „namhaften“ Angebote sollte auch „Database.com“ von Salesforce genannt werden. Das im Dezember vergangenen Jahres vorgestellte webbasierte Datenbanksystem ist nach eigener Einschätzung das weltweit erste Cloud-Datenbanksystem für Geschäftsanwendungen. Es  ist derzeit noch stark auf die Entwicklung von mobilen Applikationen und Datenmodellen für soziale Funktionalitäten sowie für Push-Dienste ausgerichtet. Da aber Salesforce wie Amazon auch Web Services in eigenen Rechenzentren anbieten kann, sollte es an dieser Stelle genannt werden.

Neben diesen Eigenentwicklungen großer Cloud-Anbieter und Eigennutzer findet sich, wie immer in einer solchen Situation der IT-Geschichte, eine Reihe von Start-ups, die sich dem Thema NoSQL widmen. Viele von ihnen können in den Tabellen von databasepro, Heft 1-2011(Artikel  „Für jeden Topf einen Deckel“ Seite 20) nachgeschlagen werden.

So bleibt abschließend zu analysieren, wie zu diesem Thema die großen Datenbank-Anbieter wie Oracle, IBM oder Microsoft, aber auch Konzerne wie HP oder SAP stehen. Sie haben bisher zu diesem Thema explizit noch keine Statements abgeben. Doch damit ist im Rahmen der „Cloud-Politik“ der Giganten durchaus zu rechnen. Mit geeigneten Übernahmen aus dem Lager der Star-ups könnten auch sie sich die nötige Technik ins Haus holen und damit die Nachfrage ihres Kundenstammes bedienen.

von Rudi Kulzer und Helmut Öhlinger

Veröffentlicht in dem leider später eingestellten Magazin databasepro