Ist SQL beziehungsfähig?

NextSQL durch Polyglot Persistence – Datenbanken neu definieren
Kommentare

Brauchen wir NoSQL wirklich? Oder ist das nur ein Buzzword für alle, die das neue Facebook werden wollen? Und wenn es wirklich sinnvoll ist, sich mit NoSQL zu beschäftigen, was wird dann mit MySQL, Oracle, Microsoft, IBM und Co.?

Vor zehn Jahren war eine Anwendung mit 1 000 Benutzern ein Gigant. Entsprechend großzügig wurde ein solches System auch mit Ressourcen versorgt. Heute, im Zeitalter von Web, Facebook und Co., ist die Tausend der Startpunkt; die Dimension hat sich hier deutlich verschoben, denn groß wird man erst mit Benutzerzahlen im Millionenbereich. Und all diese Benutzer erzeugen oft allein durch ihre Anwesenheit in einer Webanwendung eine Unmenge an Bewegungs- und Verhaltensdaten. Die Geschäftsführung geht dabei davon aus, dass sich diese Daten immer auch gewinnoptimierend aus- bzw. verwerten lassen. Die Daten werden zum Schmiermittel eines Unternehmens, und viele Webunternehmen lassen sich gar von den Daten treiben. Lassen wir dabei mal außer Acht, wer hier von wem getrieben wird.
Bei dem ganzen Sich-treiben-lassen im Datenmeer wird aber schnell klar, dass die vorhandene Technik oft nicht optimal passt. Es macht nun einmal einen großen Unterschied, ob eine Buchung mit einer Handvoll Zahlen sauber in einer Transaktion verarbeitet wird oder die Log-Daten einer Webanwendung analysiert werden, die sich auf 45 Servern, verteilt auf drei Rechenzentren, befindet. Wiederum völlig anders ist die Anforderung für die Bereitstellung einer PHP Session in einem Cluster. Ebenso stellt uns die Frage nach einer Empfehlung für ein Produkt auf Basis der Einkäufe der Freundes-Freunde-Freunde in einem sozialen Netzwerk vor vollständig andere Herausforderungen.

Sind relationale Datenbanken beziehungsfähig?

Nur trotzdem scheinen sich die wenigsten Entwickler damit anfreunden zu können, ihre persönlichen Beziehungen zu einer relationalen SQL-Datenbank aufzugeben. Ironischerweise lassen sich ja gerade Beziehungen in relationalen Datenbanken nur schwer handhaben. Werfen wir kurz einen Blick auf einen Exoten im Bereich der Datenbanken, und zwar die Graphendatenbank Neo4j. Im Rahmen eines Buchprojekts „Neo4j in Action“ zeigen die Autoren einen Performancevergleich. Ein hypothetisches soziales Netzwerk hat dabei eine Million Benutzer mit freundschaftlichen Beziehungen zueinander. Die resultierenden Daten werden jeweils einmal in einer SQL-Datenbank und in Neo4J gespeichert. Nun suchen wir Verbindungen der Personen zueinander. Dabei gehen wir also Fragestellungen nach wie: Wer kennt wen – direkt oder vielleicht auch nur indirekt über eigene Freunde oder deren Freunde? In der ersten Phase – mit Beziehungen der Tiefe 2 – ergeben sich bei beiden Systemen Antwortzeiten von zehn Millisekunden. In der Tiefe 3 findet eine SQL DB die ca. 110 000 Datensätze in etwa 30 Sekunden, die Graph-DB kontert mit 0,2 Sekunden. Bei den 600 000 Sätzen der Tiefe 4 wird die SQL DB mit 30 Minuten Abfragezeit geschlagen von Neo4J mit knapp 1,5 Sekunden. Dabei zeigt die Dimension um den Faktor 1 000 sicherlich, dass es müßig wäre, die konkrete SQL-Datenbank, die genaue Implementierung und die Optimierungsanstrengungen darzulegen.

Schemalos ist nicht konzeptlos

