Datenbanksysteme Kapitel 6: Neue Konzepte der Datenbanktechnologie

Transkript

1 Datenbanksysteme Kapitel 6: Neue Konzepte der Datenbanktechnologie Prof. Dr. Peter Chamoni Mercator School of Management Lehrstuhl für Wirtschaftsinformatik, insb. Business Intelligence Prof. Dr. Peter Chamoni - Prof. Datenbanksysteme Dr. Peter Chamoni - Wintersemester 2014/2015 1

2 Gliederung 1 Grundlagen - Datenbanksysteme 2 SQL Data Definition Language 3 Datenorganisation 4 Datenintegrität und Transaktionsverwaltung 5 SQL Data Manipulation Language 6 Neue Konzepte der Datenbanktechnologie Prof. Dr. Peter Chamoni Datenbanksysteme 2

3 Gliederung 6 Neue Konzepte der Datenbanktechnologie 6.1 Business Intelligence Infrastruktur 6.2 In Memory Computing 6.3 NoSQL Datenbanksysteme Grenzen relationaler Datenbanksysteme NoSQL Ausgewählte Grundlagen Klassifikation von NoSQL-Systemen Prof. Dr. Peter Chamoni Datenbanksysteme 3

4 6.1 Business Intelligence Infrastruktur Eine moderne BI-Infrastruktur verfügt über eine Vielzahl von Tools, um unternehmensrelevante Daten - sowohl in strukturierter, semistrukturierter wie auch unstrukturierter Form aus zahlreichen, unterschiedlichen Datenquellen zu erheben, aufzubereiten, zu speichern und auf diese Weise für Analysen nutzbar zu machen. Zu diesen Werkzeugen gehören u.a. Data Warehouses und Data Marts, In Memory Computing, Hadoop, Analytics Plattformen u.v.m. Laudon,K., Laudon,J.,Schoder D: Wirtschaftsinformtik (2016). Prof. Dr. Peter Chamoni Datenbanksysteme 4

5 6.1 Business Intelligence Infrastruktur Unternehmensanwendungen werden traditionell in operative Systeme: OLTP (Online Transactional Processing) und analytische Systeme: OLAP (Online Analytical Processing) aus Performance-Gründen unterteilt. OLTP zur Unterstützung von Geschäftsprozessen im Tagesgeschäft OLAP zur Unterstützung der Auswertung von Geschäftsdaten Prof. Dr. Peter Chamoni Datenbanksysteme 5

6 6.1 Business Intelligence Infrastruktur OLTP versus OLAP Prof. Dr. Peter Chamoni Datenbanksysteme 6

8 6.2 In Memory Computing In Memory Computing (I) Eine Möglichkeit, die Analyse von großen Datenvolumina performanter zu gestalten, besteht im Einsatz des In Memory Computing, bei dem primär der Arbeitsspeicher des Computers (RAM) zum Speichern der Daten verwendet wird. Die Nutzer greifen direkt auf die Daten im Arbeitsspeicher zu, der deshalb auch als Direktzugriffsspeicher bezeichnet wird. Bei der In-Memory-Verarbeitung können sehr große Datenmengen, die den Umfang eines Data Mart oder eines kleinen Data Warehouse haben, gänzlich im Speicher gehalten werden (Hauptspeicherdatenbanken). Durch den Einsatz von In Memory Computing können Unternehmen die Nutzung des Arbeitsspeichers optimieren und die Rechenleistung bei gleichzeitiger Senkung der Kosten beschleunigen. nicht-flüchtig Prof. Dr. Peter Chamoni Datenbanksysteme 8

9 6.2 In Memory Computing In Memory Computing (II) Technologische Konzepte Neue Techniken sind notwendig: um verschiedene Arten von Mehraufwand zu vermeiden, ABER: gleichzeitig die ACID-Eigenschaften der Transaktionsverarbeitung zu gewährleisten. Technologisch liegen Hauptspeicherdatenbanken die folgenden Konzepte zugrunde: Datenhaltung im Hauptspeicher Um die Zugriffszeiten niedrigerer Ebenen zu eliminieren, werden beim Start alle benötigten Daten in den Hauptspeicher geladen. Zur Gewährleistung der ACID-Eigenschaften - besonders im Falle nicht vermeidbarer Fehler und Ausfälle - werden die Log-Dateien im nicht-flüchtigen Speicher gehalten. Auf diesen Daten können dann Transaktionskontroll- und Wiederherstellungsmechanismen aufsetzen. nicht-flüchtig Prof. Dr. Peter Chamoni Datenbanksysteme 9

