whitepaper NoSQL Not only... but also SQL: Flexibilität und Vielfalt in der Persistenz

Transkript

1 whitepaper NoSQL Not only... but also SQL: Flexibilität und Vielfalt in der Persistenz

2 NoSQL Not only... but also SQL: Flexibilität und Vielfalt in der Persistenz Dieses Dokument soll die Technologien, die sich inzwischen unter dem Sammelbegriff NoSQL vereinigen, vorstellen. Die Autoren stellen fest, dass ein relationales Datenbanksystem nicht zwangsläufig die optimale Lösung ist und es sich für so manchen Anwendungsfall durchaus lohnt, auf eine Alternative zu setzen. Und das nicht nur bei verteilten Hochverfügbarkeitssystemen, deren Infrastruktur sich über die Kontinente dieser Erde erstreckt. NoSQL? Jahrzehntelang dominierten relationale Datenbanken die Persistenzschicht in nahezu allen Softwaresystemen. Kein Paradigmenwechsel konnte sie von ihrem Platz an der Spitze verdrängen. Zuletzt wurde ihr Niedergang mit dem Siegeszug objektorientierter Programmiersprachen prophezeit. Wenige Jahre später war klar, dass das Gegenteil geschehen war: Objektrelationales Mapping war die Antwort und damit eine noch stärkere Position der relationalen Datenbanksysteme. Diese unumschränkte Dominanz wird nun durch einen neuen Begriff herausgefordert: NoSQL! Der Begriff NoSQL umfasst eine Reihe von Technologien, die teilweise schon sehr lange bestehen, aber durch die neue, zusammenfassende Bezeichnung, die Kombination mit aktuellen Technologien und veränderter Anforderung an Persistenzlösungen in verteilten Systemen stark an Bedeutung gewonnen haben. NoSQL! Doch was soll dieser Begriff des NoSQL eigentlich bedeuten? Entgegen dem (sicherlich absichtlich erzeugten) Eindruck, dass er sich gegen die Abfragesprache SQL und damit gegen relationale Datenabbildungen wendet, bedeutet NoSQL einfach nur Not only SQL. Mit anderen Worten geht es also darum, Alternativen zu den etablierten relationalen Systemen aufzuzeigen. Diese Alternativen sind untereinander nicht ansatzweise so homogen, wie es die Welt der relationalen Datenbank ist. Einige Gemeinsamkeiten gibt es dennoch. NoSQL- Datenbanken haben kein relationales Datenmodell und damit kein in dem Sinne strikt festgelegtes Schema. eignen sich für den Einsatz in verteilten Systemen, da sie horizontal skalierbar 1 sind. Daher sind sie auch gut geeignet für die Verarbeitung großer Datenmengen. 1 Das bedeutet, dass sich die Leistungsfähigkeit durch das Hinzufügen weiterer Server steigern lässt. sind meistens Open Source bzw. ohne Lizenzkosten benutzbar. Hintergrund Fragt man sich nun, was zu dieser Entwicklung geführt hat, heißt eine kurze und bündige Antwort: Das Web!. Auch das Stichwort Big Data sollte in diesem Zusammenhang genannt werden: In vielen verschiedenen Gesellschaftsbereichen wie Forschung, Wirtschaft und Verwaltung wurden und werden ständig mehr Daten gesammelt, die natürlich im gleichen Maße nach innovativen Persistenzlösungen verlangen. Viele Unternehmen haben sich weltweit verteilte Systeme geschaffen, in denen relationale Datenbanken nicht die alleinige Persistenzlösung darstellen können. Branchen-Schwergewichte wie Amazon, Google und Facebook mussten sich neue Strategien überlegen, um der Herausforderung riesiger Datenmengen, hoher Last durch weltweit verteilte Anfragen und hohen Geschwindigkeitsanforderungen begegnen zu können. Relationale Datenbanken sind angesichts dieser Anforderungen längst nicht so dominant wie bisher, was an einer zentralen Eigenschaft relationaler Datenbanken liegt ACID. Das bedeutet: Atomicity: Entweder werden alle oder gar keine Operation einer Transaktion durchgeführt Consistency: der Datenbestand ist nach Abschluss einer Transaktion in einem konsistenten Zustand Isolation: nebenläufige Datenzugriffe sind voneinander isoliert Durability: alle Daten werden am Ende einer Transaktion dauerhaft persistiert Zwar ist jede dieser Parameter wünschenswert, doch es gibt ein Problem: Es ist nicht möglich, diese Eigenschaften in einem verteilten System aufrecht zu erhalten, bei dem die Verbindungen zwischen den einzelnen Instanzen (also das Netzwerk) nicht immer vollständig zuverlässig Seite 2/9 NoSQL whitepaper

