Mittwoch, 27. Mai 2015

NoSQL-Datenbanken: Kein Hype, sondern eine Schlüsseltechnologie für Verlage

Vor allem Verlage mit großen Mengen an Inhalten (Dokumenten) beschäftigen sich mit einer Technologie, die unter dem Namen „NoSQL-Datenbank“ immer weitere Verbreitung findet. Diese Datenbanken sind vor allem dann stark, wenn sehr viele unterschiedlich strukturierte Dokumente verwaltet und publiziert werden sollen. Christian Kohl, Referent auf dem nächsten CrossMediaForum, hat beim Verlag Walter de Gruyter diese Technologie eingeführt und erläutert im folgenden Interview, welche Gründe dafür ausschlaggebend waren und wo die Vorteile liegen.

Christian Kohl, de Gruyter
NoSQL ist das Zauberwort im Bereich Content Management. Worin liegt das Revolutionäre dieses Ansatzes?
Christian Kohl: Revolutionär ist sicher ein zu großes Wort. Je nach Anforderungen, Content-Typen und Mengen lässt sich auch mit SQL als Basis sehr gutes Content-Management betreiben. NoSQL, oder präziser dokumentenorientierte Datenbank ("document-oriented" oder "document store") als Unterklasse von NoSQL-DB sind dann wertvoll, wenn große Mengen von Dokumenten mit unterschiedlichen oder sogar sich verändernden Strukturen verarbeitet werden sollen. Das Neue an den dokumentenorientierten NoSQL Datenbanken (DB) ist, dass Dokumente nicht mehr 'geschreddert' werden müssen, damit sie in die Reihen/Zeilen Struktur einer relationalen DB passen, sondern i. d. R. das Dokument als solches in die DB eingespeist wird und diese dann entsprechende Operationen darauf ermöglicht. Hinzu kommt, dass diese DB häufig kein Schema erfordern, es also nicht im Voraus notwendig ist, alle aktuellen und möglichen künftigen Datenstrukturen zu definieren und zu modellieren, sondern die Dokumente 'as is' in die DB übernommen werden können. Damit ist ein schnellerer Start möglich, bspw. mit einem Rapid Prototyping Ansatz.
Welche Rolle spielt XML beim NoSQL-Absatz?
Christian Kohl: NoSQL hat erst einmal nichts mit XML zu tun. Da im Publishing Bereich der Content in den meisten Fällen in XML-Dokumenten vorliegt, wird NoSQL häufig synoym mit "document store" gebraucht. Es geht also um eine Unterklasse von NoSQL-DB, nämlich den dokumentorientierten, und hier noch einmal speziell den XML-Datenbanken. Eine SQL-Datenbank hat ein relationales Datenmodell als Grundlage, grob vereinfacht besteht alles aus Zeilen und Spalten, Werte stehen in Zellen. Eine dokumentorientierte NoSQL-XML-Datenbank hat als Datenmodell XML. Wenn der Anwendungsfall nun das Speichern und Verarbeiten von XML-Dokumenten ist, liegt die Schlussfolgerung nahe, dass eine Datenbank, welche diese Dokumente unverändert speichern und bearbeiten kann, dafür besser geeignet ist, als eine relationale Datenbank, die den Content erst in Zeilen und Spalten zerhacken und dann jeweils wieder zusammensetzen muss. Rein technologisch betrachtet ist eine dokumentorientierte NoSQL-XML-Datenbank der best fit für Anwendungsfälle, bei denen große Mengen XML-Dokumente im Fokus stehen. Was nicht bedeutet, dass es nicht trotzdem andere Gründe geben kann, die dagegen sprechen.
De Gruyter arbeitet seit einiger Zeit mit einer NoSQL-Lösung. Was sind die wesentlichen Veränderungen? Worin liegen die Vorteile?
Christian Kohl: Die Vorteile liegen für uns auf der Performance und auf der Kostenseite. Wir setzen eine NoSQL XML DB ein, die gleichzeitig auch noch eine Suchmaschine ist. Dadurch sparen wir einerseits Lizenzen und /oder Implementierungskosten für eine separate Suchmaschinenlösung, andererseits profitieren wir von der deutlich besseren Performance der XML-DB im Vergleich zu einer relationalen Lösung. Konkret bedeutet das für uns bessere Skalierbarkeit und niedrigere Hostingkosten.
Die größte Veränderung ist das konzeptionelle Umdenken, wenn man aus der relationalen Welt kommt. Kein DB Schema mehr, keine aufwendige Normalisierung, Xquery statt SQL als Abfragesprache. Glücklicherweise ist das für uns als Verlag relativ einfach gewesen, da wir ohnehin XML Know-how im Haus haben. Insofern stellen Xquery und xslt keine Hürden für uns dar. Das kann in anderen Firmen sicher schwieriger sein, wenn Mitarbeiter lange Jahre SQL Erfahrung haben und jetzt radikal umdenken müssten.
Wenn ich ein NoSQL-Konzept umsetzen will – was muss ich dabei besonders beachten?
Christian Kohl: Wie bei der letzten Frage schon erwähnt, sind die Menschen und ihre Fertigkeiten mit das Wichtigste: muss ich möglichweise Umschulungen durchführen, interne Widerstände überwinden? Haben meine Dienstleister das nötige Know-how, denn Xquery ist noch längst nicht so weit verbreitet wie SQL? Daneben gibt es aber auch technische Aspekte: Was sind meine Anforderungen an Konsistenz, Sicherheit, Wiederherstellung, Backup? Je nachdem, wie hier die Anforderungen aussehen, scheiden einige populäre NoSQL Lösung sofort aus. Schließlich noch der Aspekt der Nachhaltigkeit: Wie etabliert ist die Software, die ich einführen möchte, welchen Support gibt es, welche Dienstleister? Hier gibt es große Unterschiede je nach Software im Vergleich zu SQL. Für Oracle oder Microsoft DB findet sich bspw. jederzeit überall ein Dienstleister, der helfen kann. Bei einigen NoSQL-Lösungen wird es schon schwieriger unter Umständen.
Neben kommerziellen Lösungen gibt es auch Open Source-NoSQL-Datenbanken.  Welche Vor- und Nachteile sehen Sie für diese beiden Ansätze?
Christian Kohl: Es gelten grundsätzlich erst einmal dieselben Vor- und Nachteile wie bei nicht-DB Software auch. Bei den dokumentorientierten No-SQL Datenbanken kommt allerdings hinzu, dass es meines Wissens aktuell nur eine Datenbank gibt, welche die ACID-Kriterien erfüllt. Das wird gerne auch als "enterprise feature" bezeichnet. Wenn ich diese Dinge benötige, bspw. um jederzeit ein Rollback machen zu können, Konsistenz zu gewährleisten oder weniger verwundbar gegen Hardwareausfälle zu sein, dann gibt es momentan keine echte Alternative zu der kommerziellen Variante. Aber nicht alle Anwendungsszenarien benötigen diese Features, insofern haben auch OpenSource-Lösungen ihren Platz. 
Ist NoSQL immer die Antwort, oder machen SQL-Lösungen auch in Zukunft Sinn?
Christian Kohl: Natürlich gibt es auch weiterhin Anwendungsszenarien, in denen SQL-Lösungen Sinn machen. Es wird aber sicherlich eine Verschiebung geben, bei der NoSQL mehr und mehr Gewicht gewinnen wird. Gerade im Kontext von "Big Data" und Echtzeit-Anwendungen im Web gibt es sehr viele Fälle, in denen NoSQL technologisch betrachtet die bessere Lösung ist. Nicht umsonst haben Unternehmen wie Facebook oder Google, deren Existenzgrundlage große Datenmengen sind, eigene NoSQL-Datenbanken entwickelt und im Einsatz. 
Ihr Vortragsthema auf dem CrossMediaForum lautet: Crossmedia-Publishing mit NoSQL-Techniken: Möglichkeiten, Einsatzszenarien, Bewertung. Was wird die Kernbotschaft sein?
Christian Kohl: Die Kernbotschaft wird im Wesentlichen eine Synthese aus dem oben gesagten: NoSQL bietet für dokumentlastige Anwendungen, wie sie bei uns Verlagen nun mal im Vordergrund stehen, große Potenziale hinsichtlich Performance, Kosten, time to market und Flexibilität. Dass die meisten großen Verlage inzwischen eine solche Technologie einsetzen, spricht für sich. Dass kleinere Verlage es häufig noch nicht tun, ebenfalls. Wie bei jeder neuen Technologie gibt es Einstiegshürden und Unsicherheit, ob es wirklich nützlich oder nur der nächste Hype ist, von dem in zwei Jahren niemand mehr spricht. Ich glaube nicht, dass es ein Hype ist, sondern für unseren Sektor gute Chancen hat, zu einer Schlüsseltechnologie zu werden.

Keine Kommentare: