Einführung in NoSQL- Datenbanken und deren - RWTH
Werbung
Einführung in NoSQLDatenbanken und deren Klassifizierung Seminararbeit im Studiengang Scientific Programming vorgelegt von Patrick Becker Matr.-Nr.: 836962 am 15. Dezember 2011 an der Fachhochschule Aachen 1. Betreuer: 2. Betreuer: Prof. Dr. rer. nat. Volker Sander Dipl.–Inf. Arne Rache Abstract 2 Abstract Diese Seminararbeit bietet einen Einstieg in die Welt von nicht relationalen Datenbanken. Neben der Definition des Begriffs „NoSQL“ und der Motivation für die Einführung von NoSQLDatenbanken, wird eine Klassifizierung dieser vorgestellt und die Eigenschaften der Datenbanken verschiedener Klassen werden näher erläutert. Hier liegt der Schwerpunkt bei den Core-NoSQL-Systemen. Außerdem werden eng mit NoSQL-Datenbanken verwandte Themen erläutert und teilweise anhand von Beispielen verdeutlicht. Dazu gehören: Map/Reduce, CAP-Theorem, BASE und Multiversion-Concurrency-Control Inhaltsverzeichnis 3 Inhaltsverzeichnis Abstract ........................................................................................................................................... 2 Inhaltsverzeichnis............................................................................................................................ 3 1.0 Einleitung und Motivation ..................................................................................................... 4 2.0 Grundlagen ............................................................................................................................ 6 3.0 Klassifizierung von NoSQL-Datenbanken ............................................................................ 12 3.1 Wide-Column-Stores / Column-Families........................................................................ 13 3.2 Document-Stores ........................................................................................................... 14 3.3 Key/Value - Store............................................................................................................ 15 3.4 Graphdatenbanken ........................................................................................................ 16 4.0 4.1 Verwandte Themen ............................................................................................................. 16 Map/Reduce ................................................................................................................... 17 4.1.1 Programmiermodell ................................................................................................ 17 4.1.2 Detailliertes Beispiel ............................................................................................... 19 4.2 CAP-Theorem ................................................................................................................. 21 4.3 Eventually Consistent / BASE ......................................................................................... 25 4.4 Multiversion Concurrency Control(MVCC) .................................................................... 27 5.0 Zusammenfassung und Fazit ............................................................................................... 28 6.0 Ausblick................................................................................................................................ 29 Literaturverzeichnis ...................................................................................................................... 30 Einleitung und Motivation 1.0 4 Einleitung und Motivation Laut einer IDC1-Studie beträgt die weltweit gespeicherte, genutzte, erstellte oder kopierte Datenmenge im Jahr 2011 1,8 Zettabyte (1,8 Billionen Gigabyte)[1]. Diese Datenmenge verdoppelt sich aktuell alle zwei Jahre[2]. Aber wie kommt es zu dem großen Datenwachstum? Die häufigste Aktivität von Internetnutzern ist das Nutzen von Blogs sowie Sozialen Netzwerken. Durch eine vermehrte Nutzung des mobilen Internets wird die Aktivität bei sozialen Netzwerken voraussichtlich noch weiter steigen[3]. Wie stark die Nutzerzahlen von Facebook in Deutschland steigen, zeigt eine Studie von Statista[4]. Vom Juli 2009 bis zum Juli 2011 stieg die Anzahl der Facebook-Nutzer in Deutschland von ungefähr 3,5 Millionen auf ungefähr 10 Millionen an. Insgesamt verwaltet Facebook die Daten von mehr als 800 Millionen aktiven Benutzern[5]. Die Benutzer erzeugen große Datenmengen, indem sie beispielsweise täglich Pinnwandeinträge schreiben, Fotos hochladen, Fotos mit Benutzerprofilen verlinken oder Spiele nutzen. Ein gutes Beispiel, wie schnell die Datenmenge in einem Unternehmen ansteigen kann, zeigt Twitter2. Im Juni 2011 wurden täglich 200 Millionen Tweets3 gesendet. Genau ein Jahr zuvor waren es täglich 65 Millionen Tweets[6]. Die Speicherung dieser Daten geschieht oft in einer Datenbank. Gerade in der Webentwicklung werden relationale Datenbanksysteme genutzt. Forrester Research berichtete in einer Studie im Juli 2008, dass SQL4-Datenbanken die meist genutzten Datenbanken sind[7]. Edgar F. Codd beschreibt in seinem Paper "A Relational Model of Data for Large Shared Data Banks"[8], dass Daten in Tabellen mit Spalten und Zeilen ohne größere Datenverluste repräsentiert werden können. Durch diese Tabellen wird ein Schema aufgebaut, in dem dann auch Relationen zwischen den einzelnen Daten abgebildet werden können. Solche relationalen Datenbanken implementieren teilweise das ACID (Atomicity, Consistency, Isolation und Durability) Prinzip 5. Durch dieses Prinzip wird für einen dauerhaften, konsistenten Datenbestandteil gesorgt und 1 International Data Corporation Twitter ist ein soziales Netzwerk für die Veröffentlichung von kurzen Textnachrichten 3 Tweets sind veröffentliche Kurznachrichten 4 Structured Query Language 5 Beispielsweise benutzen MylSAM und PostgreSQL keine echten ACID-Transaktionen 2 Einleitung und Motivation 5 somit eine hohe Sicherheit für die Datenbank bzw. ihre Daten geboten. Des Weiteren unterstützen RDBMS6 Ad-hoc-Queries mit SQL. Die Konsistenz spielt beispielsweise bei sicherheitskritischen Bankanwendungen eine wichtige Rolle. Allerdings gibt es für diese Sicherheit der Konsistenz Einbußen bei der Performance, da bei Zugriffen auf die Datenbank einige Sperren gesetzt werden. Durch das stetige Ansteigen der Datenmenge, werden die relationalen Datenbankmanagementsysteme schnell an ihre Grenzen gebracht. Nachträgliche Änderungen am Schema einer RDBMS führen in der Regel zu minutenlangen Verlangsamungen des Systems, da unter anderem Relationen reorganisiert und teilweise Indizes neu berechnet werden müssen. Aus den beschriebenen geänderten Anforderungen ergibt sich die Notwendigkeit eines alternativen Datenbank-Ansatzes. RDBMS sind für viele Firmen ein zentraler Bestandteil ihrer Software geworden, da sie viele Vorteile, wie zum Beispiel Constraints, Transaktionen und Locking, bieten. Außerdem können die Daten durch die standardisierte Abfragesprache SQL abgerufen werden. Dennoch wurde in den 80er Jahren nach weiteren Speichermöglichkeiten gesucht, da die objektorientierte Programmiersprachen begannen sich durchzusetzen. Die Abbildung von komplexen Datenstrukturen auf das relationale Modell in einfachen Zeilen und Spalten kann nicht immer leicht durchgeführt werden. Das Ergebnis kann unter Umständen eine große Anzahl an Tabellen sein, die untereinander noch viele Beziehungen haben können. Dieses Problem wird Impedance Mismatch genannt[9]. Objektorientierte Datenbanken versuchen dieses Problem aufzulösen und sind ein Teil der NoSQL-Bewegung. Systeme wie Lotus Notes und BerkeleyDB sind Vorreiter der heutigen NoSQL-Datenbanken. Mit dem Zeitalter des Web2.0 werden neue Herausforderungen an Datenbanksysteme gestellt. Die Performance und Skalierbarkeit stellt eine der wichtigsten Herausforderungen einer Datenbank dar. Denn Latenzzeiten spielen eine gravierende Rolle bei der Nutzerzufriedenheit, wie zum Beispiel im E-Commerce-Bereich. Von dem Nutzer werden schnelle Antwortzeiten der Systeme erwartet. Die Menge an zu verarbeitenden Daten steigt und es muss überlegt werden, wie das Rechensystem skaliert werden soll, um die Masse an Daten speichern zu können und die erwartete 6 Performance zu gewährleisten. Relationes Datenbankmanagementsystem Eine weitere Herausforderung ist die Grundlagen 6 Ausfallsicherheit eines Systems. Ein Anwendungsprogramm soll für Nutzer dauerhaft verfügbar sein. Ein System kann aufgrund defekter Hardware, defekter Software oder Aktualisierung des Systems ausfallen. Des Weiteren besteht eine Herausforderung darin, auf vordefinierte Datenbankschemata zu verzichten, um die Speicherung von semistrukturierten 7 Daten flexibler gestalten zu können. 90% der deutschen Internetnutzer nutzen das Internet für die Produktrecherche[10]. Aus diesem Grund ist die Performance und Verfügbarkeit einer Datenbank für viele Web-Anbieter von großer Bedeutung. Dafür wird eine horizontale Skalierung8 angestrebt, um eine gute Skalierbarkeit bei niedrigen Kosten zu erreichen[11]. Diese neuen Herausforderungen benötigen neue Datenbankarchitekturen. Relationale Datenbankansätze zur Bewältigung dieser Herausforderungen sind beispielsweise Oracle Real Application Cluster, welche eine SharedDisk-Architektur[12] realisieren. Eine weitere Möglichkeit bietet MySQL-Cluster, das auf einer Shared-Nothing-Architektur[13] basiert. Eine nicht relationale Lösung bieten NoSQLDatenbanken, die in den letzten Jahren an Bedeutung zugenommen haben. Diese Seminararbeit konzentriert sich auf NoSQL-Datenbanken und versucht,eine Einführung in dieses Themengebiet zu geben. 2.0 Grundlagen Der Begriff „NoSQL“gibt es bereits seit 1998. Carlo Strozzi nannte eine von ihm geschriebene Open-Source-Datenbank NoSQL, um zu verdeutlichen, dass seine Datenbank keine SQLSchnittstelle bereitstellt. Er verstand NoSQL als „no SQL“ (kein SQL). Seine Datenbank basiert zwar auf dem relationalen Datenbankmodell, stellt aber keine SQL-Schnittstelle zur Verfügung. Zu NoSQL schreibt Strozzi[14]: „ NoSQL has been around for more than a decade now and it has nothing to do with the newborn NoSQL Movement. While the former is a well-defined software package, is a relational database to all effects and just does intentionally not use SQL as a query language, the 7 Semistrukturierte Daten haben keine allgemeine Struktur und sind nicht streng typisiert. Ein Beispiel ist ein Dokument mit Text und Bilder. 8 Siehe Kapitel 2.0 Grundlagen unter dem Punkt „Verteilt und horizontal skaliert“ Grundlagen 7 newcomer is mostly a concept (and by no means a novel one either), which departs from the relational model altogether and it should therefore have been called more appropriately "NoREL", or something to that effect.” Das zugrunde liegende Konzept von NoSQL Datenbanken ist der Verzicht auf Relationen. Deshalb ist laut Stozzi die Bezeichnung „NoREL“ eher angebracht. Heutzutage spricht man trotzdem von NoSQL (Not only SQL). NoSQL sind Web-scale Datenbanken, die das Ziel haben, Datenmengen im Terabyte- oder sogar Peta-Bereich zu persistieren. Unstrukturierte Daten, beispielsweise Emails, Fotos, Videos und Volltexte, nehmen im Zeitalter von Web 2.0 sehr stark zu. Eine klare Definition für NoSQL Datenbanken gibt es nicht. Aber Prof. Dr. Edlich, der Betreiber der Webseite9 und Autor des Buches „NoSQL“[15], versucht NoSQL-Datenbanken folgendermaßen zu definieren: “NoSQL DEFINITION: Next Generation Databases mostly addressing some of the points: being non-relational, distributed, opensource and horizontally scalable. The original intention has been modern web-scale databases. The movement began early 2009 and is growing rapidly. Often more characteristics apply as: schema-free, easy replication support, simple API, eventually consistent /BASE (not ACID), a huge data amount, and more. So the misleading term "nosql" (the community now translates it mostly with "not only sql") should be seen as an alias to something like the definition above.” Laut dieser Definition ist eine NoSQL-Datenbank: 1. Nicht relational. 2. Verteilt und horizontal skaliert. 3. Open-Source. 4. Schemafrei oder hat nur schwache Schemaausprägungen. 5. Einfach bei der Datenreplikation. 6. Durch eine einfache Programmierschnittstelle leicht zu verwenden. 9 http://www.nosql-database.org Grundlagen 8 7. Nur eventuell konsistent, weil nicht das ACID-Prinzip, sondern das eventually consistent/ BASE – Prinzip angewandt wird. Im folgenden Abschnitt werden die Motivationen für die einzelnen Punkte erläutert. 1. Nicht alle Daten passen in ein vordefiniertes relationales Schema. Als Beispiel dienen im Folgenden Flugdaten von einem Flugzeug, welches von einem Flughafen A zu einem Flughafen B fliegt. Dieses Flugzeug kann direkt oder durch mehrere Flüge mit Zwischenlandungen von A nach B fliegen. Diese Flüge mit Zwischenlandungen werden nun als Segmente bezeichnet. Ein Flug kann also aus mindestens einem oder mehreren Segment/en bestehen, die in einer festen Reihenfolge stehen. Die Problematik besteht darin, diese Daten in einer Datenbank abzulegen. Eine Möglichkeit ist in der Abbildung1 dargestellt. Alle Daten eines Fluges, wie beispielsweise der Ankunfts- & Zielflughafen und die jeweiligen Segmente, in eine Tabelle zu speichern. Doch diese Darstellung ist nicht flexibel. Es kann der Fall eintreffen, dass irgendwann ein Flug n+1 Segmente enthält. Dann muss eine neue Spalte hinzugefügt werden. Außerdem müssen alle alten Werte angepasst werden. Abbildung 1 Flugtabelle Beispiel 1 Grundlagen 9 Eine weitere Möglichkeit wird in Abbildung 2 und Abbildung 3 dargestellt. Abbildung 2 Flugtabelle Beispiel 2 Teil 1 Abbildung 3 Flugtabelle Beispiel 2 Teil 2 Grundlagen 10 Für jedes Segment wird eine Tabelle angelegt. Diese Darstellung ist sehr komplex. Sollte ein Flug n+1 Segmente enthalten, muss eine weitere Tabelle angelegt werden. Um einen Flug vollständig darstellen zu können, müssen Join-Operationen über alle SegmentTabellen ausgeführt werden, die Performanceprobleme mit sich bringen. Dieses Datenbankmodell kann durch das Weglassen von Relationen einen Performancegewinn erzielen. 2. Dieser Punkt beschreibt die Serverarchitektur von NoSQL-Datenbanken. Um die enormen Datenmengen gut verwalten zu können, sind NoSQL-Datenbanken verteilte Datenbanksysteme. Solche Datenbanksysteme laufen auf mehreren Servern. Dadurch findet eine verteilte Speicherung der Daten statt. Des Weiteren wird die Infrastruktur horizontal skaliert. Es gibt zwei Arten von Skalierungsmöglichkeiten. Zum einen die vertikale Skalierbarkeit (Scale-up) und zum anderen die horizontale Skalierbarkeit (Scale-out). Scale-up bedeutet, dass die Hardware von dem bestehenden System immer weiter durch neue Hardware aufgerüstet wird. Unter Scale-out versteht man eine Erweiterung der Infrastruktur durch hinzufügen weiterer Server die dann mit der verteilten Datenbank vernetzt werden. Dadurch kann man schnelle Reaktionszeiten bei Anfragen und Manipulationen erreichen, da nicht immer nur ein System auf diese Anfragen reagiert. 3. Das Kriterium Open-Source ist für die technische Sicht eher von geringer Bedeutung und für einen Bestandteil der Definition von NoSQL fraglich. Googles Bigtable[16] und Amazons Dynamo[17] sind bekannte NoSQL-Datenbanken, die nicht Open-Source sind. Dieses Kriterium entstand, da den NoSQL-Datenbanken in den Jahren 1998 – 2008 kaum Beachtung geschenkt wurde und sich Firmen eher den teuren Datenbanksysteme zuwandten, die nicht immer die Ideallösung darstellten. Durch dieses Kriterium wird der Industrie ein leichter Zugang in die NoSQL-Welt ermöglicht und eine günstige Alternative zu den bekannten Datenbanken gezeigt. 4. Die Schemafreiheit oder nur schwächere Schemarestriktionen, ist eine Reaktion auf die immer agiler werdenden Web2.0-Anforderungen und Datenstrukturen. Eine nachträgliche Schemaanpassung bei relationalen Datenbanken kann unter Umständen Grundlagen 11 zu längeren Betriebsunterbrechungen führen und das darüber liegende Portal minutenoder gar stundenlang verlangsamen. Aus diesem Grund ist die Idee bei NoSQLDatenbanken, dass teilweise die darüber liegenden Anwendungen die Verantwortung über das Schema haben. Bei den Anwendungen können Schemaanpassungen einfacher sein. Zum Beispiel kann bei einem Objekt, welches gespeichert werden soll, einfach eine Variable im Sourcecode hinzugefügt werden, die dann in der Datenbank mit gespeichert wird. 5. Eine weitere Anforderung ist die Möglichkeit zur einfachen und schnellen Replikation der Daten. Die Replikation der Daten ist ein wichtiger Bestandteil von NoSQLDatenbanken, da die Daten auf unterschiedlichen Server(Knoten) gespeichert werden. Jeder Knoten kann jederzeit ausfallen, wodurch es zu Datenverluste kommen kann. Der Datenbestand muss schnell repliziert werden können, damit die Daten, trotz solcher Ausfälle, weiterhin verfügbar sind. 6. SQL ist durch viele Join-Operationen, Unterabfragen, ineinander geschachtelte SelectOperationen und rekursive Select-Operationen schwer überschaubar und komplex geworden. Das ist ein Grund, warum einige Programmierer eine einfacherere API fordern. Dieser Punkt ist in der Welt von NoSQL-Datenbanken noch ein Problem, da die einfachen APIs bei komplexen Abfragen einer Datenbank zurzeit Schwierigkeiten bereiten. Deshalb setzen einige Anbieter bei komplexen Abfragen auf die Map/ReduceTechnik. Aber ein Grund warum man auf SQL verzichtet ist, dass die Anzahl der Zugriffe auf Datenbanken immer weiter ansteigt. International Data Corporation beschreibt in ihrem Artikel „IDC: More mobile Internet users than PC users in the U.S. by 2015“[18], dass es im Jahr 2015 ca. 2.7 Milliarden Internetnutzer weltweit geben wird. Im Jahr 2010 waren es noch ca. 2 Milliarden Internetnutzer weltweit, die im Internet surfen, Einträge in Foren verfassen, Bilder hochladen, einen Blog schreiben und vieles mehr. Durch solche Aktivitäten werden bei relationalen Datenbanksystemen indirekt komplexe Datenbankabfragen ausgeführt, die die Portale ziemlich langsam machen können. Die Tabellen in diesen Systemen müssen immer wieder pro Benutzer neu kombiniert werden um den Nutzer umfassende Informationen liefern zu können. Die Klassifizierung von NoSQL-Datenbanken 12 Idee der NoSQL-Datenbanken ist, dass Daten als Ganzes gespeichert werden. Beispielsweise soll von einem Benutzer ein eindeutiger Benutzername, der Vor- und Nachname sowie sein Wohnort persistiert werden. Es könnte nun eine Tabelle „User“ mit den Spalten Accountname, Vorname, Nachname und Wohnort angelegt werden, wobei die letzten drei Spalten Fremdschlüssel sind, die auf andere Tabellen verweisen, da diese Daten möglicherweise redundant sein könnten. Bei NoSQL-Datenbanken werden jedoch pro Benutzer alle Daten komplett gespeichert, sodass eine redundante Datenspeicherung erfolgt. Somit werden unter anderem Join-Operationen vermieden. Die NoSQL-APIs werden dadurch einfacher als SQL. 7. Nicht alle Systeme benötigen die sicherheitskritischen Konsistenz- und Transaktionsanforderungen, wie sie beispielsweise bei Bankanwendungen wichtig sind. Solche Anforderungen werden typischer Weise nicht bei sozialen Netzwerken gebraucht. Zum Beispiel ist es unproblematisch, wenn eine einkommende Freundschaftsanfrage von einem Benutzer akzeptiert wird, aber die Bestätigung bei dem Absender dieser Freundschaftsanfrage erst einige Zeit später aktualisiert wird und nicht direkt unmittelbar nach der Bestätigung des Empfängers. Es wird also kein ACID benötigt, der für die Sicherheit und Konsistenz der Daten sorgt. Die Daten können also irgendwann konsistent sein. Es ist die Rede von Eventually Consistent. Einige NoSQLDatenbanken bieten allerdings ebenfalls ACID an. Es ist durchaus möglich, dass eine Option gewählt werden muss, die zum einen ACID oder zum anderen BASE sein kann. Außer BASE ist auch noch BASE-Derivate als das zugrunde liegende Konsistenzmodell möglich. Bei der Findung einer optimalen Datenbankist also eine Anforderungsanalyse von Nöten, die bestimmen soll, aus welchen Grund eine Datenbank eingesetzt wird und inwiefern die darin zu speichernde Daten konsistent sein müssen. 3.0 Klassifizierung von NoSQL-Datenbanken Zurzeit gibt es mehr als 120 NoSQL-Datenbanken. Aufgrund der großen Menge von NoSQLDatenbanken und grundsätzlich unterschiedlicher Ansätze, bietet sich eine Klassifizierung[19] Klassifizierung von NoSQL-Datenbanken 13 an. Es gibt zum einen die Core-NoSQL-Systeme und zum anderen die Soft-NoSQL-Systeme. Diese beiden Gruppen wurden jeweils noch in Untergruppen eingeordnet. Core-NoSQL-Systeme: - Wide-Column-Store / Column-Families - Document-Stores - Key-Value-Store / Tuple-Store - Graph-Databases Soft-NoSQL-Systeme: - Object-Databases - Grid& Cloud-Database-Solutions - XML- Databases - Multivalue Databases - etc. Die meisten Core-NoSQL-Systeme entstanden aus den Web2.0-Anforderungen, während die Soft-NoSQL-Systeme nicht aus diesen Anforderungen entstanden sind. Dennoch verfolgen sie einen nicht relationalen Ansatz. In diesem Seminar werden nur auf die Core-NoSQL-Systeme eingegangen, da diese aktuell die größere Bedeutung haben. 3.1 Wide-Column-Stores / Column-Families Wide-Column-Stores sind spaltenorientierte Datenbanksysteme. Diese stehen im Gegensatz zu relationalen Datenbanken, die Daten in Zeilen speichern. Column-Family ist eine Gruppe von mehreren Spalten, die ähnliche Daten speichern. Eine Column-Family kann aus Hunderten oder gar Millionen Spalten bestehen. Aus diesem Grund werden diese Datenbanken auch WideColumn-Stores genannt. Datenbanken speichern Tabellen intern auf der Festplatte in einer eindimensionalen Folge von Bytes. Im folgenden Beispiel ist die gewählte Darstellung aufgrund einer besseren Illustration stark vereinfacht. In der Praxis werden die Daten auch in einer Folge auf der Platte abgelegt. Dies ist aber abhängig von der Datenbank und dem genutzten Dateisystem. Klassifizierung von NoSQL-Datenbanken 14 Abbildung 4 Flugtabelle Bei der zeilenorientierte Datenbank werden die Daten aneinander gereiht: Abbildung 5 Zeilenorientierte Speicherung Bei den spaltenorientierten Datenbanken wird Spalte für Spalte vorgegangen: Abbildung 6 Spaltenorientierte Speicherung Die spaltenorientierte Speicherung hat Vorteile bei der Analyse der Daten, wie zum Beispiel dem Berechnen einer Aggregatfunktion. Heise Open Source beschreibt den Vorteil durch ein Karteisystem[20]. Jeder Zeileneintrag bei relationalen Datenbanken wird auf einer Karte geschrieben. Für den Durchschnittspreis aller Flüge müssen dann alle Karten angeschaut werden und die Preise summiert werden. Effizienter ist es, wenn alle Preise auf einer Karte stehen und diese Preise nur summiert werden müssen. So gehen spaltenorientierte Datenbanken vor. Das ist ein Grund, warum diese Datenbanken bei Analyse-Programmen, wie zum Beispiel Data-Warehouse-Anwendungen, eingesetzt werden. Vertreter dieser Sorte von NoSQL-Datenbanken sind zum Beispiel: Cassandra, HBase, Amazon SimpleDB und Hypertable. 3.2 Document-Stores Die zugrunde liegende Idee der Document-Stores ist es, zusammengehörige Daten auch strukturiert in einem Dokument zusammen zu speichern. Die Dokumente werden in der Klassifizierung von NoSQL-Datenbanken 15 Datenbank mit einer Identifikationsnummer versehen, damit auf die Dokumente eindeutig zugegriffen werden kann. Bei relationalen Datenbanken werden Daten getrennt in Form von Tabellen gespeichert. Jede Tabelle speichert meistens nur eine Art von Daten. Tabellen müssen also kombiniert werden, um zusammengehörige Daten darzustellen. Den Ursprung haben Document-Stores in Lotus Notes von IBM, welches ein dokumentenorientiertes, verteiltes Datenbanksystem ist und bereits 1984 entwickelt wurde. Die Dokumente, die diese Datenbank speichert, sind strukturierte Zusammenfassungen von Informationen, wie JSON10, YAML11, RDF12 oder XML13-Dokumente. Daten können redundant vorliegen, da mehrere Dokumente gleiche Schlüssel mit gleichen Werten beinhalten können. Die Struktur der Daten kann unterschiedlich sein. Ein Schema, das die Repräsentation der Daten innerhalb eines Dokuments beschreibt, gibt es nicht. Bei Document-Stores liegt die Verantwortung der Schemata nicht mehr bei der Datenbank, sondern bei den Anwendungen. Alle Dokumente können gleiche oder unterschiedliche Schlüssel mit beliebigen Werten besitzen. Durch diese starke Schemafreiheit ist eine große Gestaltungsfreiheit möglich. Deshalb müssen Prüfungsmechanismen im Anwendungsprogramm implementiert werden. Relationen zwischen den Dokumenten können nicht abgebildet werden, da jedes Dokument individuelle Daten beinhaltet und das Schema unbekannt ist. Die bekanntesten Vertreter sind Lotus Notes, ChouchDB und MongoDB. 3.3 Key/Value - Store Die Key/Value-Store Datenbanken gehören zu den ältesten Datenbanken und werden seit den 70er Jahren angewendet. Ein Key/Value-System bietet die Zuordnung eines Werts14 zu einem Schlüssel15. Der Wert kann ein strukturierter oder unstrukturierter Datensatz sein. Die Schlüssel können in Namensräumen und Datenbanken gruppiert werden. Der Wert muss nicht zwingend ein String sein. Listen und Mengen sind beispielsweise ebenfalls möglich. Dieses leichte Datenmodell bietet in einigen Anwendungsfällen eine schnellere und effizientere Datenverwaltung als relationale Datenbanken. Die Abfrage von Daten geschieht über den 10 JavaScript-Object-Notation Yet-another-Markup-Language 12 Resource Description Framework 13 Extensible-Markup-Language 14 Englische Übersetzung: „Value“ 15 Englische Übersetzung: „Key“ 11 Verwandte Themen 16 Schlüssel, was nur eine eingeschränkte Abfragemöglichkeit bietet. Bekannte Vertreter sind Redis, Riak und Membase. 3.4 Graphdatenbanken Graphdatenbanken basieren auf dem Graphenmodell, welches aus einer Menge von Knoten und einer Menge von Kanten besteht. Die Kanten verbinden einzelne Knoten. Dadurch können Relationen dargestellt werden. Das Ziel von Graphdatenbanken ist eine einfache und effiziente Traversierung zu bieten, die bei relationalen Datenbanken nur durch intensive Join-Operationen erreichbar sind. Einige Anbieter bieten unterschiedliche Graph-Datenbanken-Modelle, wie zum Beispiel das „einfache Graph-Modell“, das „Property-Graph-Modell“ oder das „HypergraphModell“, an. Des Weiteren ist es wichtig, auf die Größe des Graphen zu achten. Sollte dieser zu groß werden, muss der Graph entsprechend partitioniert, also in Teilgraphen getrennt werden. Die bekanntesten Skalierungsarten sind Replikation- und Partitionierung eines Graphen. Typische Vertreter dieser Datenbank sind Neo4j, HyperGraphDB, DEX, InfiniteGraph, Sones GraphDB und noch viele mehr. 4.0 Verwandte Themen Das Thema NoSQL umfasst viele Ideen und Technologien, die in dieser Seminararbeit nicht alle behandelt werden können. Aus diesem Grund werden im Folgenden ausgewählte Themen vorgeführt. Diese Themen sind: 1. 2. 3. 4. Map/Reduce-Verfahren CAP-Theorem Eventually Consistency/BASE Multiversion Concurrency Control Weitere wichtige Themen, die hier nicht behandelt werden, da sie den Umfang der Seminararbeit sprengen würden, sind: 1. 2. 3. 4. Consistent Hashing Vector Clocks Paxos REST Verwandte Themen 4.1 17 Map/Reduce Map/Reduce[21] stellt sich der Herausforderung der effizienten Verarbeitung großer Datenmengen im Größenbereich von mehreren Terabytes bis hin zu vielen Petabytes. Das Map/Reduce-Framework wurde von Google implementiert, um große Datenmengen, in einem Ethernet-Netzwerk mit Standard-Personal-Computern, verarbeiten zu können. Google hat sich von den beiden Funktionen Map und Reduce aus der funktionalen Programmierung inspirieren lassen. 4.1.1 Programmiermodell Das Map/Reduce-Framework erstellt aus einer Eingabeliste, die aus Schlüssel/Wert-Paaren besteht, eine Ausgabeliste, die ebenfalls aus Schlüssel/Wert-Paaren besteht. Die zu verarbeitenden Daten werden in kleinere Blöcke aufgeteilt, die anschließend parallel bearbeitet werden können. Während des Map/Reduce-Verfahrens werden aus den einzelnen Blöcken Zwischenergebnisse erzeugt, die am Ende des Verfahrens zu einem Endergebnis zusammengeführt und an den Benutzer zurückgegeben werden. Map/Reduce besteht aus zwei grundlegende Funktionen, der Map- und der Reduce-Funktion, die auf den Rechnern eines Clusters jeweils parallel ausgeführt werden können. Die Arbeitsweise eines Map/ReduceVerfahrens kann in fünf wichtige Phasen eingeteilt werden: Verwandte Themen 18 Abbildung 7 Map/Reduce-Verfahren[22] In der ersten Phase werden die Eingabedaten in gleich große Blöcke aufgeteilt. Diese Blöcke werden Schlüssel zugeordnet. Dadurch erhält man Schlüssel/Wert-Paare. Eine Liste dieser Paare wird dann der zweiten Phase, der Map-Phase, übergeben[21]: Eingabedaten list(key1,value1). In der Map-Phase wird für jedes Schlüssel/Wert-Paar der Liste die vom Nutzer geschriebene Map-Funktion aufgerufen, die eine neue Zwischenliste erstellt, die ebenfalls aus Schlüssel/Wert-Paaren besteht. Schlüssel können in dieser Liste auch mehrfach vorkommen. Mehrere Map-Funktionen können parallel ausgeführt werden: map(key1, value1)list(key2,value2). Die dritte Phase ist die Shuffle-Phase. Die Ergebnislisten der Map-Funktion werden für die Reduce-Phase aufbereitet. Alle Tupel der Zwischenliste werden geprüft und die Werte gleichwertiger Schlüssel (hier key2) zusammengefasst. Da alle Werte, mit dem gleichen Verwandte Themen 19 Schlüssel, gruppiert werden, ist jeder Schlüssel nur noch einmal vorhanden und dadurch eindeutig. Diese Tupel werden dann an die Reduce-Phase übergeben werden: list(key2, value2) (key2, list(value2)). Die Reduce-Phase ist die vierte Phase und berechnet die Zwischenergebnisse in eine Liste von Ergebniswerten: (key2,list(value2)) list(value3). In der letzten Phase werden den Ergebniswerten ihre Schlüssel wieder zugeordnet und dem Benutzer zurückgegeben: list(value3) list(value3, key2). Auf diesen Phasen basiert das Map/Reduce-Verfahren und so wurde es auch von Google in ihrem Map/Reduce-Framework realisiert. Hadoop[23] ist ein Open-Source-Map/ReduceFramework und basiert auf dem Framework von Google. Der Anwender muss die Logik der Map- und Reduce-Funktion selbst erstellen. Alle weitere Phasen des Map/Reduce-Verfahren, wie die Verteilung der Daten, Parallelisierung der Prozesse, Handling bei Ausfall der Hard- oder Software, Aufruf der Map- und Reduce-Funktionen, Speichern der Zwischenergebnisse und Endergebnisse werden vom Map/Reduce-Framework ausgeführt. Das Map/Reduce-Verfahren spielt bei den verteilten Datenbanken eine wichtige Rolle bei der Verarbeitung großer Datenmengen. Mit diesem Verfahren lassen sich diese Datenmengen effizient durch parallele Ausführungen verarbeiten. Implementierungen des Map/ReduceVerfahrens existieren beispielsweise in den NoSQL-Datenbanken CouchDB, Riak, MongoDB und HBase. 4.1.2 Detailliertes Beispiel Die Arbeitsweise von Map/Reduce wird im Folgenden anhand eines Beispiels genauer dargestellt. Es wird der höchste Super Benzinpreis aus mehreren Monaten bei unterschiedlichen Tankstellen gesucht. Die gespeicherten Daten einer Tankstelle können zum Verwandte Themen 20 Beispiel der Name und Standort der Tankstelle enthalten, sowie der höchste Super Benzinpreis eines bestimmten Monats. Abbildung 8 Map/Reduce-Verfahren Ein Datensatz aus der Abbildung 8 setzt sich wie folgt zusammen: (ARAL,52459,01,1509...) ARAL ist der Name der Tankstelle. 52459 ist die Postleitzahl des Standortes der Tankstelle und 01 ist der Monat. In diesem Monat lag an einem bestimmten Tag der höchste Super Benzinpreis pro Liter bei 1509 Cent. Die Punkte deuten darauf hin, dass noch weitere Daten in diesem Datensatz stehen könnten. In der ersten Phase werden die Daten in Blöcke eingeteilt und einem Schlüssel zugeordnet, der sich in diesem Fall aus den Namen der Tankstelle zusammensetzt. Danach beginnt die zweite Phase, die Map-Phase. In der Map-Phase werden aus den Schlüssel/Wert-Paaren die höchsten Preise pro Tupel gefiltert und wieder als Schlüssel/Wert-Paar gespeichert. Nachdem alle Map-Berechnungen abgeschlossen sind, beginnt die Shuffle-Phase. In dieser wird jeder Tankstelle eine Liste von Preisen zugeordnet und zwischengespeichert. Ist die Shuffle-Phase beendet, wurde für jede Tankstelle eine Liste mit Preisen erstellt. Gibt es n unterschiedliche Tankstellen, dann gibt es n Zwischenlisten. In der Reduce-Phase wird dann der höchste Preis für jede Tankstelle ermittelt. In der letzten Phase werden dann den Höchstpreisen wieder ihre Schlüssel zugeordnet und dem Benutzer zurückgegeben. Verwandte Themen 21 Es gibt viele verschiedene Implementierungen des Map/Reduce-Verfahrens. Die Art der Implementierung ist abhängig vom Anwendungsbereich. Es gibt noch viele weitere Anwendungsbereiche[24][25]. Zwei Beispiele sind: 1. Zählen von Zugriffen auf eine URL: Die Map-Funktion verarbeitet aus vorhandenen Aufzeichnungen die Zugriffe auf Webseiten. Die Schlüssel/Wert-Paare sind dann nach der Map-Phase jeweils (URL, 1) pro Zugriff auf eine URL. Die Reduce-Phase addiert dann die Einsen pro URL und liefert dann das Endergebnis (URL, numberOfClicks). 2. Gleiche Wörter in einem Text zählen: Die Map-Funktion erfasst alle Wörter in einem Dokument. Die Schlüssel/Wert-Paare nach der Map-Phase sind (Wort, 1), jeweils für jedes Vorkommen. In der Shuffle-Phase werden dann die die Einsen pro Wort in einer Liste mit den Tupeln (Wort, [1,…,1]) gespeichert. Die Reduce-Phase addiert dann alle Einsen zusammen und das Ergebnis ist dann die Anzahl der Vorkommen des Wortes (Wort, Anzahl). 4.2 CAP-Theorem Das Akronym CAP steht für Consistency, Availability und Partition Tolerance und ist auch bekannt als das Brewers-Theorem. Dieses Theorem war eine Vermutung von Prof. Eric A. Brewer und wurde im Jahr 2000 in einem Vortrag auf dem ACM16-Symposium über „Priciples of Destributed Computing“ vorgetragen[26][27]. Seth Gilbert und Nancy Lynch haben dieses Theorem später axiomatisch bewiesen. Brewer versuchte zu verdeutlichen, warum die Vereinbarkeit von Konsistenz, Verfügbarkeit und Ausfalltoleranz nicht erreichbar ist. Seine wichtigste Erkenntnis ist, dass bei verteilten Systemen nur zwei von den drei genannten Eigenschaften gleichzeitig zu erreichen sind. 16 Association for Computing Machinery Verwandte Themen 22 Abbildung 9 CAP-Theorem[28] Consistency (Konsistenz): Alle Clients sehen zur selben Zeit auch die gleichen Daten. Die Daten befinden sich nach dem Ablauf einer Transaktion in einem konsistenten Zustand. Das bedeutet, dass darauf folgende Lesezugriffe auf einen beliebigen Knoten den aktuellen Wert zurückgeben. Availability (Verfügbarkeit): Ein System muss in einer vorher fest definierten Reaktionszeit reagieren können. Anfragen von Clients an das System müssen jederzeit beantwortet werden können. Die Reaktionszeiten des Systems müssen schnell sein. Das Internet wird immer mehr zum Vertriebsort. „97 Prozent der deutschen Internetnutzer kaufen online ein“[28]. Laut ECC17 ist ein Grund, warum kaufwillige Kunden eine E-Commerce-Anwendung verlassen, dass sie wegen zu langer Ladezeiten warten müssen. 17 E-Commerce-Center Handel Verwandte Themen 23 Partition Tolerance (Ausfalltoleranz): Das Gesamtsystem muss bei Ausfall einzelner Kommunikationsverbindungen weiterhin laufen können und auf weitere einkommende Anfragen reagieren können. Solche Ausfälle können beispielsweise durch Wartungsarbeiten oder durch das Wechseln alter Hardware sowie durch defekte Hardware oder durch Softwarefehler entstehen. Damit das System weiterhin laufen kann, müssen die zu verwaltenden Daten auf verschiedene Serverrepliziert werden. Warum nur zwei von den drei Eigenschaften bei verteilten Systemen zu erreichen sind, wird nun anhand eines Beispiels verdeutlicht. Wenn die Verfügbarkeit und die Ausfalltoleranz im Vordergrund stehen sollen, ist es nicht möglich die Konsistenz dauerhaft zu gewährleisten (AP). Ein verteiltes System kann beispielsweise aus den Knoten K1 und K2 bestehen, die Blogeinträge speichern. Diese Blogeinträge können manipuliert werden, indem ein vorhandener Blogeintrag editiert, gelöscht oder kommentiert wird. Es können auch neue Blogeinträge hinzugefügt werden.K1 soll für die Manipulation der Daten und K2 soll für Lesezugriffe zuständig sein. Beide Knoten speichern die gleichen Blogeinträge und haben zu Beginn den Datenzustand B0. Abbildung 10 CAP-Theorem Beispiel Wenn nach einer Transaktion eine Datenmanipulation bei K1 stattgefunden hat, werden die Daten auf K2 durch einen Synchronisationsmechanismus M auf den aktuellen Stand gebracht. Ein Benutzer fügt zum Beispiel einen neuen Blogeintrag hinzu und ändert dadurch den Datenzustand auf K1 von B0 auf B1. K2 wird durch M auf den aktuellen Datenzustand B1 gebracht, damit die darauf folgenden Lesezugriffe auf K2 die aktuellen Blogeinträge liefern. Verwandte Themen 24 Abbildung 11 CAP-Theorem mit Synchronisation Nun kann es vorkommen, dass die Netzwerkverbindung zwischen K1 und K2 getrennt wurde und die Kommunikation untereinander nicht mehr möglich ist. Ein weiterer Benutzer kommentiert einen Blogeintrag und ändert dadurch den Datenzustand auf K1 von B1 auf B2. Der Synchronisationsmechanismus zwischen K1 und K2 ist nicht möglich. Die Daten sind inkonsistent. Wenn nun ein Lesezugriff auf K2 stattfindet, wird dieser den Datenzustand B1 zurückliefern. Abbildung 12 CAP-Theorem ohne Synchronisation Die Konsistenz kann nicht gewährleistet werden. Wenn die Konsistenz eingehalten werden soll gilt eine Transaktion, die Daten manipuliert, erst als abgeschlossen, wenn alle anderen Knoten synchronisiert wurden. Die Unterbrechung der Kommunikation zwischen K1 und K2 führt dazu, dass das System ausfällt, weil K1 blockiert. K1 ist also nicht mehr Verfügbar und kann auf keine weiteren Schreibzugriffe reagieren. In dem Beispiel soll die Verfügbarkeit aber gewährleistet sein. Deshalb darf das System nicht aufgrund der Konsistenzeinhaltung blockieren. Inkonsistente Daten müssen also akzeptiert werden. Vor der Festlegung welche Datenbank eingesetzt werden soll, ist es daher wichtig, dass die zu speichernden Daten und das Verwandte Themen 25 Anwendungsgebiet auf die Notwendigkeit einer Konsistenzeinhaltung überprüft werden müssen. 4.3 Eventually Consistent / BASE Im Kapitel 5.2 wurde die Schlussfolgerung des CAP-Theorems erläutert, welche sagt, dass bei verteilten Systemen nur zwei von den drei Eigenschaften Konsistenz, Verfügbarkeit und Ausfalltoleranz, ausgewählt werden können. Fall sein System hoch verfügbar und ausfalltolerant sein soll, wurde gezeigt, dass die Einhaltung der Konsistenz nicht möglich ist und gespeicherte Daten nicht gezwungenermaßen konsistent sind. Eventually Consistent ist die Gegenseite der strikten Konsistenzeinhaltung, die bei relationalen Datenbanken gewährleistet ist. Es ist eine Unterkategorie von Weak-Consistency18. Es kann also der Fall sein, dass nicht alle Benutzer zu gleichen Zeit auch die gleichen Daten sehen. Benutzer befinden sich dann in einem Zeitfenster der Inkonsistenz19. Dieses Konsistenzmodell beschreibt, dass sich Daten irgendwann in einem konsistenten Zustand befinden. Bis die Datenbank in einen konsistenten Zustand überführt wurde, befinden sich die Daten in einem inkonsistenten Zustand. Die Konsistenz ist also nach einer Transaktion kein fester Zustand mehr, sondern ein Übergangsprozess. Diese neue Sicht des Konsistenzbegriffs stammt aus den Anforderungen der steigenden Anzahl von Internetnutzern, der gleichzeitig wachsenden Datenmenge und der Anforderung an schneller Reaktionszeiten der Systeme, die diese Daten verarbeiten. Realisiert werden diese Aufgaben durch verteilte Datenbanken, für die ja das CAP-Theorem gilt. ACID ist bei relationalen Datenbanken für die Einhaltung der Konsistenz zuständig. Das Modell BASE (Basically Available, Soft State, Eventually Consistent) verwirklicht Eventually Consistent und setzt auf die Verfügbarkeit des Systems. Durch das Konzept Multiversion Concurrency Control (MVCC) versucht BASE Sperrungen zu vermeiden, um dadurch die Verfügbarkeit zu gewährleisten. Es existieren auch andere Ansätze für BASE-Lösungen: Causal Consistency: Dieses Konsistenzmodell ist mit dem Konsistenzmodell der relationalen Datenbanksysteme ACID vergleichbar. Kausal Abhängig bedeutet, dass beispielsweise ein Prozess A einen beliebigen Wert X in eine Datenbank schreibt und ein Prozess B den Wert X 18 Strong-Consistency und Weak-Consistency sind die beiden Grundformen der Konsistenz Inconcistency-Window 19 Verwandte Themen 26 ausliest und dann einen Wert Y in die Datenbank schreibt. Prozess B ist vom Wert X abhängig um Y schreiben zu können. Ob Prozess B den Wert X für eine Vorberechnung nutzt oder nicht ist unwichtig. Causal Consistency „(…) ist bei Transaktionen in verteilten DB-Systemen gegeben, wenn auch bei sehr enger zeitlicher Nähe der Prozesse A und B auf allen replizierten Knoten sichergestellt ist, dass B den von A geschriebenen Wert X liest bevor Y geschrieben wird.”20 Read-your-write Consistency: Wenn ein Prozess einen Datensatz in der Datenbank geändert hat, werden seine nachfolgenden Zugriffe immer nur die von ihm geänderte Version des Datensatzes zurückgeben. Der Prozess bekommt dadurch keine älteren Versionen des Datensatzes und sieht nur seine Änderungen. Read-your-write Consistency ist ein Spezialfall von Causal Consistency. Session Consistency: Jeder Prozess bekommt eine Session. Während dieser Session wird dem Prozess Read-your-write Consistency garantiert. Es werden so lange eigene Manipulationen der Datensätze gesehen, wie die Session anhält. Monotonic Read Consistency: Wenn ein Prozess einen Datensatz gelesen hat, dann wird er bei jedem weiteren Zugriff auf den Datensatz immer den gleichen Wert bekommen. Monotonic Write Consistency: Alle Schreiboperationen werden in der Reihenfolge ausgeführt, wie Prozesse sie abgeschickt haben. Wenn ein System diese Eigenschaft nicht erfüllt, ist unklar in welchem Zustand sich ein manipulierter Datensatz befindet, der in zeitlich kurzen Abständen durch mehrere Schreiboperationen geändert wurde. Diese vier Eigenschaften zeigen bei dem Einsatz von NoSQL-Datenbanken, dass eine intensivere Datenanalyse notwendig und auf Konsistenzeigenschaften zu prüfen ist. Außerdem zeigen sie, wann bei einer NoSQL-Datenbank eher mit ACID-Ähnlichen Konsistenz oder mit Eventually Consistency zu rechnen ist. 20 http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/BASE Verwandte Themen 4.4 27 Multiversion Concurrency Control(MVCC) Eine Aufgabe der relationalen Datenbanken ist es, die zu persistierenden Daten korrekt in der Datenbank abzulegen. Dafür sorgt die semantische Integrität, wie zum Beispiel Anforderungen an den zu speicherden Daten, so genannte „Constraints“. Auch die Konsistenz der Daten muss gesichert sein, wenn ein Datensatz gleichzeitig von mehreren Anwendern manipuliert wird. Bei relationalen Datenbanken ist bei diesem Fall die klassische Vorgehensweise das Sperren von Datensätzen. Wird bei einer Datenbank eine Transaktion bearbeitet, die auf einen bestimmten Datensatz operiert, erhalten alle anderen einkommenden Lese- oder Schreiboperationen, die ebenfalls auf den gleichen Datensatz zugreifen müssen, eine Sperrung. Wenn die bearbeitete Transaktion abgeschlossen ist, kann die nächste Transaktion abgearbeitet werden. Um eine Datenmenge im Tera- und Peta-Byte-Bereich verwalten zu können, werden die Datenbanken auf verteilte Systeme mit mehreren hundert Servern ausgeführt. Die Kommunikationskosten zwischen Servern sind beim häufigen Setzen und Aufheben der Sperre hoch. Ebenfalls sind bei gesperrten Datensätzen nebenläufige Leseoperationen nicht möglich. Das führt bei den Benutzern zu Wartezeiten. Multiversion Concurrency Control (MVCC) bietet eine andere Lösung, die keine Sperrung bei gleichzeitigen Zugriffen auf einen Datensatz durchführt. Bei MVCC werden durch Datenmanipulationen (Hinzufügen, Ändern, Löschen eines Datensatzes) Versionen des Datensatzes erstellt. Zum Beispiel wird beim Ändern eines Datensatzes ein neuer Datensatz erstellt, der die geänderten Werte des ursprünglichen Datensatzes enthält. Des Weiteren wird der neue Datensatz mit einer Versionsnummer versehen. Die Datensätze liegen also in unterschiedlichen Versionen vor. Außerdem verweist der neue Datensatz auf seinen Vorgänger, siehe Abbildung13. Abbildung 13 Versionierung der Daten Schreibvorgänge blockieren nicht mehr nebenläufige Operationen. Leseoperationen warten nicht mehr, bis bei einer Schreiboperation der neue Wert in die Datenbank geschrieben wurde. Zusammenfassung und Fazit 28 Stattdessen wird der zu lesende Datensatz in einer älteren Version zurückgegeben. Konkurrierende parallele Schreibzugriffe werden frühzeitig erkannt und behandelt. Bei Transaktionsende einer Schreiboperation wird die aktuelle Version eines Datensatzes mit der Vorgängerversion des gerade angelegten Datensatzes verglichen. Nun können zwei Fälle eintreten. Im ersten Fall sind beide Versionsnummern identisch. Dann können die Änderungen in einem neuen Datensatz gespeichert und auf den Vorgänger verwiesen werden. Im zweiten Fall ist die Vorgänger-Versionsnummer des neu angelegten Datensatzes größer, als die aktuelle Versionsnummer. In diesem Fall liegt ein Konflikt vor und die Transaktion muss wiederholt werden. In regelmäßigen Abständen werden alte Datensatzversionen, wenn diese nicht mehr von Transaktionen benötigt werden, dauerhaft vom System entfernt. Das Löschen dieser alten Datensätze ist Notwendig, da sonst sehr viel Speichplatz verbraucht wird, der nicht mehr abgefragt wird. Als Versionsnummer können unterschiedliche Einträge dienen, wie zum Beispiel: eine fortlaufende Transaktionsnummer, der Zeitpunkt der Datenmanipulation oder der Transaktionsstartzeitpunkt. Wichtig ist, dass diese Versionsnummern streng monoton sind. 5.0 Zusammenfassung und Fazit In dieser Seminararbeit wurde gezeigt, dass neue Anforderungen an Datenbanken gestellt werden. Das weltweite Datenvolumen steigt immer weiter an und immer mehr Menschen erhalten einen Internetzugang. Gleichzeitig erzeugen diese immer mehr strukturierte, semistrukturierte und unstrukturierte Daten. Relationale Datenbanken werden dadurch schnell an ihre Grenzen gebracht. Es gibt grundsätzlich unterschiedliche Realisierungen von NoSQLDatenbanken Dies führte zu einer Klassifizierung der NoSQL-Datenbanken. Dabei unterscheidet man Wide-Column-Stores, Document-Stores, Key/Value-Stores und Graphdatenbanken. Die jeweiligen Klassen mit ihren Eigenschaften wurden im Kapitel 3.0 beschrieben. In dieser Seminararbeit wurde nur ein Teil der NoSQL-Technologien erklärt. Eine zentrale Rolle spielt die Map/Reduce-Technologie. Mit dem Map/Reduce-Verfahren lassen sich große Datenmengen, die in einem verteilten System gespeichert sind, parallel auf allen Servern effizient durchsuchen. Eventually-Consistent bzw. BASE zeigt, dass sich die Daten in einer Datenbank nicht immer in einem konsistenten Zustand befinden müssen. Die Konsistenz ist Ausblick 29 kein fester Zustand mehr, sondern ein Übergangsprozess. Das Multiversion-ConcurrencyControl Konzept sorgt dafür, dass eine Datenbank erreichbar bleibt, obwohl sich die Daten in einem inkonsistenten Zustand befinden. Außerdem werden bei gleichzeitigen SchreibOperationen keine Lese-Operationen auf denselben Datensatz blockiert. Das CAP-Theorem hat herausgestellt, dass bei verteilten Systemen nur zwei der drei EigenschaftenKonsistenz, Verfügbarkeit und Ausfalltoleranz erreicht werden können und somit ein Kompromiss eingegangen werden muss. Diese Arbeit soll verdeutlichen, dass bei der Wahl einer passenden Datenbank eine Analyse der zu speichernden Daten stattfinden muss. 6.0 Ausblick NoSQL gewinnt eine immer größere Bedeutung. Das zeigt sich auch daran, dass sehr viele große Unternehmen Gebrauch von NoSQL-Datenbanken machen. Darunter zählen Unternehmen wie Facebook, Twitter, Google, YouTube, Amazon, BBC, Canonical und viele mehr. Auch Microsoft möchte NoSQL-Datenbanken in ihrem Cloud-Dienst Aszure einbinden[30]. Das Münchener IT-Dienstleistungsunternehmen Consol sieht NoSQL-Datenbanken als einen geheimen Trend im Jahr 2011 und ist davon überzeugt, dass diese Datenbanken immer mehr an Bedeutung gewinnen werden[31]. Leider konnten einige Themen im Zusammenhang mit NoSQL-Datenbanken in dieser Arbeit nicht beschrieben werden, da sie den Umfang dieser Arbeit sprengen würden. Weitere wichtige Themen sind unter anderem: Consistent-Hashing, Vector Clocks, Paxos, REST und Cloud Computing. Ein weiteres Thema, welches in der Zukunft der NoSQL-Datenbanken eine große Rolle spielen könnte, ist UnQL. UnQL steht für Unstructed Data Query Language und ist eine Abfragesprache für NoSQL-Datenbanken. Die Syntax soll der von SQL ähnlich sein und wird von den Entwicklern von SQLite und CouchDB entwickelt[32]. Literaturverzeichnis 30 Literaturverzeichnis [1] „EMC,“ [Online]. Available: http://germany.emc.com/leadership/programs/digital-universe.htm. [Zugriff am 14 12 2011]. [2] „CIO,“ [Online]. Available: http://www.cio.de/dynamicit/bestpractice/2281581. [Zugriff am 14 12 2001]. [3] „TNS-Infratest,“ [Online]. Available: http://www.tns-infratest.com/presse/presseinformation.asp?prID=769. [Zugriff am 14 12 2011]. [4] „Stastita,“ [Online]. Available: http://de.statista.com/statistik/daten/studie/70189/umfrage/nutzer-vonfacebook-in-deutschland-seit-2009/. [Zugriff am 14 12 2011]. [5] „Facebook,“ [Online]. Available: http://www.facebook.com/press/info.php?statistics. [Zugriff am 14 12 2011]. [6] „TwitterBlog,“ [Online]. Available: http://blog.twitter.com/2011/06/200-million-tweets-per-day.html. [Zugriff am 14 12 2011]. [7] „MySQL,“ [Online]. Available: http://www.mysql.de/why-mysql/marketshare/. [Zugriff am 14 12 2011]. [8] E. F. Codd, „A Relational Model of Data for Large Shared Data Banks,“ CACM, Bd. 13, Nr. 6, pp. 377-387, June 1970. [9] „Intersystems,“ [Online]. Available: http://www.intersystems.de/cache/whitepapers/matchwp.html. [Zugriff am 14 12 2014]. [10] „TNS-Infratest,“ [Online]. Available: http://www.tns-infratest.com/presse/presseinformation.asp?prID=823. [Zugriff am 14 12 2011]. [11] A. Göbel, „Verbindung relationaler Datenbanksysteme und NoSQL-Produkte,“ in 23rd GI-Workshop on Foundations of Databases, Obergurgl, Österreich, 2011. [12] „Oracle Real Application Clusters,“ [Online]. Available: http://www.oracle.com/de/products/database/options/rac/index.html. [Zugriff am 14 12 2011]. [13] „MySQL Cluster,“ [Online]. Available: http://www.mysql.de/products/cluster/architecture.html. [Zugriff am 11 12 2011]. [14] „Stozzi,“ [Online]. Available: http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page. [Zugriff am 11 12 2011]. [15] S. Edlich, A. Friedland, J. Hampe, B. Brauer und M. Brückner, NoSQL, München: Carl Hanser Verlag, 2011. [16] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes und R. E. Gruber, „Bigtable: A distributed storage system for structured data,“ in IN PROCEEDINGS OF THE 7TH CONFERENCE ON Literaturverzeichnis 31 USENIX SYMPOSIUM ON OPERATING SYSTEMS DESIGN AND IMPLEMENTATION - VOLUME 7, 2006. [17] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall und W. Vogels, „Dynamo: amazon’s highly available key-value store,“ in In Proceedings Symposium on Operating Systems Principles, 2007. [18] „macdailynews,“ [Online]. Available: http://macdailynews.com/2011/09/13/idc-more-mobile-internet-usersthan-pc-users-in-the-u-s-by-2015/. [Zugriff am 14 12 2011]. [19] „NoSQL-Database,“ [Online]. Available: http://www.nosql-database.org. [Zugriff am 11 12 2011]. [20] „Heise,“ [Online]. Available: http://www.heise.de/open/artikel/NoSQL-im-Ueberblick1012483.html?artikelseite=2. [Zugriff am 14 12 2011]. [21] J. Dean, S. Ghemawat und G. I. , „MapReduce: simplified data processing on large clusters,“ in In OSDI’04: Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation, 2004. [22] „Heise,“ [Online]. Available: http://www.heise.de/developer/artikel/Programmiermodell-und-Framework964823.html?view=zoom;zoom=1.. [Zugriff am 14 12 2012]. [23] „Hadoop,“ [Online]. Available: http://hadoop.apache.org/. [Zugriff am 14 12 2011]. [24] „code.google,“ [Online]. Available: http://code.google.com/intl/de-DE/edu/parallel/mapreduce-tutorial.html. [Zugriff am 14 12 2011]. [25] „Hadoop.apache,“ [Online]. Available: http://hadoop.apache.org/common/docs/current/mapred_tutorial.html#Example%3A+WordCount+v1.0. [Zugriff am 14 12 2011]. [26] E. A. Brewer, „Towars robust ditributed systems,“ in (Invited Talk) Principles of Distrubuted Computing, Portland, Oregon, 2000. [27] S. Gilbert und N. Lynch, „Brewer's Conjecture and the Feasibility of Consistent Available Partition-Tolerant Web Services,“ in In ACM SIGACT News, 2002. [28] „ECC,“ [Online]. Available: http://www.ecchandel.de/97_prozent_der_deutschen_internetnutzer_kaufen.php. [Zugriff am 14 12 2011]. [29] „CouchDB,“ [Online]. Available: http://couchdb.org. [Zugriff am 14 12 2011]. [30] T. Geci und O. G. , „NoSQL Datenbanken – Alles,“ in Erläuterungen zu NoSQL Datenbanken und Einsatzgebiete.