3 ist, ohne die Verfügbarkeit des Systems einzuschränken. Diese Aussage ist Teil des sog. CAP-Theorems, dass nicht nur in der akademischen Welt für Furore gesorgt hat. CAP-Theorem Das CAP-Theorem 2 beschreibt keine Unzulänglichkeit aktueller Datenbanken, sondern vielmehr eine mathematisch bewiesene Einschränkung aller verteilten Systeme. Es besagt, dass bei einer verteilten Datenbank, deren Instanzen durch ein Netzwerk verbunden sind, das nicht immer zu 100% verfügbar ist, niemals die ständige Erreichbarkeit des Systems mit der gleichzeitigen ständigen Konsistenz der Daten vereinbar sind. Vielmehr muss man sich dafür entscheiden, welche der beiden Eigenschaften die höhere Priorität hat. Da Netzwerke in der Praxis nie vollständig zuverlässig sind, als bekanntes Beispiel mögen die Fallacies of Distributed Computing 3 dienen ist die Aussage des CAP-Theorems eindeutig: Angesichts eines potenziell unzuverlässigen Netzwerks ist das unbedingte Festhalten an der Datenkonsistenz nur mit Kompromissen bei der Verfügbarkeit des Systems zu realisieren. Die Vielfalt der NoSQL-Welt Die Welt der klassischen relationalen Datenbanken stellt sich gegenüber der Vielzahl an verschiedenen Projekten aus dem NoSQL-Umfeld relativ homogen dar. Allerdings kann man in all der Heterogenität mittlerweile Gruppen von Datenbanken unterscheiden, die viele Eigenschaften teilen. In der Folge stellen wir die wichtigsten Gruppen und einige ihrer Vertreter vor. Key/Value Store Die Key/Value Stores sind der Beweis dafür, dass alternative Datenbanken schon seit langem bekannt sind: Einer ihrer älteren Vertreter ist DBM, das bereits 1979 für UNIX entwickelt wurde. Die Datenstruktur ist durch den Namen schon weitgehend beschrieben: Ein Schlüssel, der auf einen (im einfachsten Fall) primitiven Wert zeigt. Zwischen den einzelnen Key/Value-Paaren gibt es dabei keine Relationen, weshalb diese Art von Datenbanken sehr gut horizontal skalierbar ist und klare Geschwindigkeitsvorteile gegenüber anderen Datenbanken hat. Genau diese Einschränkung der Verfügbarkeit war und ist für viele Anwendungen nicht denkbar. Dagegen sind phasenweise nicht konsistente Daten durchaus akzeptabel. Ein gutes Beispiel dafür sind große Webangebote wie Facebook, Amazon und Google. Daraus folgt ein anderes Transaktionsmodell. Als Gegenpol zu ACID hat sich hier der Begriff BASE etabliert. BASE (Basic Availability, Soft State, Eventually Consistent) BASE bezeichnet ein Transaktionsmodell, bei dem die Verfügbarkeit oberste Priorität hat (Basic Availability). Konsistenz ist untergeordnet, und die Verantwortung hierfür wird ggf. den zugreifenden Applikationen übertragen (Soft State). Nicht alle Datenbankknoten weisen nach Beendigung einer Transaktion zwingend einen konsistenten Stand auf, jedoch ist gewährleistet, dass eine Datenänderung zum nächstmöglichen Zeitpunkt vollständig an alle relevanten Knoten propagiert wird (Eventually Constistent). ACID und BASE kann man sich als zwei Endpunkte einer Dimension denken, auf der sich die verschiedenen Datenbanken verorten lassen. Die bekannten relationalen Datenbanken sind dabei eher an ACID gelagert, während viele NoSQL-Datenbanken näher an BASE liegen. 2 Das Theorem ist nach den drei Eigenschaften verteilter Systeme benannt, die darin in Beziehung gesetzt werden: Consistency, Availability und Partition Tolerance. 3 Peter Deutsch, The Eight Fallacies of Distributed Computing, Abbildung 1: Key/Value Store Der Einsatz eines solchen Systems bietet sich also immer dann an, wenn das Datenmodell sehr einfach ist und die Geschwindigkeitsanforderungen hoch sind. Mögliche konkrete Einsatzfelder wären damit zum Beispiel das Erfassen von statistischen Daten, wie z.b. der Zeitdauer für die Bearbeitung einer Anfrage in einer Webapplikation oder die Benutzungshäufigkeit von Features. Genauso gut ließe sich aber auch ein einfacher Twitter-Klon oder eine Lesezeichenfunktion im Browsermit einem Key/ Value Store umsetzen. Der bekannteste Vertreter dieser Zunft ist zur Zeit Redis. n Redis Dieser Key/Value-Store ist ein Open Source-Projekt unter BSD-Lizenz und wird mittlerweile maßgeblich durch die für ihre Virtualisierungslösungen bekannte Firma VMWare unterstützt. Neben einfachen Strings kann der für einen Key gespeicherte Wert in Redis auch aus Sets Seite 3/9 NoSQL whitepaper