10 6.2 In Memory Computing In Memory Computing (III) Technologische Konzepte Zeilen- und spaltenweise Speicherung von Datensätzen Während spaltenorientierte Datenbanken tendenziell für analytische Systeme geeigneter sind, zeilenorientierte Datenbanken dagegen für operative Systeme, erscheint für kombinierte Systeme eine hybride Technik sinnvoll. Tabelle Row Store Column Store Prof. Dr. Peter Chamoni Datenbanksysteme 10

11 6.2 In Memory Computing In Memory Computing (IV) Technologische Konzepte Spaltenorientierte Datenorganisation Das Lesen und Einfügen eines vollständigen Datensatzes erfordert relativ aufwendige Zugriffe auf sämtliche, unabhängig gespeicherte Spalten. Column Store Bei einer Anfrageverarbeitung werden jetzt nur wirklich benötigte Attribute in den Hauptspeicher transferiert. Attributwerte einzelner Spalten sind oft so homogen, dass leichtgewichtige Kompressionsverfahren wie z.b. Dictionary-Encoding zu signifikanten Kompressionsraten führen. Standardrepertoire spaltenorientierter Datenbanken: Komprimierte Datenhaltung in Verbindung mit Anfrageverarbeitungstechniken, die auf komprimierten Daten operieren können. Die Vorteile spaltenorientierter Datenhaltung sind so groß, dass viele relationale Datenbanken sie heutzutage zumindest als Option anbieten. Prof. Dr. Peter Chamoni Datenbanksysteme 11

12 6.2 In Memory Computing In Memory Computing (V) Technologische Konzepte Zeilen- und Spaltenorientierte Speicherung von Datensätzen Beispiel (1) Verkauf Monat Land Produkt Betrag DE P DE P AF P DE P Prof. Dr. Peter Chamoni - Datenbanksysteme 12

13 6.2 In Memory Computing In Memory Computing (VI) Technologische Konzepte Zeilen- und Spaltenorientierte Speicherung von Datensätzen Beispiel (2) Verkauf zeilenorientiert SELECT SUM(Betrag) FROM Verkauf WHERE Monat > ; Ausgabe: 350 Verkauf spaltenorientiert Prof. Dr. Peter Chamoni - Datenbanksysteme 13

14 6.2 In Memory Computing In Memory Computing (VII) Technologische Konzepte Zeilen- und Spaltenorientierte Speicherung von Datensätzen Beispiel (3) Verkauf zeilenorientiert SELECT * FROM Verkauf WHERE Monat > ; Verkauf spaltenorientiert Ausgabe: Monat Land Produkt Betrag DE P AF P DE P Prof. Dr. Peter Chamoni - Datenbanksysteme 14

15 6.2 In Memory Computing In Memory Computing (VIII) Technologische Konzepte Nur Einfügeoperationen in der Datenbank Insert-Only-Datenbanken definieren eine Kategorie von DBMS, bei der neue Datensätze grundsätzlich nur hinzugefügt werden. Modifizierende Operationen (ändern, löschen) werden in technisches Anfügen umgesetzt, wobei ein Zeitstempel mitgeschrieben wird und Gültigkeitsflags gesetzt werden. Eingefügte Datensätze sind so nur für einen Zeitraum gültig und Werte daher zeitabhängig. Auf diese Weise wird die komplette Historie aller Datenmodifikationen persistiert. Gründe sind zum einen das Speichern der kompletten Historie aller Unternehmensdaten (in vielen Ländern gesetzlich vorgeschrieben), zum anderen aber auch die Nebenläufigkeitskontrolle. Der Vorteil dabei ist, dass Lesetransaktionen nicht Ressourcen sperren müssen und daher nicht andere Transaktionen blockieren. Prof. Dr. Peter Chamoni Datenbanksysteme 15

