NoSQL-Architekturen: Wie sich die neuen ?· dern besteht aus mehreren Ansätzen. Die NoSQL-Datenbanken…

  • Published on
    17-Sep-2018

  • View
    212

  • Download
    0

Embed Size (px)

Transcript

  • Definition NoSQLBei der Entwicklung von Softwaresystemen wird heutzutage meistens auf relationale Datenbanken gesetzt. Diese Datenbanken speichern Werte in Tabellen. Tabellen kn-nen zueinander in Beziehung stehen eben in Relationen. Architekten haben praktisch nie eine ernsthafte Alternative zu relationa-len Datenbanken genutzt, obwohl sich in vielen Projekten schon Schwchen abzeich-neten:

    n Die Welt kann man nicht immer in Ta-bellen pressen. Komplexe Datenstruk-turen, wie z.B. Versicherungsvertrge, fhren oft zu aufwndigen Modellen, wenn sie in Tabellen abgelegt werden. Typische Zeichen sind eine Vielzahl von Tabellen mit zahlreichen Beziehungen zueinander. Das verkompliziert die Ent-wicklung.

    n Generische Datenstrukturen und die Erweiterung von Datenstrukturen sind nur schwer mglich. In einer Daten-bank nur eine neue Spalte einzufgen, kann bei einer groen Produktionsda-tenbank de facto unmglich sein. Oft werden daher Tabellen mit Schlssel-Wert-Paaren verwendet, um spter zu Datenstzen Attribute hinzufgen zu knnen. Solche Anstze fhren zu kom-plexen Anfragen. Auerdem ist anhand der Spaltennamen nicht mehr erkenn-bar, welche Daten gespeichert werden. Bei anderen Entwrfen werden CLOBs (Character Large Objects) mit XML oder JSON genutzt, um die Daten ge-nerisch und flexibel zu speichern. Dann knnen Anfragen sich aber nicht mehr auf Attribute dieser Strukturen bezie-hen, da die Datenbank sie einfach nur uninterpretiert abspeichert.

    n Die Schwierigkeiten bei einer Schema-Migration fhren auch dazu, dass eine

    neue Version der Software oft mit ei-nem Datenbank-Schema arbeiten muss, das gar nicht mehr zu den Anforderun-gen passt.

    Hinzu kommen Skalierungsprobleme: Re-lationale Datenbanken knnen meistens nur vertikal skalieren, also indem grere Server genutzt werden man spricht von Scale Up. Zwar gibt es auch Cluster-Anst-ze. Diese beschleunigen dann aber oft nur Lesezugriffe oder setzen einen gemeinsam genutzten Massenspeicher voraus, was die Skalierbarkeit einschrnkt.Es gibt allerdings auch alternative Archi-tekturen. Werden Web-Server genutzt, so knnen Anfragen fr bestimmte Kunden auf einige Server verteilt werden. Diese Ser-ver nutzen dann eine Datenbank, die nur die Daten fr den entsprechenden Kunden-kreis enthalten. Dadurch kann die Last auf viele Datenbanken verteilt werden und so preisgnstiger skaliert werden. Diese Ar-chitektur nutzt also Scale Out: Neue Server knnen hinzugefgt werden, um die Leis-tungsfhigkeit des Systems zu erhhen. Der Ansatz wird allerdings nicht direkt auf der Datenbank untersttzt, sondern auf Ebene der Web-Server.Da relationale Datenbanken nicht fr alle Flle die optimale Lsung darstellen, ist die NoSQL-Bewegung entstanden. NoSQL ist eine Abkrzung fr Not Only SQL sie weist also auch relationalen Datenbanken durchaus einen Einsatzbereich zu. NoSQL ist nicht eine einzige Technologie, son-dern besteht aus mehreren Anstzen. Die NoSQL-Datenbanken lassen sich grob in die folgenden vier Kategorien einteilen:

    n Key-Value-Datenbankenn Large-Column-Datenbankenn Dokumentendatenbankenn Graphendatenbanken

    Key-Value-DatenbankenKey-Value-Datenbanken sind gekennzeich-net durch ein einfaches Mapping von Keys auf Values (siehe Abbildung 1). Das Daten-modell kann als Map verstanden werden. Values knnen beliebige Objekte sein. Der Vorteil dieses Grundprinzips ist nicht nur die leichte Verstndlichkeit, sondern auch die hervorragende Eignung fr Scale-Out-Szenarien. Hierfr werden die Daten aufgeteilt in voneinander unabhngige Shards, die auf verschiedene Server verteilt werden. Dabei werden bestimmte Wertebe-reiche der Keys auf bestimmte Server ver-teilt.Aus dem einfachen Datenmodell resultie-ren auch gleichzeitig die grten Nachteile. Da das Datenmodell vom Grundansatz her nicht fr komplexe Probleme ausgelegt ist und keine Joins mglich sind, kann leicht eine groe Komplexitt im Code entstehen. Weil keine Joins untersttzt werden, muss Denormalisierung eingesetzt werden. De-normalisierung fhrt zu Redundanzen, die bei komplexen Datenmodellen schwierig zu verwalten sein knnen. Um eine komplexe Applikationslogik zu vermeiden, sollten nur schlanke Datenmodelle eingesetzt wer-den.Der Einsatzschwerpunkt von Key-Value-Datenbanken liegt bei hohen Anforderun-gen an Skalierbarkeit und einem einfachen Datenmodell mit vielen Lese- und Schreib-

    NoSQL-Architekturen:Wie sich die neuen Datenbanken

    auswirkenNoSQL-Datenbanken stellen die Architekten von Softwaresystemen vor vllig neue Herausforderungen.

    Mit dem Anbinden einer bestimmten API ist es nicht getan. Der andere Umgang mit Persistenz hat Auswirkungen auf die Architektur von Applikationen und ndert damit die Softwareentwicklung grundlegend.

    Im ersten Teil des Artikels werden die verschiedenen NoSQL-Technologien vorgestellt und im zweiten Teil die Herausforderungen, vor denen Architekten wegen dieser Technologien stehen.

    NoSQL-Architekturen: Wie sich die neuen Datenbanken auswirken

    34

    Abb 1: Datenmodell einer Key-Value-Datenbank.

  • operationen, wie dies z.B. bei den Daten einer User-Session der Fall ist.Ein bekannter Vertreter dieser NoSQL-Kategorie ist Redis (vgl. [red]). Diese popu-lre Key-Value-Datenbank darf dank einer BSD-Lizenz (Berkeley Software Distributi-on) frei verwendet werden. Redis hlt die Daten vollstndig im Hauptspeicher, was zu enormen Performance-Vorteilen fhrt. Beispielsweise kann Redis daher auch als Ersatz fr einen Cache genutzt werden. Diese technische Eigenschaft muss jedoch bei der Definition der Architektur Berck-sichtigung finden. Trotz der In-Memory-Technik werden die Daten von Redis auch persistent auf einem Massenspeicher abge-legt. Neben den reinen Datenbank-Funkti-onalitten bietet Redis auerdem auch ein Messaging-System, sodass sich vielfltige Anwendungsgebiete ergeben. An einer Un-tersttzung fr den Cluster-Betrieb wird derzeit noch gearbeitet. Zurzeit wird nur die Replikation auf andere Knoten unter-sttzt, von denen dann auch gelesen wer-den kann. Ein Failover kann ber die Ver-waltungskomponente Sentinel realisiert werden. Eine echte Verteilung der Daten ist aber noch nicht mglich.Ein anderes Beispiel ist die in Erlang ge-schriebene Open-Source-Datenbank Riak (vgl. [Bas14]). Riak berzeugt unter an-derem durch eine ausgeklgelte Cluster-Verwaltung, die durch das Amazon-Dyna-mo-Papier (vgl. [Vog07]) inspiriert wurde. Dadurch ist eine gute Skalierbarkeit auch fr groe Datenmengen gegeben. Riak ergnzt auerdem das reine Key-Value-Modell durch Indizes und eine integrierte Volltext-Suche. So knnen praktisch belie-big komplexe Queries verarbeitet werden.Die beiden Beispiele Riak und Redis zeigen, dass selbst innerhalb einer NoSQL-Katego-rie wie den Key-Value-Datenbanken gro-e Unterschiede zwischen den Vertretern dieser Kategorie vorliegen: Redis ist eher eine Art Cache mit Persistenz und fr hohe Performance bei kleinen Datenmengen aus-gelegt. Riak hingegen hat die Strken bei groen Datenmengen. So kann also fr je-des Szenario eine mageschneiderte Lsung genutzt werden.

    Large-Column-DatenbankenIn einer Large-Column-Datenbank knnen die Daten im Vergleich zu einer Key-Value-Datenbank besser strukturiert werden. Unter einem Zeilenschlssel werden die Spalten (Columns) mit ihren Werten abge-legt. Zusammengehrige Spalten werden

    in einer so genannten Column Family zu-sammengefasst. Eine Column Family ist da-durch vergleichbar mit dem Konzept einer Tabelle. Abbildung 2 zeigt die Column Fa-mily HOTELS, deren Datenstze durch eindeutige Zeilenschlssel identifiziert wer-den knnen. Ein besonderer Vorteil der Large-Column-Datenbanken ist, dass in je-der Zeile einer Column Family unterschied-liche Spalten gespeichert werden knnen. Im Gegensatz zu relationalen Datenbanken knnen aber keine Beziehungen zwischen Tabellen angelegt werden.Durch eine Aufteilung in unterschiedliche Column Families knnen beispielsweise die allgemeinen Informationen ber die Hotels also Name und Adresse von den Zim-merreservierungen getrennt werden. Lese-operationen mssen dann gegebenenfalls nur die jeweils bentigten Spaltenfamilien aus der Zeile auslesen. Weil es keine Ab-hngigkeit zwischen zwei Datenstzen gibt und diese eindeutig ber Schlssel iden-tifizierbar sind, ist es mglich, sehr groe Datenmengen durch horizontale Verteilung der Daten zu verwalten.HBase (vgl. [Apa14]), die Datenbank des Apache-Hadoop-Projekts, setzt das Kon-zept der Large-Column-Datenbanken um und kann in Clustern unterschiedlichster Gre beliebige Datenmengen verwalten. Durch die gute Hadoop-Integration ist es auch mglich, MapReduce zur Analyse der in HBase gespeicherten Daten zu verwen-den. Das ist wichtig, weil Large-Column-Datenbanken wie HBase keine Joins unter-sttzten.Eine wichtige Alternative zu HBase ist die Datenbank Apache Cassandra (vgl. [Apa09]), die wie HBase ebenfalls auf der JVM luft und unter der Apache License Version 2.0 verfgbar ist. Auch mit Riak (siehe oben) gibt es Gemeinsamkeiten. Wie Riak setzt Cassandra den von Amazon Dy-namo stammenden Verteilungs- und Skalie-rungsmechanismus ein. Hochverfgbarkeit und eine sehr gute Performance erreicht Cassandra durch den Einsatz von Replika-ten.

    DokumentendatenbankenDokumentendatenbanken speichern Daten in Form von schemalosen Dokumenten und verwenden hufig JSON oder XML als Da-tenformat. Die gespeicherten Dokumente knnen Strukturen bestehend aus Arrays mit einfachen Schlssel-Wert-Paaren bis hin zu komplexen Verschachtelungen auf-weisen. Des Weiteren knnen Beziehungen zwischen Dokumenten angelegt und kom-plexe Abfrage erstellt werden.Der Einsatz von Dokumentendatenbanken liegt bei semi-strukturierten Daten, ins-besondere wenn deren Struktur im Laufe der Zeit nderungen unterworfen ist oder wenn sich die Strukturen der gespeicherten Dokumente voneinander unterscheiden. Beispielsweise knnen damit Produktda-tenbanken aufgebaut werden. Sie knnte zum Beispiel folgende Datenstze enthal-ten:

    {

    _id: ObjectId(513f7a151f3cb101b6cf4132), art: T-Shirt, groesse: L, farbe : gruen}

    {

    _id: ObjectId(513f7a151f3cb101b6cf4242), art: Schuh, groesse: 42, absatz : flach, farbe : braun}

    Jeder Datensatz knnte unterschiedliche Attribute enthalten. Volltextsuchen und In-dizes sind ebenfalls mglich.Als Beispiel fr eine Dokumentendaten-bank ist MongoDB (vgl. [Mon13]) zu nen-nen. Diese JSON-Dokumentendatenbank der Firma 10gen ist die am weitesten ver-breitete NoSQL-Dokumentendatenbank. Das flexible Datenmodell, eine gute Doku-mentation, Open-Source AGPL 2.0 Lizenz (Affero General Public License) und die

    03/2014 35

    www.objektspektrum.de

    Abb. 2: Datenmodell einer Large-Column-Datenbank.

  • Untersttzung fr komplexe Abfragen sind Grnde fr die hohe Akzeptanz dieser Da-tenbank.Eine wichtige Alternative ist CouchDB (vgl. [Apa13]), eine Datenbank, die ebenfalls mit JSON-Daten arbeitet. ber eine HTTP-REST Schnittstelle kann diese sehr gut in verschiedenste Applikationen integriert werden. CouchDB ist in Erlang implemen-tiert und steht unter der Apache-2.0-Lizenz.

    GraphendatenbankenGraphendatenbanken bilden Beziehungen zwischen Daten durch gerichtete Graphen ab. Ein gerichteter Graph umfasst eine defi-nierte Menge von Knoten und Kanten. Eine Kante verbindet einen Start- und einen End-knoten. Mehrere Kanten drfen denselben Start- und Endknoten haben (vgl. [Wik]).Das Einsatzgebiet von Graphendatenban-ken liegt dort, wo mit vernetzen Daten-strukturen umgegangen wird. Ein Anwen-dungsfall ist beispielsweise das Verwalten von sozialen Netzwerken oder die Ab-bildung und der effiziente Umgang mit Unternehmensgeflechten im Kontext von Auskunfteien. Abbildung 3 zeigt die bei-spielhafte Verknpfung von Hotels und Be-nutzern zur Erfassung von Empfehlungen. Auch viele andere Domnen lassen sich gut als Graphen modellieren so die Risiko-bewertung bei Versicherungen, Probleme in der Bio-Informatik oder die Portfolio-Analyse.Ein prominenter Vertreter der Graphenda-tenbanken ist Neo4J (vgl. [Neo14]). Die Community-Version von Neo4J steht unter GPL (GNU General Public ) v3, whrend die Enterprise Edition unter einer kom-merziellen Lizenz steht und nur fr Open-Source-Projekte unter AGPL verfgbar ist. Neo4J ist in Java geschrieben und verfgt

    unter anderem ber eine REST-Schnitt-stelle. Im Unterschied zu vielen anderen NoSQL-Datenbanken werden ACID-Transaktionen und Two Phase Commit untersttzt. Das ist auch notwendig, da sinnvolle nderungen an einem Graphen zumeist mehrere Knoten und Kanten um-fassen, whrend bei anderen Datenstruk-turen die Begrenzung auf einen Datensatz ausreichend ist.

    GemeinsamkeitenBei den Datenbanken kristallisieren sich einige wesentliche Grundmerkmale als Ge-meinsamkeiten heraus. Dabei gibt es natr-lich bei der hohen Anzahl der zu NoSQL zugeordneten Datenbanken hier und da auch Ausnahmen.So zeigt sich, dass diese Datenbanken keine fest vorgegebenen Schemata im herkmm-lichen Sinne wie relationale Datenbanken bentigen. Vielmehr knnen in einer Ta-belle, also z.B. einer Collection in einer MongoDB, unterschiedliche Datenstruktu-ren enthalten sein. Das fhrt zu einer zuvor ungekannten Flexibilitt der Datenstruk-turierung und Modellierung in der Daten-bank. Allerdings muss der Code, der mit diesen Daten aus der Datenbank arbeitet, immer noch mit den verschiedenen Daten-stzen umgehen knnen. Insofern ist im Code immer noch ein Schema vorhanden.Auffllig ist auch, dass die Vertreter der NoSQL-Bewegung keine Joins, wie wir sie aus der relationalen Welt kennen, unter-sttzen. Der Grund ist recht trivial: Ms-sen Joins ber Daten ausgefhrt werden, die verteilt ber mehrere Knoten vorliegen, so wre dazu ein sehr groer interner Auf-wand notwendig. Zudem wren diese Joins nur mit geringer Performance umsetzbar.Die Verteilung der Daten auf viele Knoten

    bedingt oft auch eine Replikation von Da-ten. Dann werden Kopien von Daten auf unterschiedlichen Knoten gehalten. Fllt ein Knoten aus, kann das Gesamtsystem dennoch auf alle Daten zugreifen und ent-sprechende Anfragen beantworten. So wird eine hohe Ausfallsicherheit ohne den Ein-satz teurer ausfallsicherer Hardware sicher-gestellt.

    Konsistenz, CAP und BASEIm Zusammenhang mit Replikation und Verteilung taucht die Frage nach der Konsistenz der Daten auf. Hier spielt das CAP-Theorem von Brewer (vgl. [Bre00]) eine entscheidende Rolle. Es besagt, dass Konsistenz (Consistency), Verfgbarkeit (Availability) und Partitionstoleranz (Parti-tion Tolerance) in einem verteilten System nicht alle zur gleichen Zeit erreicht werden knnen. Werden Daten in einem System repliziert, mssen die Knoten stndig n-derungen austauschen. Wenn das Netzwerk ausfllt, spricht man von einer Partitionie-rung des Netzes. Einige Knoten knnen dann nicht mehr alle nderungen empfan-gen. Ein Knoten, der nicht alle nderungen bekommen hat, hat nun bei einer Anfrage zwei Mglichkeiten:

    n Er bearbeitet die Anfrage nicht, um si-cherzustellen, dass keine inkonsistenten Daten zurckgegeben werden schlie-lich knnten die Daten sich ja in der Zwischenzeit gendert haben. Dann ist Konsistenz zwar gewhrleistet, aber keine Verfgbarkeit, da der Knoten sich sozusagen freiwillig abgeschaltet hat.

    n Er bearbeit...

Recommended

View more >