Aber auch in ihren eigentlichen Domänengebieten stehen sich relationale Datenbanken oft selbst im Weg. Die streng mathematische Ausrichtung führt über kurz oder lang zu einem Datenmodell, das, einmal festgelegt, die Zeiten zu überdauern scheint. Änderungen an einem Schema – ein sog. ALTER TABLE – wird bei vielen Sätzen, vielleicht im Millionenbereich, zur Stunden andauernden Geduldsprobe. Im Extremfall entsteht hier dann ein Wartungsfenster; optimistisch der Ausdruck für einen temporären Totalausfall.
Die Nutzung der Datenbanken mündet in der Regel in zwei Rollen. So steht die OLTP-Rolle zu Beginn – also die Aufgabe, Daten transaktional zu erfassen oder zu erzeugen. Ausgewertet werden die Daten dann mit der OLAP-Rolle, womit die Erstellung von Aggregaten wie Summen oder anderen Kennzahlen gemeint sind. OLTP und OLAP sind zwar in sich genommen völlig unterschiedliche Abläufe; trotzdem arbeiten die allermeisten Systeme hier im gleichen Schema. Und häufig ist die OLTP die treibende Kraft; die Analytik tritt in den Hintergrund. Die Mühe, die entstandenen Daten in ein optimiertes Abfrageschema zu überführen, ist oft ein neues Projekt – wobei man Anwendungen wie Data Mining im neuen Data Warehouse teuer bezahlen wird.

Consistency, Availability and Partitionstoleranz

Das Design von Datenbanken muss in Bezug auf das Nutzungskonzept immer ein Kompromiss sein. Dabei wird – insbesondere bei der Betrachtung von Multiusersystemen – immer wieder der Begriff der Konsistenz genannt. Die Konsistenz bezieht sich dabei explizit auf die Benutzersicht der Daten im Netzwerk. So sollen auch in einem vernetzten System alle Benutzer möglichst auch die gleichen Daten sehen. Daneben wird unter dem Begriff der Verfügbarkeit insbesondere auch die Geschwindigkeit beim Zugriff auf die Daten verstanden. Stellt man nun beide Begriffe in den Zusammenhang einer eventuellen Verteilung einer Datenbank auf mehrere Rechner oder gar Standorte, so wird schnell klar, dass hier Kompromisse eingegangen werden müssen. Die Herstellung der Konsistenz kann unter ungünstigen Bedingungen bemerkenswert lange dauern; neben dem reinen Datentransport muss ja auch eine Rückmeldung auf alle Systeme erfolgen und all dies benötigt einfach mal seine Zeit.. Bei einer Änderung von Daten müssen Leseoperationen so lange warten, bis die Verteilung auf alle Partitionen der Datenbank erfolgt ist. Daraus ergibt sich dann entweder Verfügbarkeit (in akzeptabler Geschwindigkeit) oder Konsistenz. Diesen Widerspruch beschreibt das sog. CAP Theorem: Konsistenz (Consistency), Verfügbarkeit (Availability) und Partitionstoleranz (Partition Tolerance) sind demnach in verteilten Systemen niemals gleichzeitig verfügbar. Betrachtet man nun das Heer von NoSQL-Datenbanken, dann stellt man fest, dass hier oft Lösungen für sehr große Datenmengen (Big Data) angedacht werden. Damit setzt man dann zunächst auf das P aus CAP; daneben gilt es, dann entweder die Konsistenz oder die Verfügbarkeit zu wählen.
Eine horizontale Partitionierung, und damit die Verteilung auf mehrere Maschinen etwa in der Cloud, passt einfach nicht zu relationalen Datenbanksystemen. Faktisch der einzige Weg, solche Systeme zu skalieren, ist der Umzug auf eine größere Maschine. Obwohl hier die Innovationszyklen weiterhin klein sind, ist das Wachstum der Datenmengen in vielen Bereichen überproportional höher.
Und schließlich sahen wir bereits die Probleme mit hierarchischem Aufbau, Netzstrukturen und komplexen Beziehungsgeflechten. Auch hier sind wir zügig mit unserem relationalen Datenbanklatein am Ende.

NoSQL: Exotisch? Gefährlich?