4 oder Listen bestehen. Das Tool ist sehr flexibel einsetzbar, da es zwei Persistenzmodi unterstützt. Entweder werden die Daten zunächst nur im RAM gehalten und je nach Konfiguration in bestimmten Abständen auf der Festplatte gespeichert, oder es wird direkt auf die Festplatte geschrieben. So lässt sich flexibel bestimmen, wie wichtig die Geschwindigkeit im Vergleich zur Datensicherheit gewichtet werden soll. mehreren Rechnern oder durch mehrere Prozessorkerne auf einem Rechner. Document Stores können besonders dann ihre Stärken ausspielen, wenn Daten strukturiert gespeichert werden müssen, aber ein allgemeingültiges, striktes Schema n Scalaris Ein sehr interessantes, EU-gefördertes Projekt, das gemeinsam durch das Berliner Zuse-Institut und die Firma onscale entwickelt wird. Scalaris besticht durch seine weitgehende Unterstützung von Transaktionen sowie seine Geschwindigkeit. Ein Grund für diese Leistungsfähigkeit ist, dass es sich um einen In-Memory-Datastore handelt. Der Ausfall einzelner Knoten bedeutet hierbei keinen Datenverlust, da die Daten immer auf mehrere Knoten repliziert werden. Scalaris sollte also eingesetzt werden, wenn sehr viele Anfragen schnell über viele Instanzen mit gleichzeitig hohen Anforderungen an die Konsistenz abgearbeitet werden müssen. Das Projekt steht unter der Apache 2.0-Lizenz. Abbildung 2: Document Store Document Store Innerhalb eines Document Stores werden Daten in Strukturen organisiert, die durchaus Ähnlichkeit mit Dokumenten haben, die wir aus dem Alltag kennen. Es gibt nicht viele Vertreter dieser Kategorie, dafür aber mit CouchDB und MongoDB zwei Projekte mit sehr hohem Bekanntheitsgrad. Als Format für die Dokumente verwendet man meist JSON oder dessen binäre Version BSON. JSON hat in der Welt der Webapplikationen XML den Rang abgelaufen und ist ein sehr geeignetes Format für diesen Zweck. Jedes Dokument erhält dabei eine eindeutige Kennung (ID), die den Zugriff auf das Dokument ermöglicht. Anders als in relationalen Datenbanken sind Daten in einem Document Store zunächst nicht miteinander verbunden. Für Abfragen wird daher oft ein Map/Reduce- Ansatz 4 benutzt: in der Map-Phase extrahiert man Ergebnisse aus den einzelnen Dokumenten, die dann in der Reduce-Phase aggregiert werden. Vorteilhaft hierbei ist, dass man die erste Phase parallelisieren kann. auf 4 Map-Reduce-Verfahren zur Datenanalyse und -aggregation finden sich in sehr vielen NoSQL-Datenbanken. Eine Definition und ein erster Einblick finden sich hier: Reduce eher hinderlich wäre. Beispiele hierfür sind CMS-Systeme und E-Commerce-Anwendungen. Ein festes Schema für den gesamten verwalteten Inhalt oder alle angebotenen Produkte wirkt sich hier schlecht auf die Wartbarkeit der Software aus. Mit einem Document Store hingegen lässt sich jedes Produkt beipielsweise als Dokument verwalten, was eine flexiblere Lösung darstellt. Nun aber zu den bereits genannten zwei Platz hirschen unter den Document Stores: CouchDB und MongoDB. n CouchDB Das Motto dieses Systems ist Relax - der Entwickler darf sich also entspannen. Dies fängt schon bei der API an: Sie setzt sehr stark auf die Architektur des Webs und wird somit von Kennern als RESTful 5 bezeichnet. Mit anderen Worten: Wer sich mit Webapplikationen bzw. -technologien auskennt, wird sich hier sehr schnell zurechtfinden. Neben diesem klaren Fokus auf das Web gibt es eine andere Auffälligkeit: CouchDB hat eine herausragende Unterstützung für die Synchronisation zwischen verschiedenen Instanzen. So genügt ein einziger Befehl, um 5 Mehr Informationen zu diesem Programmierparadigma finden sich hier: Seite 4/9 NoSQL whitepaper

5 die Dokumente einer Instanz mit einer anderen Instanz zur synchronisieren. Konflikte werden dabei automatisch erkannt; die Anwendung kann sie dann prüfen und auflösen. Dieses interessante Feature verdankt CouchDB der Vergangenheit des Projektgründers und Hauptentwicklers Damien Katz, der früher zum Lotus Notes Team gehörte. Gerade diese Eigenschaft macht CouchDB in Zeiten mobiler Endgeräte, deren Anbindung an das Internet oft schlecht oder gar nicht gegeben ist, zu einer sehr interessanten Möglichkeit, Daten nach einer unabhängigen Überarbeitung zu synchronisieren. Das sehen die Entwickler hinter dem Projekt genauso und daher gibt es für die zwei populärsten Betriebssysteme für Smartphones und Tablets ios und Android jeweils eine Version von CouchDB, die treffend Couchbase Mobile heißt. Wer Couchbase in eine Applikation integrieren möchte, wird mit hoher Wahrscheinlichkeit eine API in seiner bevorzugten Programmiersprache finden. Darüber hinaus gibt es mit ActiveCouch ein ORM-Framework für Ruby, das vor allem für Rails-Applikationen interessant sein dürfte. Eine Unterstützung innerhalb des Spring Data- Projekts ist geplant. Die Entwicklung von CouchDB wird wesentlich von der Firma Couchbase vorangetrieben, die auch Support und Hosting-Services rund um CouchDB anbietet. n MongoDB Eine der bekanntesten NoSQL-Lösungen ist sicherlich MongoDB, das sich einer großen Popularität innerhalb der Entwicklergemeinde erfreut. Die Zielsetzung der Entwickler ist es, eine einfach zu nutzende, skalierbare, schnelle und flexible Persistenzlösung anzubieten. Wie bei CouchDB werden Daten in Dokumenten gespeichert, und zwar im Format BSON. Diese Dokumente werden in Collections organisiert, die man mit Tabellen in relationalen Systemen vergleichen kann. MongoDB bietet darüber hinaus einige Features an, die in der relationalen Welt sehr beliebt sind: Indizes, dynamische Abfragen, Upserts und einfache Datenaggregation. Gleichzeitig ist es hoch skalierbar und unterstützt fast jede erdenkliche Plattform und Programmiersprache. MongoDB bietet, wie auch CouchDB, mit einer REST-API eine Webtechnologie-affine Schnittstelle. Darüber hinaus besteht eine umfangreiche Unterstützung durch das Spring Data- Projekt und ebenso für Ruby Anwendungen durch MongoMapper. Die Entwicklung von MongoDB wird durch die Firma 10gen geleistet, die Datenbank selbst jedoch steht unter der GNU AGPL 3.0-Lizenz. 10gen bietet kommerzielle Lizenzen, Trainings und Beratung an. Wide Column Stores Wide Column Stores erinnern an die bereits seit Ende der 80er Jahre bekannten spaltenorientierten Datenbanken. Anstatt, wie in relationalen Datenbanken üblich, die Daten eines Datensatzes nebeneinander zu speichern, erfolgt dort die Speicherung der einzelnen Attributausprägungen in spaltenorientierten Datenbanken untereinander. In einer Tabelle, die das Alter von Personen erfasst, würden also die verschiedenen Geburtstage nebeneinander stehen und nicht etwa zeilenorientiert: Name, Geburtstag; Name, Geburtstag; usw. Name, Name; Geburtstag, Geburtstag; Beispiele für solche Datenbanken sind Sybase IQ oder MonetDB. Der Vorteil dieser Datenorganisation liegt auf der Hand: Sie eignet sich hervorragend für die Aggregation von Daten, und spaltenorientierte Datenbanken sind daher vor allem im Data Warehouse- und Data Mining- Umfeld zu finden. Wide Column Stores besitzen eine gewisse Ähnlichkeit zu diesen Datenbanken. Ihr Vorbild ist BigTable, eine Datenbank, die hinter fast allen bekannten Google-Angeboten steht. Diese Technologie ist zwar nur indirekt über die Google App Engine für Dritte nutzbar, wurde aber von Google 2006 in einem wissenschaftlichen Vortrag vorgestellt. Dort wird BigTable als sparse, distributed, persistent multidimensional sorted map beschrieben. Jeder Wert in dieser Map wird einem Spalten- und Zeilenschlüssel zugeordnet. Das von den Google-Mitarbeitern gewählte Beispiel ist die Speicherung von Informationen über Webseiten: Der (invertierte) Name der Website stellt den Zeilenschlüssel dar. Zu dieser Webseite können in Spalten Eigenschaften gespeichert werden, wie z.b. deren Inhalt (eine sogenannte Column Family). Diesen Werten wird dann noch ein Zeitstempel zugewiesen: In diesem Fall der Zeitpunkt, an dem der Crawler diese Information gespeichert hat. Das Design von BigTable ist darauf ausgelegt, einer Vielzahl von Anforderungen gerecht zu werden. Eine konstante Anforderung deutet schon der Name an: Es geht um die horizontale Skalierung sehr großer Datenmengen. n HBase Hierbei handelt es sich um ein Open Source-Projekt unter Apache 2.0-Lizenz, dessen Hauptentwickler mittlerweile für Microsoft arbeiten. HBase orientiert sich sehr stark an BigTable und kann für die dazu nötigen Komponenten auf schon etablierte Open Source-Projekte wie Seite 5/9 NoSQL whitepaper

6 Abbildung 3: Wide Column Store das verteilte Dateisystem Hadoop zurückgreifen. HBase wird bei vielen großen Firmen wie z.b. Yahoo intensiv genutzt und gilt als sehr stabil. Durch die Orientierung an BigTable ist das System sehr einfach horizontal skalierbar. Allerdings sind Installation und Betrieb aller Komponenten aufwändig, was für kleine Installationen eher unrentabel ist. Entschließt man sich trotzdem für HBase, findet man mit MassiveRecord ORM-Support für Ruby- Anwendungen vor. Auch eine Integration in das Spring Data-Projekt ist geplant. n Amazon Simple DB Falls ein Wide Column Store die richtige Lösung für ein Persistenzproblem darstellt, aber die Datenmenge oder sonstige Rahmenbedingungen nicht den Aufbau eines solchen Systems lohnen, ist die Product-as-a-Service-Lösung Amazon Simple DB eine gute Alternative. Hier zahlt man rein nach Nutzung (belegter Speicher, Übertragungsvolumen und Rechenzeit für Abfragen) und kann festlegen, in welchen Rechenzentren die Daten vorgehalten werden. Die Daten lassen sich über ein einfaches Interface via REST oder SOAP abfragen, und es werden Schnittstellenbibliotheken für viele gängige Programmiersprachen zur Verfügung gestellt. Amazon Simple DB ist vor allem dann interessant, wenn man für dasselbe Projekt bereits andere Amazon Web Services-Dienste verwendet, da die Produkte über eine gute Integration verfügen. AWS stellt für alle gängigen Programmiersprachen entsprechende SDKs bereit. Graph DBs Viele Leser werden sich bei dem Begriff des Graphen sofort an das Studium erinnert fühlen: Das Königsberger Brückenproblem oder Traveling Salesman stellen meist erste Berührungspunkte mit dem Ansatz dar, ein komplexes Problem auf die abstrakte Form von Knoten und deren Relationen, den sogenannten Kanten, anzuwenden. Praktische Erfahrungen, die aus diesem Ansatz resultieren, werden erfolgreich in Logistik, technischen und sozialen Netzwerken sowie in vielen anderen Berei- Seite 6/9 NoSQL whitepaper

7 chen eingesetzt. objektorientierte oder XML-Datenbanken. Darüber hinaus entstehen ständig neue Projekte, und bestehende Lösungen werden fortentwickelt, so dass jede Beschreibung zwangsläufig nur eine Momentaufnahme darstellen kann. Orientierung in der neuen Datenbankwelt Die Vielfalt der schönen neuen Datenbankwelt erscheint zu Anfang überwältigend. Aber die zur Verfügung stehenden Möglichkeiten sind nicht nur zahlreicher, sondern auch deutlich vielfältiger geworden. Darum fällt die Analyse leichter, als sie im ersten Moment vielleicht erscheint. Es sind zwar viele neue Datenbanken verfügbar, aber diese sind wesentlich differenzierter und das machtauch die Auswahl einfacher. Abbildung 4: Wide Column Store Die Entwicklung von Graph DBs begründet sich darin, dass sich die genannten Strukturen nur sehr schlecht mit anderen Datenbanken abbilden lassen. Darüber hinaus bieten Graph DBs spezialisierte Interfaces an, die die Arbeit mit der Datenstruktur wesentlich erleichtern. Graphen, die in diesen Datenbanken verarbeitet werden, werden weithin Property Graphs genannt und bieten vielfältige Möglichkeiten zur Abbildung komplexer Beziehungen. n Neo4J Im vergleichsweise jungen Feld der Graph DBs ist Neo4J das auffälligste Projekt, da es schon seit einigen Jahren im Produktiveinsatz ist. Neo4J ist eine Entwicklung der Neo Technology, die das Projekt unter der AGPL v3 freigegeben hat und auch kommerzielle Lizenzen anbietet. Neo4J zeichnet eignet sich sowohl für den eingebetteten Betrieb als auch für den Einsatz als Server. Für den Fall, dass die Kapazität eines Servers nicht ausreicht, bietet Neo4J die Möglichkeit der Replizierung durch einen Master auf mehrere Slaves. Wenn auch Schreibvorgänge auf mehrere Maschinen verteilt werden sollen, gibt es nur die von relationalen Datenbanken bekannte Lösung des Shardings als mögliches Mittel. Neo4J ist in Java implementiert und bietet neben einer Java-Schnittstelle auch eine API für viele andere Programmiersprachen und via REST an. Mit Spring Data Neo4J steht auch ein weitergehende Integration für Java-Projekte bereit. Und sonst? Neben den beschriebenen Kategorien gibt es noch eine Vielzahl anderer Gruppen von NoSQL-Vertretern, wie No more SQL? In jeder IT-Landschaft dürfte es eine große Anzahl von Persistierungsaufgaben geben, für die im Moment relationale Datenbanken eingesetzt werden. Müssen diese nun alle auf den Prüfstand gestellt werden? Die klare Antwort lautet: Jein! Man kann getrost der Prämisse folgen, dass man keine Probleme lösen sollte, die man nicht hat: Wenn die implementierten Lösungen gut funktionieren, gibt es schließlich keinen Grund, sie abzulösen, selbst wenn eine relationale Datenbank nicht mehr die perfekte Lösung zu sein scheint, wenn man sich die neuen Möglichkeiten vor Augen hält. Völlig anders stellt sich die Situation dar, wenn bestehende Systeme durch wiederkehrende Probleme auf sich aufmerksam machen oder neue Projekte in Angriff genommen werden. In diesen Fällen ist es durchaus sinnvoll, die klassische relationale Datenbank gegen die NoSQL-Alternative abzuwägen. In diesem Zusammenhang sollte man sich einer Reihe einfacher Fragen beantworten: Welche Mindestanforderungen bestehen an das Transaktionsmodell: Kann auf ein bestimmtes Maß an Konsistenz verzichtet werden und wie wichtig ist dagegen die Verfügbarkeit der Datenbank? Wie hoch ist die zu erwartende oder aktuelle Datenmenge? Zwar werden nur wenige Unternehmen mit Daten im Petabytebereich konfrontiert, aber die Leistungsgrenze eines einzelnen Servers ist schon deutlich unterhalb dieser Marke erreicht. Wie viele Anfragen welcher Art sind zu erwarten? Neben einer hohen Datenmenge kann eine sehr hohe Zahl an Abfragen dazu führen, dass horizontale Skalierbarkeit wünschenswert ist. Seite 7/9 NoSQL whitepaper

8 Ebenso ist die Struktur der Abfragen interessant, da dies einen Hinweis darauf geben kann, inwieweit man von Caching profitieren kann. Während relationale Datenbanken hier meist auf einen eingebauten Query Cache setzen, kann man bei den meisten NoSQL-Alternativen auf die schon aus dem Web bewährten Lösungen innerhalb des HTTP-Protokolls zurückgreifen, was wesentlich flexibler ist. Ist das strenge, relationale Datenbankschema ein Vorteil oder ein Nachteil bei der Lösung des vorliegenden Problems? Werden eine Vielzahl von Constraints festgelegt und man ist froh sich über deren Einhaltung sicher zu sein, oder führen häufige Downtimes wegen Schemaänderungen bereits zu Kopfzerbrechen und Denormalisierung der Tabellenstruktur? Entsprechen die Daten im Wesentlichen einem relationalen Modell oder müssen die Daten mühsam diesem Modell angepasst werden? Falls Letzteres zutrifft, ist es wahrscheinlich, dass einer der bisher beschriebenen NoSQL-Vertreter das Problem besser lösen kann. Also NoSQL und nun? Wenn sich als Ergebnis einer ersten Analyse eine relationale Datenbank als eher ungeeignetes Werkzeug erweist, ist zwar ein erster Schritt getan, aber nun steht man vor der nächsten Entscheidung: Welche NoSQL- Familie ist die richtige? Auch hier hilft die Vielfalt der verschiedenen Ansätze weiter: Zunächst ist es sehr hilfreich, die Struktur der zu persistierenden Daten zu betrachten und sich zu vergegenwärtigen, wie auf diese zugegriffen werden muss. In vielen Fällen wird man dadurch schnell eine der oben beschriebenen Kategorien ausmachen, denn was liegt z.b. näher als eine Struktur, die sich durch einen Graphen abbilden lässt, auch in einer entsprechenden Graph DB zu speichern? Dies gilt vor allem, wenn sich die Operationen auf den Daten sehr gut durch Operationen auf dem Graphen umsetzen lassen. Dabei ist es wichtig, einen Trade-off zu beachten: Je komplizierter das Datenmodell, desto komplexer werden auch die umsetzenden Datenbanken und deren Skalierung. Wenn mal also mit einem simplen Key/Value-Store auskommen kann, so ist es unbedingt empfehlenswert, dies auch zu tun. Der letzte Schritt Im letzten Schritt muss noch zwischen den verschiedenen Vertretern einer Familie gewählt werden. An dieser Stelle gibt es eine Reihe von einfach prüfbaren Kriterien, die in vielen Fällen nur noch einen oder wenige ausgesuchte Kandidaten übrig lassen dürften: In vielen Organisationen können Technologien nur eingesetzt werden, wenn hierfür auch Support geboten wird. Bei einigen Open Source-Projekten ist dies noch nicht der Fall, weshalb diese dann keine Alternativen darstellen. Die meisten NoSQL-Projekte verwenden Lizenzen, die den Nutzern sehr weitgehende Rechte einräumen. Trotzdem ist natürlich im einzelnen zu prüfen, ob die rechtlichen Voraussetzungen für den Einsatz gegeben sind. Falls das Betriebssystem, auf dem die Datenbank installiert werden soll, nicht frei wählbar ist, kann es sich dabei um ein einfaches Ausschlusskriterium handeln: Während Linux kaum ein Problem darstellt, ist es durchaus möglich, dass einige der Kandidaten unter Windows oder seltener eingesetzten Unix- Varianten nicht unterstützt werden. Der Tool-Support ist ein weiteres Kriterium, das unter Umständen im ersten Moment vergessen wird, aber dennoch sehr relevant sein kann. So bieten die meisten der vorgestellten Datenbanken sehr guten Support für Backups, bei der Unterstützung von dynamischen Abfragen und der Rechteverwaltung gibt es aber deutliche Unterschiede. Ein starkes Argument kann auch der Vergleich des Einarbeitungsaufwandes sein. Finden Entwickler und Administratoren viele vertraute Technologien wieder oder sind die verwendeten Ansätze zum großen Teil fremd und damit der Einarbeitungsaufwand entsprechend hoch? Neben diesen Kriterien kann man natürlich noch viele weitere anführen, aber die erwähnten Punkte sind eine gute Unterstützung bei der ersten Orientierung in der wachsenden NoSQL-Welt. Zusammenfassung NoSQL ist ein Sammelbegriff, unter dem die verschiedenen nicht relationalen Datenbanksysteme versammelt werden. Jede von ihnen dient vornehmlich einem einzigen Zweck: eine hochspezialisierte Lösung für ein sehr spezifisches Problem bereitzustellen. Das bedeutet im Umkehrschluss, dass andererseits jeder Datenbanktyp in seinen Anwendungsmöglichkeiten limitiert ist, wenn man bei optimalen Lösungsansätzen bleibt und keine Kompromisse eingehen möchte. Wer sich die Mühe macht, seine Anforderungen genau zu analysieren und seine Möglichkeiten sorgfältig zu prüfen, wird mit einer idealen Persistenzlösung belohnt werden. Seite 8/9 NoSQL whitepaper

9 Die Autoren Carl Anders Düvel ist Consultant bei der Holisticon AG, dabei arbeitet er vor allem im JavaEE-, Spring- und Webprojekten. Er hat zusammen mit seinen Kollegen ein Buch über EJB 3.1 geschrieben und bloggt regelmäßig unter blog.holisticon.de und carlduevel.net. Enno Thieleke arbeitet als Berater bei der Holisticon AG. Als Architekt und Entwickler unterstützt er Unternehmen u.a. bei der Einführung und Umsetzung von Geschäftsprozessen und deckt dabei ein breites Spektrum von Technologien ab, wobei sein Schwerpunkt auf J2EE/JEE liegt. Kontakt Holisticon AG Griegstraße 75 / Haus Hamburg info@holisticon.de Seite 9/9 NoSQL whitepaper