16 6.2 In Memory Computing In Memory Computing (IX) Technologische Konzepte Insert-Only-Datenbanken Deltamechanismus komprimiert INSERT Schreiboperationen Haupt-Speicher Delta-Speicher MERGE Leseoperationen Prof. Dr. Peter Chamoni - Datenbanksysteme 16

17 6.2 In Memory Computing In Memory Computing (X) Technologische Konzepte Insert-Only-Datenbanken Beispiel (1) UPDATE, INSERT INSERT MERGE :00 Prof. Dr. Peter Chamoni - Datenbanksysteme 17

18 6.2 In Memory Computing In Memory Computing (XI) Technologische Konzepte Insert-Only-Datenbanken Beispiel (2) Delete INSERT MERGE :00 Prof. Dr. Peter Chamoni - Datenbanksysteme 18

19 6.2 In Memory Computing In Memory Computing (XII) Technologische Konzepte Multicore-CPUs und Multiprozessoren Eine Multicore-CPU hat viele Rechnerkerne auf einem Chip. Zur Realisierung dieser Konzepte werden verschiedene Techniken eingesetzt: Verarbeitungslogik nahe der Datenbank Klassische Client-Server-Architektur: möglichst viel Verarbeitungslogik wird von den Applikationsservern übernommen Hauptspeicherdatenbank: viel Anwendungslogik wird in die Datenbank integriert. Datenkompression Einsatz unterschiedlicher Formen von Datenkompression Verzicht auf Aggregate Aggregate werden nicht gesondert gespeichert (Speicherersparnis), sondern performant im Hauptspeicher on the fly berechnet. Prof. Dr. Peter Chamoni Datenbanksysteme 19

20 6.2 In Memory Computing In Memory Computing (XIII) Technologische Konzepte In Memory Computing - Datenkompression (Dictionary Compressed) Prof. Dr. Peter Chamoni - Datenbanksysteme 20