Nun scheinen ja NoSQL-Datenbanken gerade hier neue Lösungswege aufzuzeigen. Trotzdem gelten diese Systeme weiterhin als experimentell, wenn nicht sogar exotisch. Auf der Suche nach den Gründen hierfür finden sich Vorbehalte gegen Programmiersprachen wie Erlang und gegen Algorithmen, die eigentlich keine sind – wie MapReduce. Oft ist es aber auch die Angst, die ausgetretenen, sicheren Pfade zu verlassen. Viele Entwickler sind in gewissem Maße konservativ. Neue Technologien werden als gefährlich eingestuft, da diese die Entwicklungszeiten schwerer einschätzbar machen, und oft werden Experten wieder zu Anfängern und verlieren damit einiges an Reputation. Ein weiterer unnützer Irrglaube ist das Streben nach dem universellen Datenbankzugriff. Somit werden dann vorhandene Spezialfunktionalitäten geschickt umgangen, mit Hinweisen wie: „Das läuft dann nicht mehr, wenn wir auf Oracle gehen.“ Meine Erfahrung zeigt, dass es, wenn es wirklich zu einem Wechsel des Datenbanksystems kommt, dieser dann auch mit einem Reengineering der Anwendung einhergeht.

Wo liegen die Dateninseln?

Insbesondere in großen Unternehmen lässt sich immer wieder auch die Bildung von Dateninseln beobachten. Dabei werden dann für spezielle Anwendungsfälle Daten dupliziert und mit anderen Technologien verarbeitet, als es die internen Regularien vorschreiben würden. Typisch etwa ist es, den Internetauftritt mit einem CMS, aufsetzend auf LAMP, zu realisieren, intern dann aber eine Datenhaltung etwa mit Microsoft-Produkten zu handhaben. Falls Sie schon eine CMS-Anwendung realisiert haben, kennen Sie sicherlich die Anforderung nach der Übernahme der Word-Textverarbeitungstexte. Eine Übernahme von „Altdaten“ ist eine elementare Forderung bei der Einführung neuer Systeme. Oft werden aber die Altsysteme teilweise weitergenutzt, und damit entstehen dann Dateninseln, die sich unkontrolliert entwickeln können.

Relational – quo vadis?

Zwangsläufig stellt sich langsam die Frage, ob das relationale Modell vielleicht schon längst ausgedient hat und wir einfach bisher die Signale übersehen haben. Die Antwort darauf ist sicherlich anders als erwartet, denn es stellt sich gar nicht die Frage nach einem radikalen Umstieg. Vielmehr gilt es, Wege zu finden, die bestehenden relationalen Systeme an den Stellen, wo sich Schwächen zeigen, um andere Datenbanksysteme zu ergänzen.

Aufmacherbild: Take my love von Shutterstock / Urheberrecht: diez artwork

[ header = Seite 2: Not only SQL ]

Not only SQL

Dazu gilt es, sich zunächst der besonderen Stärken der einzelnen alternativen Datenbanken bewusst zu werden. Der Begriff NoSQL wird hier bewusst nicht als Gegenentwurf zu SQL verstanden, sondern vielmehr als „not only SQL“. Die Motivation, sich mit Alternativen auseinanderzusetzen, liegt allein in zwei Aspekten. An erster Stelle steht, häufig der wesentliche Faktor, die Verarbeitung von Daten mit hoher Geschwindigkeit. Ab einer bestimmten Datenmenge reden wir dann neben der algorithmischen Verarbeitung auch über die Möglichkeiten der Skalierung, also der Verteilung der Daten und/oder der Verarbeitung derselben. Dieser Aspekt ist also direkt spürbar für jeden Benutzer unserer (Web-)Anwendung. Der zweite Motivationsaspekt liegt in der vereinfachten Softwareentwicklung. Hier ist ausschlaggebend, ob ein System eine spezielle Funktion überhaupt anbietet; etwa die Navigation in Datennetzen. Dass solche Funktionen dann noch deutlich schneller zu Ergebnissen führen, sollte sich von selbst verstehen. Die allermeisten NoSQL-Datenbanken verzichten auf ein explizites Schema und erreichen damit eine deutlich höhere Agilität in der Entwicklung. Der Unterschied zwischen Agilität und „verdammt lange warten“ wird bei der Ausführung eines LTER TABLE Statements auf einer indizierten SQL-Tabelle mit zehn Millionen Datensätzen erfahrbar.
Werfen wir zum weiteren Verständnis einen Blick auf die vier großen Gruppen, in die sich NoSQL-Datenbanken einordnen lassen. Dabei möchte ich keinen Anspruch auf Vollständigkeit erheben; aktuell existieren etwa 150 Vertreter in den unterschiedlichen Gruppen.

