NoSQL-Architekture: Wie sich die eue Datebake auswirke NoSQL-Architekture: Wie sich die eue Datebake auswirke NoSQL-Datebake stelle die Architekte vo Softwaresysteme vor völlig eue Herausforderuge. Mit dem Abide eier bestimmte API ist es icht geta. Der adere Umgag mit Persistez hat Auswirkuge auf die Architektur vo Applikatioe ud ädert damit die Softwareetwicklug grudleged. Im erste Teil des Artikels werde die verschiedee NoSQL-Techologie vorgestellt ud im zweite Teil die Herausforderuge, vor dee Architekte wege dieser Techologie stehe. Defiitio NoSQL Bei der Etwicklug vo Softwaresysteme wird heutzutage meistes auf relatioale Datebake gesetzt. Diese Datebake speicher Werte i Tabelle. Tabelle köe zueiader i Beziehug stehe ebe i Relatioe. Architekte habe praktisch ie eie ersthafte Alterative zu relatioale Datebake geutzt, obwohl sich i viele Projekte scho Schwäche abzeichete: Die Welt ka ma icht immer i Tabelle presse. Komplexe Datestrukture, wie z.b. Versicherugsverträge, führe oft zu aufwädige Modelle, we sie i Tabelle abgelegt werde. Typische Zeiche sid eie Vielzahl vo Tabelle mit zahlreiche Beziehuge zueiader. Das verkompliziert die Etwicklug. Geerische Datestrukture ud die Erweiterug vo Datestrukture sid ur schwer möglich. I eier Datebak ur eie eue Spalte eizufüge, ka bei eier große Produktiosdatebak de facto umöglich sei. Oft werde daher Tabelle mit Schlüssel- Wert-Paare verwedet, um später zu Datesätze Attribute hizufüge zu köe. Solche Asätze führe zu komplexe Afrage. Außerdem ist ahad der Spalteame icht mehr erkebar, welche Date gespeichert werde. Bei adere Etwürfe werde CLOBs (Character Large Objects) mit XML oder JSON geutzt, um die Date geerisch ud flexibel zu speicher. Da köe Afrage sich aber icht mehr auf Attribute dieser Strukture beziehe, da die Datebak sie eifach ur uiterpretiert abspeichert. Die Schwierigkeite bei eier Schema- Migratio führe auch dazu, dass eie eue Versio der Software oft mit eiem Datebak-Schema arbeite muss, das gar icht mehr zu de Aforderuge passt. Hizu komme Skalierugsprobleme: Relatioale Datebake köe meistes ur vertikal skaliere, also idem größere Server geutzt werde ma spricht vo Scale Up. Zwar gibt es auch Cluster-Asätze. Diese beschleuige da aber oft ur Lesezugriffe oder setze eie gemeisam geutzte Massespeicher voraus, was die Skalierbarkeit eischräkt. Es gibt allerdigs auch alterative Architekture. Werde Web-Server geutzt, so köe Afrage für bestimmte Kude auf eiige Server verteilt werde. Diese Server utze da eie Datebak, die ur die Date für de etsprechede Kudekreis ethalte. Dadurch ka die Last auf viele Datebake verteilt werde ud so preisgüstiger skaliert werde. Diese Architektur utzt also Scale Out: Neue Server köe hizugefügt werde, um die Leistugsfähigkeit des Systems zu erhöhe. Der Asatz wird allerdigs icht direkt auf der Datebak uterstützt, soder auf Ebee der Web-Server. Da relatioale Datebake icht für alle Fälle die optimale Lösug darstelle, ist die NoSQL-Bewegug etstade. NoSQL ist eie Abkürzug für Not Oly SQL sie weist also auch relatioale Datebake durchaus eie Eisatzbereich zu. NoSQL ist icht eie eizige Techologie, soder besteht aus mehrere Asätze. Die NoSQL-Datebake lasse sich grob i die folgede vier Kategorie eiteile: Key-Value-Datebake Large-Colum-Datebake Dokumetedatebake Graphedatebake Key-Value-Datebake Key-Value-Datebake sid gekezeichet durch ei eifaches Mappig vo Keys auf Values (siehe Abbildug 1). Das Datemodell ka als Map verstade werde. Values köe beliebige Objekte sei. Der Vorteil dieses Grudprizips ist icht ur die leichte Verstädlichkeit, soder auch die hervorragede Eigug für Scale- Out-Szearie. Hierfür werde die Date aufgeteilt i voeiader uabhägige Shards, die auf verschiedee Server verteilt werde. Dabei werde bestimmte Wertebereiche der Keys auf bestimmte Server verteilt. Aus dem eifache Datemodell resultiere auch gleichzeitig die größte Nachteile. Da das Datemodell vom Grudasatz her icht für komplexe Probleme ausgelegt ist ud keie Jois möglich sid, ka leicht eie große Komplexität im Code etstehe. Weil keie Jois uterstützt werde, muss Deormalisierug eigesetzt werde. Deormalisierug führt zu Redudaze, die bei komplexe Datemodelle schwierig zu verwalte sei köe. Um eie komplexe Applikatioslogik zu vermeide, sollte ur schlake Datemodelle eigesetzt werde. Der Eisatzschwerpukt vo Key-Value- Datebake liegt bei hohe Aforderuge a Skalierbarkeit ud eiem eifache Datemodell mit viele Lese- ud Schreib- Abb 1: Datemodell eier Key-Value- Datebak. 34
www.objektspektrum.de operatioe, wie dies z.b. bei de Date eier User-Sessio der Fall ist. Ei bekater Vertreter dieser NoSQL- Kategorie ist Redis (vgl. [red]). Diese populäre Key-Value-Datebak darf dak eier BSD-Lizez (Berkeley Software Distributio) frei verwedet werde. Redis hält die Date vollstädig im Hauptspeicher, was zu eorme Performace-Vorteile führt. Beispielsweise ka Redis daher auch als Ersatz für eie Cache geutzt werde. Diese techische Eigeschaft muss jedoch bei der Defiitio der Architektur Berücksichtigug fide. Trotz der I-Memory- Techik werde die Date vo Redis auch persistet auf eiem Massespeicher abgelegt. Nebe de reie Datebak-Fuktioalitäte bietet Redis außerdem auch ei Messagig-System, sodass sich vielfältige Awedugsgebiete ergebe. A eier Uterstützug für de Cluster-Betrieb wird derzeit och gearbeitet. Zurzeit wird ur die Replikatio auf adere Kote uterstützt, vo dee da auch gelese werde ka. Ei Failover ka über die Verwaltugskompoete Setiel realisiert werde. Eie echte Verteilug der Date ist aber och icht möglich. Ei aderes Beispiel ist die i Erlag geschriebee Ope-Source-Datebak Riak (vgl. [Bas14]). Riak überzeugt uter aderem durch eie ausgeklügelte Cluster- Verwaltug, die durch das Amazo-Dyamo-Papier (vgl. [Vog07]) ispiriert wurde. Dadurch ist eie gute Skalierbarkeit auch für große Datemege gegebe. Riak ergäzt außerdem das reie Key-Value- Modell durch Idizes ud eie itegrierte Volltext-Suche. So köe praktisch beliebig komplexe Queries verarbeitet werde. Die beide Beispiele Riak ud Redis zeige, dass selbst ierhalb eier NoSQL-Kategorie wie de Key-Value-Datebake große Uterschiede zwische de Vertreter dieser Kategorie vorliege: Redis ist eher eie Art Cache mit Persistez ud für hohe Performace bei kleie Datemege ausgelegt. Riak higege hat die Stärke bei große Datemege. So ka also für jedes Szeario eie maßgescheiderte Lösug geutzt werde. Large-Colum-Datebake I eier Large-Colum-Datebak köe die Date im Vergleich zu eier Key-Value- Datebak besser strukturiert werde. Uter eiem Zeileschlüssel werde die Spalte (Colums) mit ihre Werte abgelegt. Zusammegehörige Spalte werde Abb. 2: Datemodell eier Large-Colum-Datebak. i eier so geate Colum Family zusammegefasst. Eie Colum Family ist dadurch vergleichbar mit dem Kozept eier Tabelle. Abbildug 2 zeigt die Colum Family HOTELS, dere Datesätze durch eideutige Zeileschlüssel idetifiziert werde köe. Ei besoderer Vorteil der Large-Colum-Datebake ist, dass i jeder Zeile eier Colum Family uterschiedliche Spalte gespeichert werde köe. Im Gegesatz zu relatioale Datebake köe aber keie Beziehuge zwische Tabelle agelegt werde. Durch eie Aufteilug i uterschiedliche Colum Families köe beispielsweise die allgemeie Iformatioe über die Hotels also Name ud Adresse vo de Zimmerreservieruge getret werde. Leseoperatioe müsse da gegebeefalls ur die jeweils beötigte Spaltefamilie aus der Zeile auslese. Weil es keie Abhägigkeit zwische zwei Datesätze gibt ud diese eideutig über Schlüssel idetifizierbar sid, ist es möglich, sehr große Datemege durch horizotale Verteilug der Date zu verwalte. HBase (vgl. [Apa14]), die Datebak des Apache-Hadoop-Projekts, setzt das Kozept der Large-Colum-Datebake um ud ka i Cluster uterschiedlichster Größe beliebige Datemege verwalte. Durch die gute Hadoop-Itegratio ist es auch möglich, MapReduce zur Aalyse der i HBase gespeicherte Date zu verwede. Das ist wichtig, weil Large-Colum- Datebake wie HBase keie Jois uterstützte. Eie wichtige Alterative zu HBase ist die Datebak Apache Cassadra (vgl. [Apa09]), die wie HBase ebefalls auf der JVM läuft ud uter der Apache Licese Versio 2.0 verfügbar ist. Auch mit Riak (siehe obe) gibt es Gemeisamkeite. Wie Riak setzt Cassadra de vo Amazo Dyamo stammede Verteilugs- ud Skalierugsmechaismus ei. Hochverfügbarkeit ud eie sehr gute Performace erreicht Cassadra durch de Eisatz vo Replikate. Dokumetedatebake Dokumetedatebake speicher Date i Form vo schemalose Dokumete ud verwede häufig JSON oder XML als Dateformat. Die gespeicherte Dokumete köe Strukture bestehed aus Arrays mit eifache Schlüssel-Wert-Paare bis hi zu komplexe Verschachteluge aufweise. Des Weitere köe Beziehuge zwische Dokumete agelegt ud komplexe Abfrage erstellt werde. Der Eisatz vo Dokumetedatebake liegt bei semi-strukturierte Date, isbesodere we dere Struktur im Laufe der Zeit Äderuge uterworfe ist oder we sich die Strukture der gespeicherte Dokumete voeiader uterscheide. Beispielsweise köe damit Produktdatebake aufgebaut werde. Sie köte zum Beispiel folgede Datesätze ethalte: { _id : ObjectId( 513f7a151f3cb1 01b6cf4132 ), art : T-Shirt, groesse : L, farbe : grue } { _id : ObjectId( 513f7a151f3cb1 01b6cf4242 ), art : Schuh, groesse : 42, absatz : flach, farbe : brau } Jeder Datesatz köte uterschiedliche Attribute ethalte. Volltextsuche ud Idizes sid ebefalls möglich. Als Beispiel für eie Dokumetedatebak ist MogoDB (vgl. [Mo13]) zu ee. Diese JSON-Dokumetedatebak der Firma 10ge ist die am weiteste verbreitete NoSQL-Dokumetedatebak. Das flexible Datemodell, eie gute Dokumetatio, Ope-Source AGPL 2.0 Lizez (Affero Geeral Public Licese) ud die 03/2014 35
NoSQL-Architekture: Wie sich die eue Datebake auswirke bedigt oft auch eie Replikatio vo Date. Da werde Kopie vo Date auf uterschiedliche Kote gehalte. Fällt ei Kote aus, ka das Gesamtsystem deoch auf alle Date zugreife ud etsprechede Afrage beatworte. So wird eie hohe Ausfallsicherheit ohe de Eisatz teurer ausfallsicherer Hardware sichergestellt. Abb. 3: Datemodell eier Graphedatebak. Uterstützug für komplexe Abfrage sid Grüde für die hohe Akzeptaz dieser Datebak. Eie wichtige Alterative ist CouchDB (vgl. [Apa13]), eie Datebak, die ebefalls mit JSON-Date arbeitet. Über eie HTTP- REST Schittstelle ka diese sehr gut i verschiedeste Applikatioe itegriert werde. CouchDB ist i Erlag implemetiert ud steht uter der Apache-2.0-Lizez. Graphedatebake Graphedatebake bilde Beziehuge zwische Date durch gerichtete Graphe ab. Ei gerichteter Graph umfasst eie defiierte Mege vo Kote ud Kate. Eie Kate verbidet eie Start- ud eie Edkote. Mehrere Kate dürfe deselbe Start- ud Edkote habe (vgl. [Wik]). Das Eisatzgebiet vo Graphedatebake liegt dort, wo mit veretze Datestrukture umgegage wird. Ei Awedugsfall ist beispielsweise das Verwalte vo soziale Netzwerke oder die Abbildug ud der effiziete Umgag mit Uterehmesgeflechte im Kotext vo Auskufteie. Abbildug 3 zeigt die beispielhafte Verküpfug vo Hotels ud Beutzer zur Erfassug vo Empfehluge. Auch viele adere Domäe lasse sich gut als Graphe modelliere so die Risikobewertug bei Versicheruge, Probleme i der Bio-Iformatik oder die Portfolio- Aalyse. Ei promieter Vertreter der Graphedatebake ist Neo4J (vgl. [Neo14]). Die Commuity-Versio vo Neo4J steht uter GPL (GNU Geeral Public ) v3, währed die Eterprise Editio uter eier kommerzielle Lizez steht ud ur für Ope- Source-Projekte uter AGPL verfügbar ist. Neo4J ist i Java geschriebe ud verfügt uter aderem über eie REST-Schittstelle. Im Uterschied zu viele adere NoSQL-Datebake werde ACID- Trasaktioe ud Two Phase Commit uterstützt. Das ist auch otwedig, da sivolle Äderuge a eiem Graphe zumeist mehrere Kote ud Kate umfasse, währed bei adere Datestrukture die Begrezug auf eie Datesatz ausreiched ist. Gemeisamkeite Bei de Datebake kristallisiere sich eiige wesetliche Grudmerkmale als Gemeisamkeite heraus. Dabei gibt es atürlich bei der hohe Azahl der zu NoSQL zugeordete Datebake hier ud da auch Ausahme. So zeigt sich, dass diese Datebake keie fest vorgegebee Schemata im herkömmliche Sie wie relatioale Datebake beötige. Vielmehr köe i eier Tabelle, also z.b. eier Collectio i eier MogoDB, uterschiedliche Datestrukture ethalte sei. Das führt zu eier zuvor ugekate Flexibilität der Datestrukturierug ud Modellierug i der Datebak. Allerdigs muss der Code, der mit diese Date aus der Datebak arbeitet, immer och mit de verschiedee Datesätze umgehe köe. Isofer ist im Code immer och ei Schema vorhade. Auffällig ist auch, dass die Vertreter der NoSQL-Bewegug keie Jois, wie wir sie aus der relatioale Welt kee, uterstütze. Der Grud ist recht trivial: Müsse Jois über Date ausgeführt werde, die verteilt über mehrere Kote vorliege, so wäre dazu ei sehr großer iterer Aufwad otwedig. Zudem wäre diese Jois ur mit geriger Performace umsetzbar. Die Verteilug der Date auf viele Kote Kosistez, CAP ud BASE Im Zusammehag mit Replikatio ud Verteilug taucht die Frage ach der Kosistez der Date auf. Hier spielt das CAP-Theorem vo Brewer (vgl. [Bre00]) eie etscheidede Rolle. Es besagt, dass Kosistez (Cosistecy), Verfügbarkeit (Availability) ud Partitiostoleraz (Partitio Tolerace) i eiem verteilte System icht alle zur gleiche Zeit erreicht werde köe. Werde Date i eiem System repliziert, müsse die Kote städig Äderuge austausche. We das Netzwerk ausfällt, spricht ma vo eier Partitioierug des Netzes. Eiige Kote köe da icht mehr alle Äderuge empfage. Ei Kote, der icht alle Äderuge bekomme hat, hat u bei eier Afrage zwei Möglichkeite: Er bearbeitet die Afrage icht, um sicherzustelle, dass keie ikosistete Date zurückgegebe werde schließlich köte die Date sich ja i der Zwischezeit geädert habe. Da ist Kosistez zwar gewährleistet, aber keie Verfügbarkeit, da der Kote sich sozusage freiwillig abgeschaltet hat. Er bearbeitet die Afrage. Dabei ka es sei, dass er auf eiem veraltete Datebestad arbeitet. Da ist das Ergebis ikosistet mit dem Ergebis, das ei aderer Kote erzeugt hätte. Also ist Verfügbarkeit gegebe, da ja eie Atwort gegebe wird. Aber Kosistez wird icht erreicht, weil adere Kote ei aderes Ergebis zurückgebe köe. Nach diesem Asatz arbeite die meiste NoSQL-Datebake. Dieser Asatz wird auch BASE geat (für Basically Available, Soft-state, Evetually cosistet, vgl. [Pri08]). Das System ist also grudsätzlich verfügbar. Je achdem, welche Kote ma fragt, bekommt ma eie adere Atwort: Der Zustad ist also sozusage weich. Am Ede sid alle Kote kosistet, da sie dieselbe Date habe. Evetually steht ämlich icht für evetuell, soder für am Ede. 36
www.objektspektrum.de I der Realität gibt es Variatiosmöglichkeite beispielsweise ka ma eie bestimmte Zeit warte, bevor ma vo eier Partitioierug ausgeht. Ebeso köe mehrere Replikate gelese werde, um Ikosisteze aufzudecke ud zu kläre. Die meiste NoSQL-Datebake gebe dem Etwickler die Möglichkeit, für jede Zugriff eie Kompromiss im CAP-Bereich zu wähle. Klassische relatioale Systeme higege wähle meistes Kosistez ud Verfügbarkeit sie opfer also die Partitiostoleraz ud gehe vo eier ausreiched verfügbare Ifrastruktur aus. Bei eier Partitioierug oder dem Ausfall eizeler Kompoete arbeite sie da oft gar icht mehr. Das ist bei kleiere Systeme auch akzeptabel, da eie Partitioierug oder ei Ausfall mit ausreicheder Wahrscheilichkeit ausgeschlosse werde köe, we ur weige Kompoete beteiligt sid, die zudem hoch-verfügbar sid. Bei eier horizotale Skalierug ud eiem Arbeite mit icht hoch-verfügbarer Hardware, wie sie die meiste NoSQL-Systeme ermögliche, sid solche Garatie aber meistes icht mehr möglich, da zu viele Kompoete a dem System beteiligt sid. Tiefergehede Erläuteruge zu dem CAP-Theorem ud BASE fide sie bei [Gür12] ud [Wol12]. Herausforderuge für Architekte Neue Techologie stelle Projekte ud Architekte vor eue Herausforderuge: Sie müsse die passede Techologie wähle ud die Herausforderuge mit de eue Techologie auch i der Architektur berücksichtige. Die Persistez-Frage Wie dargestellt, gibt es eie Reihe vo Datebake, die für sich i Aspruch ehme, vieles besser zu hadhabe als relatioale Systeme. Allerdigs besteht die Gefahr, ereut alle erdekliche Date ach dem Motto Oe Size fits all i ei bestimmtes Modell zu presse ur ebe u eie NoSQL-Datebak statt eier relatioale. Diese Diskrepaz hat Marti Fowler i seiem viel beachtete Blog Polyglot Persistece (vgl. [Fow11]) beschriebe. Hier schlägt Fowler vor, je ach Awedugsfall uterschiedliche Datebake i eier Applikatio eizusetze. Der relatioale Welt droht letztedlich icht der Niedergag, soder vielmehr eie sivolle Ergäzug. Dort, wo ei relatioales System otwedig ist, sollte auch eies eigesetzt werde. Müsse semistrukturierte Date ohe ei festes Schema mit eier hohe Performace geschriebe werde, so ka eie dokumeteorietierte Datebak die bessere Wahl sei. Datebake werde sich also i zuküftige Architekture icht mehr ausschließe, soder ergäze. Eie solche polyglotte Architektur kommt aber icht ohe eie Kehrseite der Medaille daher. Das Gesamtsystem wird komplexer ud es müsse mehrere Datebaksysteme gewartet werde. Dies hat auch Eifluss auf die Koste eies Gesamtsystems. Etwickler müsse zudem mehrere verschiedee APIs lere, um diese Datebake aspreche zu köe. Hier bietet übriges das Projekt Sprig Data (vgl. [GoP14]) eie sehr gute Asatz, idem ei eiheitliches Java- Programmiermodell für verschiedee Datebake, auch relatioale, agebote wird. Die Auswahl der zum Eisatz kommede Datebak(e) hägt vo viele Faktore ab: Wie viele Date liege vor, wie sid diese strukturiert ud wie muss auf diese zugegriffe werde? Aufgrud der breite Masse uterschiedlicher Datebake ka hier keie allgemeigültige Atwort gegebe werde, soder es muss vo Fall zu Fall etschiede werde. Das Datevolume ist dabei ur ei Eiflussfaktor auch die Modellierug spielt eie etscheidede Rolle. Schemadesig Das Schemadesig ist bei NoSQL-Datebake wie scho bei relatioale Datebake ebeso ei wesetlicher Faktor für die Performace ud Wartbarkeit. Bei de NoSQL-Datebake geht ma bei der Datemodellierug vo der Fragestellug aus: Welche Frage müsse beatwortet werde? Bei relatioale Datebake wird higege die Frage betrachtet: Welche Date sid vorhade? (vgl. [HSB]). Relatioales Schema-Desig strebt durch Normalisierug eie möglichst redudazfreie ud flexible Modellierug der Date a. Afrage köe sich durch Jois die beötigte Iformatioe zusammesuche ud die Afrage köe durch Idizes optimiert werde. Bei de meiste NoSQL-Datebake gibt es keie Jois das gilt vor allem für Key-Value-, Large- Colum- ud Dokumetedatebake. Daher müsse die Date so zusamme abgelegt werde, dass die geplate Afrage beatwortet werde köe. Außerdem köe Date aus verschiedee Doku- Abb. 4: Dokumet mit Persoedate mit eigebetteter Adresse. mete icht gemeisam geädert werde. Nur Neo4j uterstützt das atomare Äder größerer Teile der Date i eier Trasaktio ach dem ACID-Prizip. Sost sid solche Äderuge auf eizele Datesätze begrezt. Dafür bekommt der Etwickler eie wesetlich bessere Skalierbarkeit bei de NoSQL-Datebake. Außerdem sid NoSQL-Datebake flexibler, de sie sid schemalos ud köe daher praktisch beliebige Date speicher ud verarbeite. Aweduge, die eie NoSQL- Datebak verwede, habe atürlich immer och eie festgelegte Datestruktur, mit der sie arbeite. Der limitierede Faktor bei der Flexibilität ist aber icht mehr die Datebak, soder die Awedug. Bei der Datemodellierug habe sich folgede Asätze als hilfreich erweise: Aggregiere Bei der Aggregatio vo Date werde 1-zu-1- oder 1-zu--Beziehuge zusammegezoge. Das erhöht die Performace bei lesede Zugriffe, da sofort alle abhägige Date ohe Nachlade verfügbar sid. Es führt aber evetuell zu eier höhere Komplexität bei der Verarbeitug der Date ud zu erhöhtem Date-Traffic bei der Äderug eizeler Bestadteile. Alterativ köe Date i Afrage aggregiert werde. Dazu köe beispielsweise Asätze wie MapReduce geutzt werde. Im Beispiel vo Abbildug 4 sid die Adressdate zusamme mit de Persoedate abgelegt. Die führt zu Performacevorteile beim Lade eies Beutzers, da hierbei die etsprechede Date jeweils zusamme abgelegt sid. Deormalisiere Bei der Deormalisierug schafft ma bewusste Dateredudaze. Das ka die Abfrage vereifache oder optimiere. Es hat aber de Nachteil, dass das zu spei- 03/2014 37
NoSQL-Architekture: Wie sich die eue Datebake auswirke che ach alle Hotels i Dortmud wird zuächst bei CITIES der Eitrag mit CITY=Dortmud gesucht. Dieser ethält die IDs aller Hotels i Dortmud. Mittels der IDs der Hotels erfolgt da ei gezielter Zugriff auf die jeweilige Hotels. Abb. 5: Redudate Speicherug durch Eibettug. cherde Datevolume steigt. Außerdem muss die Awedug die Kosistez zwische de verschiedee redudate Iformatioe sicherstelle. Im Beispiel i Abbildug 5 wird dieselbe Adresse sowohl beim Beutzer als auch beim Hotel abgelegt. Das führt zwar zur redudate Ablage derselbe Adresse im System, vereifacht jedoch die Abfrage der jeweilige Hotel- oder Nutzerdate, da sie jeweils mittels eies Datebakzugriffs möglich ist. Clietseitige Jois Die meiste NoSQL-Datebake uterstütze keie Jois. Nichtsdestotrotz sid diese für bestimmte Awedugsfälle fachlich uerlässlich. So lasse sich häufig 1-zu-1- oder 1-zu--Beziehuge mit de Asätze Deormalisiere oder Aggregiere abdecke. Bei -zu-m-beziehuge ist das jedoch meist icht vertretbar. Hier ka auf Asatz des clietseitige Jois der Date zurückgegriffe werde. Das hat atürlich i Bezug auf die übertragee Datemege ud damit auf die Laufzeit sigifikate Auswirkuge, da gegebeefalls erhebliche Datemege verarbeitet werde müsse. Atomare Date I de meiste Datebake sid atomare Äderuge auf eie Datesatz beschräkt. Oft ist es möglich, mit eier eizige Aktio eie Datesatz zu suche ud diese da auch gleich zu äder. Atomare Äderuge über mehrere Datesätze werde vo de meiste NoSQL- Datebake bewusst icht uterstützt, um das Hadlig vo verteile Locks ud Deadlocks zu vermeide. So köe die otwedige Performace ud Skalierbarkeit sichergestellt werde. Eie wesetliche Herausforderug beim Schema-Desig ist also, die Date so zu aggregiere, dass fachliche Datesätze, die zusamme atomar geädert werde müsse, im Schema auch gemeisam abgelegt werde. Idextabelle Selbstverwaltete Idextabelle köe zur Beschleuigug vo Abfrage eigesetzt werde, we dies icht die eigesetzte NoSQL-Datebak vo sich aus uterstützt. Hierbei ist zu berücksichtige, dass die Idextabelle etspreched zu aktualisiere sid. Dies ka i Batch-Läufe erfolge da sid die Idizes icht immer aktuell. Oder es ka währed eies Iserts/Update/Deletes geschehe, was egative Auswirkuge auf die Performace bei schreibede Operatioe hat. I Abbildug 6 wird der Idex für die Eigeschaft Stadt aufgebaut, um auf alle Hotels i eier Stadt zuzugreife. Zur Su- Composite Keys Composite Keys, die sich aus de etsprechede fachliche Werte zusammesetze, köe bei eiige NoSQL-Datebake als mehrdimesioale Idizes verwedet werde. Afrage, die eie solche Zusammesetzug vo Schlüssel utze, köe so beschleuigt werde. Zur Gruppierug vo Date köe Composite Keys ebefalls eigesetzt werde. Das Beispiel i Abbildug 7 zeigt, wie zur Abfrage vo Hotels i eier bestimmte Abb. 7: Verwedug vo Composite Keys. Stadt ud eier bestimmte Azahl vo Stere ei Composite Key, basiered auf CITY:STARS:ID, eigesetzt werde ka. So köe z.b. mittels Dortmud:2 alle Zwei-Stere-Hotels i Dortmud ermittelt werde, ohe dass jeweils der eigetliche Datesatz eies Hotels zu aalysiere ist. Die Afrage ka durch die Date aus dem Idex bereits abgearbeitet werde. Fazit Architekte stehe also dak NoSQL vor eiige Herausforderuge: Abb. 6: Eisatz vo Idextabelle. Sie müsse eie bestimmte Datebak- Techologie wähle. Die eizele 38
www.objektspektrum.de Literatur & Liks [Apa09] The Apache Software Foudatio, Cassadra, 2009, siehe: http://cassadra.apache.org/ [Apa13] The Apache Software Foudatio, CouchDB, 2013, siehe: http://couchdb.apache.org [Apa14] The Apache Software Foudatio, HBase, 2014, siehe: http://hbase.apache.org [Bas14] Basho Techologies, riak, siehe: http://basho.com/riak/ [Bre00] E.A. Brewer, Towards Robust Distributed Systems, Keyote beim 19th ACM Symposium o Priciples of Distributed Computig (PODC), 19.7.2000 [Fow11] M. Fowler, PolyglotPersistece, 2011, siehe: http://martifowler.com/bliki/polyglotpersistece.html [GoP14] GoPivotal, Sprig Data, 2014, siehe: http://www.sprigsource.org/sprig-data/ [Gür12] H.-C. Gürsoy, Was Architekte bei NoSQL-Datebake beachte sollte, i: Java-SPEKTRUM 03/2012 [HSB] Highly Scalable Blog, siehe: http://highlyscalable.wordpress.com/2012/03/01/osql-data-modelig-techiques/ [Mo13] MogoDB, 2013, siehe: http://www.mogodb.org/ [Neo14] Neo Techology, Neo4j, 2014, siehe: http://www.eo4j.org/ [Pri08] D. Pritchett, BASE: A Acid Alterative, ACM Queue, 2008, siehe: http://queue.acm.org/detail.cfm?id=1394128 [red] redis, siehe: http://redis.io/ [Vog07] All Thigs Distributed Werer Vogels weblog o buildig scalable ad robust distributed systems, 2007, siehe: http://www.allthigsdistributed.com/2007/10/amazos_dyamo.html [Wik] Wikipedia, Gerichteter Graph, siehe: http://de.wikipedia.org/wiki/gerichteter_graph [Wol12] E. Wolff, Architekture für die Cloud, i: JavaSPEKTRUM 01/2012 Techologie habe spezifische Vorud Nachteile. So uterstütze dokumeteorietiere Datebake flexible Datestrukture, währed relatioale Modelle Trasaktioe auch über mehrere Tabelle zulasse. Graphedatebake higege sid vor allem für Graphe-Probleme gut geeiget. Im Rahme eier polyglotte Architektur köe durchaus auch mehrere Persistez-Techologie i eiem Projekt geutzt werde. Daher müsse NoSQL ud eie relatioale Datebak auch kei Widerspruch sei, soder köe sich durchaus ergäze. NoSQL-Datebake sid icht ur da sivoll, we die Skalierbarkeit wichtig ist. Gerade Dokumetedatebake ud Graphedatebake habe alterative Datemodelle, die i viele Fälle icht ur für die Performace, soder auch für die Etwicklug wesetliche Vorteile biete. Komplexe Datemodelle lasse sich oft leichter i Dokumete ausdrücke als i eier Vielzahl vo Tabelle. Ud die Datemodelle köe später flexibel erweitert werde. Für NoSQL-Projekte sid zahlreiche Techologie-Etscheiduge zu treffe ud vor allem die Ablage der Date ist etspreched zu strukturiere. Also gibt es viele eue, iteressate Herausforderuge für Architekte. Die Autore Eberhard Wolff (eberhard.wolff@gmail.com) arbeitet als freiberuflicher Architekt ud Berater. Außerdem ist er Java-Champio ud Leiter des Techologie-Beirats der adesso AG. Sei techologischer Schwerpukt liegt auf Sprig, NoSQL ud Cloud. Adreas Hartma (hartma@adesso.de) ist Pricipal Software Architect bei der adesso AG, Vortrageder auf Kofereze sowie Autor diverser Fachartikel. Sei Tätigkeitsschwerpukt liegt i der Kozeptio ud Implemetierug vo leichtgewichtige Softwarearchitekture ud Frameworks auf Basis der JEE-Plattform. Dr. Halil-Cem Gürsoy ist als Pricipal Software Architect bei der adesso AG tätig. Sei techologischer Schwerpukt liegt dabei auf Java-Eterprise. I diesem Kotext kozetriert er sich auf verteilte Systeme, Cloud-Architekture sowie Build- ud Deploymet-Prozesse i verteilte Systeme. Kai Spichale (kai.spichale@adesso.de) ist Software-Egieer bei der adesso AG. Er ist Autor verschiedeer Fachartikel ud regelmäßiger Sprecher auf Kofereze. Seie berufliche Iteresse sid NoSQL, Suchtechologie ud verschiedeste Ope-Source-Java-Techologie. 03/2014 39