21 6.2 In Memory Computing Ein Blick in die Zukunft Hybrid Transactional/Analytical Processing (HTAP) is a term used to describe the capability of a single database that can perform both OLTP and OLAP for the purpose of real-time operational intelligence processing. [ Prof. Dr. Peter Chamoni Datenbanksysteme 21

23 6.3.1 Grenzen relationaler Datenbanksysteme Relationale Datenbanksysteme (I) Ausgerichtet auf komplexe Datenbankanwendungen - Große Datenmodelle - Transaktionen: strenge Einhaltung des ACID-Prinzips zur Sicherstellung der Datenintegrität, d.h. Datenkonsistenz, Datensicherheit und des Datenschutzes DBS ist von Anbeginn nicht auf Skalierbarkeit ausgerichtet, vielmehr wird ein Server auf mehr Leistungsfähigkeit technisch aufgerüstet. Skalierung: vertikal ( Scale Up ) bezeichnet die vertikale Vergrößerung von Ressourcen eines Datenbanksystems in Form von Speicher und/oder CPU. - führt zu Groß-Systemen - verlangt extrem zuverlässige Hardware - verursacht überproportionale Kosten - erzeugt single point of failure Scale Up Prof. Dr. Peter Chamoni Datenbanksysteme 23

24 6.3.1 Grenzen relationaler Datenbanksysteme Relationale Datenbanksysteme (II) Zunehmende Performance-Probleme entstanden bei RDBS durch fortwährend steigende Anforderungen im Verlauf der Entwicklung Beispiel: Systemaufrufe Prof. Dr. Peter Chamoni Datenbanksysteme 24

26 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksysteme (I) NoSQL (not only SQL) (1) Die neuen Systeme sind unabhängig voneinander - aus praktischen Anforderungen heraus - entstanden, z.b. - aus Performance-Anforderungen beim Umgang mit großen Datenmengen (Web 2.0), - Speichern unstrukturierter Daten etc. Diese unabhängigen Wurzeln spiegeln sich auch in einer gewissen Vielfalt von Konzepten wieder. Antwort auf die Anforderungen großer Internet-Sites (Facebook, Google, Amazon ) Seit ca steht NoSQL (not only SQL) für eine Familie von sehr gut skalierbaren Datenbanksystemen, die einen nicht-relationalen Ansatz verfolgen. Prof. Dr. Peter Chamoni Datenbanksysteme 26

27 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksysteme (II) NoSQL (not only SQL) (2) Zahlreiche NoSQL-Konzepte lehnen sich an folgende Definition an: Unter NoSQL wird eine neue Generation von Datenbanksystemen verstanden, die meistens einige der nachfolgenden Punkte berücksichtigen: Das zugrundeliegende Datenmodell ist nicht relational. Die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgerichtet. Das NoSQL-System ist Open Source. Fortsetzung der Definition nächste Folie [ Prof. Dr. Peter Chamoni Datenbanksysteme 27

28 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksysteme (III) NoSQL (not only SQL) (3) Ergänzt wird die Definition mit folgenden Merkmalen: Das System ist schemafrei oder hat nur schwache Schemarestriktionen. Aufgrund der verteilten Architektur unterstützt das System eine einfache Datenreplikation. Das System bietet eine einfache API. Dem System liegt meistens auch als Konsistenzmodell zugrunde: eventually consistent / BASE, aber nicht ACID. [ Prof. Dr. Peter Chamoni Datenbanksysteme 28

29 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksysteme (IV) NoSQL Datenbanksysteme (4) Ausgerichtet auf Internet-Anwendungen - Rasantes Daten-Wachstum - Stabile Zugriffszeiten - Hohe Verfügbarkeit NoSQL-Systemen sind i.d.r. von Anbeginn auf Skalierbarkeit ausgerichtet, d.h. es können Rechnerknoten dynamisch eingebunden werden, die einen Teil der Last/Daten tragen können. Skalierung: horizontal ( Scale Out )... bezeichnet die Erweiterung des Systems durch Einfügen zusätzlicher Computerressourcen Scale Out - führt zu verteilten Systemen, - erzeugt many points of failure Prof. Dr. Peter Chamoni Datenbanksysteme 29

30 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksysteme (V) NoSQL Datenbanksysteme (5) Skalierung: horizontal ( Scale Out ) Erweiterung des Systems durch Einfügen zusätzlicher Computerressourcen. Verteilte Systeme sind nicht einfach zu betreiben bzgl. - Homogenität, Heterogenität - Sicherheit - Administration - Kommunikation, Bandbreite, Transportkosten u.v.m Konsistenzmodell in verteilten Datenbanksystemen: Ist es möglich, ein Datenbanksystem zu entwickeln, - ausgehend vom Konsistenzprinzip wie bei dem Entwurf relationaler Datenbanksysteme, - ABER: es gleichzeitig bzgl. der horizontalen Skalierbarkeit einfacher und performanter zu gestalten? Prof. Dr. Peter Chamoni Datenbanksysteme 30

31 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (VI) CAP-Theorem (1) (Eric Brewer, PODC 2000) In einem verteilten System können jeweils höchstens zwei der Eigenschaften gleichzeitig erfüllt sein: Konsistenz (Consistency) Die verteilte Datenbank erreicht nach Abschluss einer Transaktion einen konsistenten Zustand. Consistency Verfügbarkeit (Availability) Das System muss für einen konkreten Anwendungsfall eine akzeptable Reaktionszeit aufweisen, die bis zu einer vordefinierten Last eingehalten werden muss. Availability Partition Tolerance Ausfalltoleranz (Partition Tolerance) Das System kann weiterarbeiten trotz Ausfall eines Knotens oder einer Kommunikationsverbindung zwischen den Knoten. Prof. Dr. Peter Chamoni Datenbanksysteme 31

32 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (VII) CAP-Theorem (2) In der Praxis steht ein Unternehmen gemäß des CAP-Theorems somit vor der Entscheidung: Lockerung der Forderung nach strikter Einhaltung der Konsistenz im System oder Consistency das Risiko zu tragen, dass das System bei einem Ausfall der Verbindungen gar nicht oder nicht mit einer akzeptablen Reaktionszeit antwortet. Availability Partition Tolerance Für ein Webunternehmen, dessen Profit von der Erreichbarkeit seines Dienstes abhängt, ist dieses Risiko wohl eher nicht tragbar! Prof. Dr. Peter Chamoni Datenbanksysteme 32

33 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (VIII) Alternatives Konsistenzmodell: BASE ist ein Gegenkonzept zu ACID, basierend auf der Annahme, dass ein Verzicht auf Strong Consistency und dafür eine höhere Achtsamkeit auf Verfügbarkeit des Systems eine Steigerung der Skalierbarkeit ermöglicht. wird zur Lösung des Konflikts des CAP-Theorems herangezogen. BASE Eine NoSQL-Datenbank sollte über folgende Eigenschaften verfügen: grundsätzlich verfügbar (Basically Available) loser Zustand Konsistenz (Soft State) schlussendlich konsistent (Eventually Consistent) (schwache Konsistenz) Prof. Dr. Peter Chamoni Datenbanksysteme 33

34 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (IX) Map/Reduce Framework (1) spielt eine zentrale Rolle im Kontext von NoSQL-Datenbanken. Das Verfahren ist geeignet, große verteilte Datenmengen bei paralleler Ausführung effizient zu durchsuchen. Die Ursprünge des Verfahrens liegen in der funktionalen Programmierung: LISP erlaubt Entwicklern die Nutzung der Map/Reduce-Routinen, um parallele Programme zu erstellen, ohne dass der Entwickler sich um die Programmierung - der Kommunikation innerhalb des Rechner-Clusters - des Aufgaben-Monitorings oder - der Fehlerbehandlung kümmern muss. Prof. Dr. Peter Chamoni Datenbanksysteme 34

35 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (X) Map/Reduce Framework (2) Das Framework nutzt zwei Algorithmen, die jeweils nebenläufig auf verschiedenen Rechnerknoten in zwei Phasen hintereinander ausgeführt werden: Map verteilt Aufgaben an die verschiedenen Knoten im Netzwerk; Die Funktion map() wendet eine Funktion sukzessive auf alle Elemente einer Liste an und gibt eine durch die Funktion modifizierte Liste zurück. Reduce sortiert die Aufgaben; Eingabe Die Funktion reduce() akkumuliert einzelne Funktionsergebnisse der Listenpaare und reduziert sie damit auf einen Ausgabewert. Zwischenergebnisse Ausgabe Prof. Dr. Peter Chamoni Datenbanksysteme 35

36 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (XI) Map/Reduce Framework (3) Beispiel: durchschnittl. erreichte Punktzahl im letzten Semester auf Jahresebene MatrikelnummerDatumPunktzahl Eingabe MAP Combine Reduce (2014,25) (2014, [25, 47]) (2014,36) (2015,57) (2015,57) (2015,57) (2014,47) Prof. Dr. Peter Chamoni Datenbanksysteme 36

37 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (XII) Map/Reduce Framework (4) wird zur Lösung einer Vielzahl von Aufgaben genutzt, die eine Berechnung großer Datenmengen in einem Verbund von Rechnern erfordern. Beispielhaft sollen folgende Anwendungsbereiche genannt werden - Zählen von Zugriffen auf eine URL Map: verarbeitet die Zugriffe auf Webseiten aus vorhandenen Aufzeichnungen und gibt die Key/Value-Paare (URL, 1 ) aus. Reduce: addiert die Zwischenergebnisse pro URL und liefert als Ergebnisse die Zugriffe pro URL. - Wortindex Erstellung - Suchen in verteilten Datenbeständen (Grep) oder Sortieren - Erstellung des Link-Graphen über die Verlinkung von Webseiten zu einem Ziel Prof. Dr. Peter Chamoni Datenbanksysteme 37

38 6.3.2 NoSQL Ausgewählte Grundlagen NoSQL Datenbanksystem (XIII) Map/Reduce Framework (5) ist für viele Einsatzbereiche effizient anwendbar. Aus diesem Grunde wurden seit der ersten Vorstellung zahlreiche Implementierungen erzeugt, z.b. Implementierungen - Google Map/Reduce Framework ist in C ++ implementiert und bietet APIs für Python und Java. - Hadoop ist ein Apache Open Source-Java-Framework für skalierbare, verteilte Software. - CouchDB nutzt ein Map/Reduce Framework zur Definition von Views über verteite Dokumente. - u.v.m (z.b. Prof. Dr. Peter Chamoni Datenbanksysteme 38

39 6.3.2 NoSQL Ausgewählte Grundlagen SQL- vs. NoSQL-Datenbanksystem (I) Relationales Datenbanksystem (1) Modell Das Datenmodell ist relational, d.h. alle Daten werden in Tabellen abgelegt. Funktionale Abhängigkeiten bilden die Grundlage der Normalformen. Mit der Einhaltung dieser Normalformen werden konsistente und nicht-redundante Datenbankentwürfe garantiert. Architektur Das System gewährleistet Datenunabhängigkeit. Schema Die Definition von Tabellen werden im relationalen Datenbankschema abgelegt. Dieses enthält zudem die Definition der Primärschlüssel sowie Integritätsbedingungen. [Meier (2016), HMD H.310] Prof. Dr. Peter Chamoni - Datenbanksysteme 39

40 6.3.2 NoSQL Ausgewählte Grundlagen SQL- vs. NoSQL-Datenbanksystem (II) Relationales Datenbanksystem (2) Sprache Das Datenbanksystem verwendet SQL zur Datendefinition, -selektion und manipulation. Mehrbenutzerbetrieb Das System unterstützt den Mehrbenutzerbetrieb. Es können also gleichzeitig mehrere Benutzer die Datenbank abfragen oder bearbeiten. Konsistenz Ein relationales Datenbanksystem garantiert jederzeit Konsistenzerhaltung (strong consistency). Zudem bestehen Funktionen für die fehlerfreie und korrekte Speicherung der Daten sowie ihren Schutz vor Zerstörung, vor Verlust, vor unbefugtem Zugriff und Missbrauch. [Meier (2016), HMD H.310] Prof. Dr. Peter Chamoni - Datenbanksysteme 40

41 6.3.2 NoSQL Ausgewählte Grundlagen SQL- vs. NoSQL-Datenbanksystem (III) NoSQL Datenbanksystem (1) Modell Das zugrundeliegende Datenmodell ist nicht relational. Architektur Die Datenarchitektur unterstützt massiv verteilte Webanwendungen und horizontale Skalierung. Mindestens 3V Das Datenbanksystem erfüllt die Anforderungen für umfangreiche Datenbestände (volume), flexible Datenstrukturen (variety) und Echtzeitverarbeitung (velocity). Schema Das Datenbanksystem unterliegt keinem fixen Datenbankschema. [Meier (2016), HMD H.310] Prof. Dr. Peter Chamoni - Datenbanksysteme 41

42 6.3.2 NoSQL Ausgewählte Grundlagen SQL- vs. NoSQL-Datenbanksystem (IV) NoSQL Datenbanksystem (2) Replikation Das Datenbanksystem unterstützt die Datenreplikation. Mehrbenutzerbetrieb Das System unterstützt den Mehrbenutzerbetrieb, wobei differenzierte Konsistenzeinstellungen gewählt werden können. Konsistenz Aufgrund des CAP-Theorems ist die Konsistenz nur verzögert gewährleistet, falls hohe Verfügbarkeit und Ausfalltoleranz angestrebt werden. (weak consistency) [Meier (2016), HMD H.310] Prof. Dr. Peter Chamoni - Datenbanksysteme 42

44 6.3.3 Klassifikation von NoSQL Systemen Aufgrund der weit gefassten Definition zählen zu NoSQL eine Vielzahl verschiedener Konzepte, wobei die derzeit wichtigsten sind: Key / Value Stores Document Stores Column resp. Column Family Stores (In-Memory-Datenbanken) Graph-Datenbanken u.v.m. Prof. Dr. Peter Chamoni - Datenbanksysteme 44

45 6.3.3 Klassifikation von NoSQL Systemen Key / Value Store (I) Grundprinzip sämtliche Daten werden in Form von Schlüssel-Wertpaaren gespeichert, d.h. die gespeicherten Daten (value) werden über einen eindeutigen Schlüssel (key), der aus einer strukturierten oder willkürlichen Zeichenkette bestehen kann, identifiziert. Beschreibung einfach-strukturierte NoSQL-DB prädestiniert, Parallelität in der Verarbeitung auszunutzen (Map/Reduce-Verfahren) Mengenoperationen und Aggregationen benötigen wenig Rechenzeit. Prof. Dr. Peter Chamoni - Datenbanksysteme 45

46 6.3.3 Klassifikation von NoSQL Systemen Key / Value Store (II) Abfragen Einfache Suchabfragen werden unterstützt (Beschränkung auf Keys). Komplexe Auswertungen sind aufwendig zu realisieren. Einsatzbereiche Anwendungen, die hochverfügbar sind und gleichzeitig sehr geringe Reaktionszeit aufweisen müssen Web-Anwendungen für Warenkörbe bei Online-Shops oder für die Speicherung von Session-Daten Posteingangssuche von Facebook (Cassandra) Anbieter z.b. Membase (Couchbase), Redis (Vmware), Azure Table Storage (Microsoft), Berkeley DB (Oracle) Prof. Dr. Peter Chamoni - Datenbanksysteme 46

47 6.3.3 Klassifikation von NoSQL Systemen Document Store Dokumentorientierte Datenbank (I) Grundprinzip Ähnlich zu Key/Value Stores Daten sind jedoch Dokumente, die untereinander keine Beziehung haben, sondern nur eine strukturierte Sammlung von unterschiedlichen Daten aufweisen. (Sammlung von semi-strukturierten Dokumenten) Diese Dokumente werden nach einem bestimmten Format (XML, JSON, etc.) ausgetauscht und gespeichert. Document Store Versicherungsagentur Beschreibung einfach-strukturierte NoSQL-DB Horizontale Skalierung und Replikation werden auf einfache Weise unterstützt. verlangt kein Schema und ist offen für Änderungen. Prof. Dr. Peter Chamoni - Datenbanksysteme 47

48 6.3.3 Klassifikation von NoSQL Systemen Document Store Dokumentorientierte Datenbank (II) Abfragen Dynamische Abfragen sind ein guter Ersatz für SQL, da oft umfangreiche Filteroperatoren zur Verfügung stehen. Einsatzbereiche Viele webbasierte Anwendungen lassen sich als Kollektion von Dokumenten realisieren. Anbieter MongoDB (JSON), CouchDB (Apache, JSON), Lotus Notes (IBM, Domino XML) Prof. Dr. Peter Chamoni - Datenbanksysteme 48

49 6.3.3 Klassifikation von NoSQL Systemen Column Store bzw. Column Familiy Store (I) Grundprinzip: Column Store Spaltenorientierte Datenbanken speichern die Attribute einer Tabelle spalten- und nicht zeilenweise. Beschreibung unterstützt die kostengünstige Speicherung großer Datenbestände. Die Skalierung der Daten kann rasch und effizient erfolgen. Spaltenweise Aggregationen können in kurzer Zeit durchgeführt werden. Abfragen SQL-ähnliche Abfragen sind möglich. Prof. Dr. Peter Chamoni - Datenbanksysteme 49

50 6.3.3 Klassifikation von NoSQL Systemen Column Store bzw. Column Familiy Store (II) Grundprinzip: Column Family Store (Wide Column Stores) Die spaltenorientierte Speicherung wird mit zeilenorientierten Ansätzen kombiniert. Column Families werden gelegentlich mit relationalen Tabellen verglichen, bei denen Zeilen eine dynamische Anzahl an Attributen haben. Sie ordnen Daten nach einem Zeilenschlüssel, der mit beliebig vielen Spalten verknüpft ist. Dabei wurden sie für eine verteilte Architektur entwickelt, damit sie hochverfügbar und skalierbar sind. Prof. Dr. Peter Chamoni - Datenbanksysteme 50

51 6.3.3 Klassifikation von NoSQL Systemen Column Store bzw. Column Familiy Store (III) Grundprinzip: Column Family Store (Wide Column Stores) Grundsätzlich besteht das Modell aus Spaltenfamilien (Column Families), Zeilen-Schlüssel und den Spalten (Columns). Die kleinste Einheit dieses Systems ist eine Spalte. Sie besteht aus: einem Namen mit einem Wert (Key-Value-Paar) und einem Zeitstempel, der zur Versionsverwaltung dient. Spalten, die als zusammenhängend betrachtet werden sollen und auf die gemeinsam zugegriffen werden soll, lassen sich als Sammlung zu Spaltenfamilien aggregieren (ähnlich den relationalen Tabellen). Prof. Dr. Peter Chamoni - Datenbanksysteme 51

52 6.3.3 Klassifikation von NoSQL Systemen Column Store bzw. Column Familiy Store (IV) Grundprinzip: Column Family Store (Wide Column Stores) Die Sortierung und das Referenzieren der Spaltenfamilien erfolgt über die Zeilen-Schlüssel. Diese Zeilen können beliebig viele Attribute/Spalten besitzen. Sie sind an kein Schema gebunden, d.h. jede Zeile kann einen anderen Aufbau haben als die nächste. Prof. Dr. Peter Chamoni - Datenbanksysteme 52

53 6.3.3 Klassifikation von NoSQL Systemen Column Store bzw. Column Familiy Store (V) Beschreibung Ursprung des Systems (Googles BigTable) war das Bedürfnis nach einem flexiblen System mit hoher Performanz und Verfügbarkeit beim Umgang mit Daten im Petabyte-Bereich, verstreut auf tausenden Cluster-Knoten. Einsatzbereiche Content-Management-Systeme Soziale Netzwerke und Blog-Plattformen BigTable kommt intern in vielen Google-Diensten zum Einsatz, z.b. in Google Maps, Google Earth oder YouTube. Anbieter Cassandra (Apache), Hadoop / HBase (Apache), BigTable (Google), Dynamo (Amazon) Prof. Dr. Peter Chamoni - Datenbanksysteme 53

54 6.3.3 Klassifikation von NoSQL Systemen Graph-Datenbank (I) Grundprinzip Eine graphenorientierte Datenbank benutzt Graphen, um stark vernetzte Informationen darzustellen und abzuspeichern. Sie verwaltet Graph- oder Baumstrukturen, in denen die Elemente miteinander verknüpft sind. Knoten des Graphen = Daten Kanten des Graphen = Beziehungen zwischen den Daten Knoten und Kanten des Graphen können mit properties, also Eigenschaften versehen oder gewichtet werden. Die Daten werden über ihre (relative) Position im Graphen identifiziert (traversieren), somit wird kein Schlüssel benötigt. Prof. Dr. Peter Chamoni - Datenbanksysteme 54

55 6.3.3 Klassifikation von NoSQL Systemen Graph-Datenbank (II) Einsatzbereiche Graph-Datenbanken erfreuen sich großer Beliebtheit, da sie für unterschiedliche Anwendungen eingesetzt werden können: Analyse von sozialen Netzwerken Aufbau von Empfehlungssystemen Web 3.0 Semantisches Web Fahrplanoptimierung geographische Systeme Anbieter Neo4J, sones GraphDB, Trinity (Microsoft), AllegroGraph Prof. Dr. Peter Chamoni - Datenbanksysteme 55

56 6.3.3 Klassifikation von NoSQL Systemen Koexistenz von SQL- und NoSQL-Datenbanktechnologien Viele webbasierte Anwendungen setzen für die unterschiedlichen Dienste adäquate Datenhaltungssysteme ein. Die vielfältigen Anforderungen an Konsistenz, Verfügbarkeit, Auswertungsgeschwindigkeit oder Ausfalltoleranz verlangen oft nach einer Kombination von Datenhaltungssystemen [Meier (2016), HMD H.310] Prof. Dr. Peter Chamoni - Datenbanksysteme 56