Dokumente auf die Bank

Die erste Gruppe bilden dokumentenorientierte Datenbanken wie MongoDB und CouchDB. Hierbei werden die Daten typischerweise in Form von nach JSON-serialisierten Objekten gespeichert. Der Begriff des Dokuments leitet sich eher aus der Abgeschlossenheit eines Datensatzes in sich selbst ab. Eventuell vorhandene Referenzen werden nicht aufgelöst; wohl ist aber ein gewisses Verständnis der Datenbank für eingebettete Objekte oder Listen vorhanden. Teilweise darf ein solches Dokument dann auch mit binären Daten, etwa in Form von Attachements, ergänzt werden.
Typisch ist der Verzicht auf ein Schema; eine Speichereinheit (Datenbank oder Collection) kann beliebige Dokumente aufnehmen. Jedes Dokument erhält eine eindeutige ID und kann damit in der Sammlung wiedergefunden werden. Alternativ ist die Suche mithilfe einer Abfragesprache möglich. Daneben wird der Zugang mittels MapReduce angeboten.

Schlüsseldaten

Die zweite Gruppe bilden die sog. Key-Value Stores. Oft werden hier die Daten rein im Arbeitsspeicher gehalten, womit der Zugriff rasant schnell wird. Prädestiniert sind solche Systeme für die Speicherung von Session-Informationen oder auch als Caching Layer. Es lassen sich aber auch Funktionen finden, die weit über die einfache Speicherung von Schlüssel-Wert-Paaren hinaus gehen. So bietet etwa Redis auch transaktionelle Listenoperationen und ein ausgefeiltes Publish-Subscribe-System; in Riak finden sich auch Dokumenten-DB-Eigenschaften wie die Speicherung von Werten im JSON-Format.

BigTable – Data à la Google

In die dritte Gruppe gehört die bei Google eingesetzte Datenbank BigTable, aber auch Derivate davon wie Cassandra. Hier spricht man von Column-Family-Datenbanken. Die Besonderheit solcher Spaltendatenbanken ist die physikalische Speicherung der Daten als Spalten. Die resultierenden Dateien mit den Spaltengruppen können nun auf getrennten Maschinen gespeichert werden. Interessant ist das Konzept insbesondere dann, wenn etwa Aggregate auf einer Spalte durchgeführt werden sollen. Die zu untersuchenden Werte liegen dabei schon nahe beisammen, und eine solche Verarbeitung spielt die Vorteile der Speichermethode aus.

Mein Freund – dein Freund

Die letzte Gruppe bilden schließlich die Graphendatenbanken. Die Open-Source-Datenbank Neo4j fällt hier insbesondere auf. Graphen-DB legen den Schwerpunkt auf die Navigation zwischen den Datensätzen auf Basis der gespeicherten Beziehungen. So können diese optimal etwa die Freundschaftsbeziehungen in sozialen Netzwerken abbilden. Aber auch Probleme wie eine Routenplanung oder die Erstellung einer Empfehlung lassen sich mit Graphendatenbanken, besser gesagt: durch entsprechende Graphenalgorithmen, lösen.

NextSQL durch Polyglot Persistence

Wir stellen fest, dass relationale Systeme Schwächen besitzen, aber natürlich auch Stärken. Und eine ähnliche Feststellung findet sich auch bei der Betrachtung vieler nicht relationaler Systeme. Sie ahnen vermutlich schon, wo hin der nächste Schritt führen könnte. Die Lösung für die neuen Anforderungen findet sich nicht in der Ablösung der etablierten Systeme. Definieren wir SQL als Synonym für relationale Datenbanken, dann geht es also nicht um den Übergang von SQL zu NoSQL. Vielmehr geht es um eine Neudefinition von zukünftigen Datenbanken und Datenspeichern. Diese NextSQL-Datenbanken müssen die Vorzüge von transaktionalen Systemen besitzen, aber auch flexibel und bedarfsgerecht Spezialisten aus dem NoSQL-Lager integrieren.

Orientalischer Stil

Das Ziel einer solchen polyglotten Datenhaltung kann über unterschiedliche Wege erreicht werden. Vermutlich entstehen hier in Zukunft einige neue Unternehmen. So versucht sich die Datenbank OrientDB bereits eine solche Richtung vorzugeben. Dabei positioniert man sich allerdings als Anbieter des vollen Stacks und wird sich damit wohl nur für Neuentwicklungen empfehlen können. Interessant ist die Entwicklung aber allemal, und da in Java geschrieben, existiert hier schon der erste Port für Android.

Es gibt immer einen noch größeren Fisch

Auch ist davon auszugehen, dass man bei den klassischen Herstellern den Markt sehr genau beobachtet. Und so hat jeder Hersteller eigentlich schon eine Lösung in der Hinterhand, die zumindest Teilaspekte abdeckt. So rechnet man etwa Lotus Notes – mittlerweile ja IBM – zu den NoSQL-dokumentorientierten Datenbanken. Pikanterweise hat der Entwickler von CouchDB (Damien Katz) lange Zeit im Team von Notes gearbeitet. Vermutlich ist davon auszugehen, dass wir in Kürze neben einigen Versuchsballons wie Oracle NoSQL auch Lösungen finden werden, die gleichwertig neben den SQL-Flaggschiffen angesiedelt sind.

Hausgemacht schmeckt am besten

Und schließlich bleibt natürlich noch der Eigenbau. Faktisch haben viele Unternehmen bereits mit dem Aufbau einer polyglotten Datenhaltung begonnen, ohne es vielleicht bewusst gemerkt zu haben. So setzen einige wohlbekannte Produkte und Projekte im Bereich der Quellcodeverwaltung wie Git, Suchsysteme wie Lucene oder Benutzerverwaltungen wie OpenLDAP selbst auf NoSQL-Systemen auf.
Bei der Realisierung eines eigenen polyglotten Datenlayers lässt sich die Aufteilung der Daten auf die einzelnen Datenbanken fein granuliert steuern. Wichtig ist hier aber auch die Bildung eines Leitsystems. Dort sollten zumindest die Identifier für die Basisdaten zentral erstellt werden. Typisch ist aber auch die „Anreicherung“ mit den klassischen, von Menschen lesbaren Daten wie etwa eine Kundennummer oder Vor- und Nachname; darüber hinaus vielleicht noch sämtliche Adressdaten und andere Kontaktdaten. Wahrscheinlich entwickelt sich hieraus schnell eine Anforderung für eine dokumentenorientierte Datenbank, die dann als Leitsystem dient.
Daten wie Sessions, Warenkörbe, aber auch Caching-Systeme lassen sich meist hervorragend mit Key-Value Stores realisieren. Dort sind häufig auch Verfahren für die zeitabhängige Expiration verfügbar, die höchst nützlich für die Verwaltung von Datencaches sind. Dass Beziehungsinformationen in eine Graphen-DB gehören, haben wir bereits mehrfach betont; und auch dass sich dort hervorragend Empfehlungsdaten generieren lassen.
Was bleibt, sind natürlich äußerst wichtige Daten wie der Saldo des Kundenkontos oder die Anzahl eines bestimmten Artikels im Lager; außerdem alle ähnlichen Daten, die stark transaktionsorientiert sind. Und diese Daten dürfen und sollen in den bestehenden relationalen Systemen verbleiben.
Bei einem solchen Aufbau muss klar sein, dass sich dadurch zum einen Redundanzen innerhalb der einzelnen Speicher ergeben können, die aber vermutlich eher gering sein werden. Ein weiteres Problem stellt aber das Routing der Daten auf die einzelnen Speicher dar. Aber auch hier entwickeln sich mit Event Sourcing bzw. CQRS mittlerweile Technologien.

Ausblick

Man darf bei aller Freude über die eigene Problemlösungskompetenz nicht vergessen, dass wir aktuell noch immer über relativ neue Produkte und Projekte sprechen. Somit fehlt dann partiell die Integration in bestehende Sicherungskonzepte oder aber Monitoring-Systeme. Auch der manuelle Neustart von fünfzig Instanzen auf fünfzehn verschiedenen Systemen macht Administratoren nur bedingt Spaß.
Ebenso wird es wohl noch eine Weile dauern, bis der erste Reportgenerator mit NextSQL für Businessanwender die Produktreife erlangt. Wobei – eigentlich ein interessantes Thema für ein Start-up. Und damit möchte ich mich empfehlen – bis zur nächsten Ausgabe des Entwickler Magazins!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -