Application-Mimes: experimentelle, vergleichende Bewertung von Datenbank-Systemen

Transkript

1 1Berichte aus dem Karl-Steinbuch- Forschungsprogramm Jens Nimis Martin Kammerer Matthias Armbruster Chris Mattes Application-Mimes: experimentelle, vergleichende Bewertung von Datenbank-Systemen Ein Leitfaden zur erfolgreichen Auswahl innovativer Datenbank-Systeme U1

2 Berichte aus dem Karl-Steinbuch- Forschungsprogramm Nr. 1 Application-Mimes: experimentelle, vergleichende Bewertung von Datenbank-Systemen Ein Leitfaden zur erfolgreichen Auswahl innovativer Datenbank-Systeme Jens Nimis Martin Kammerer Matthias Armbruster Chris Mattes

3 1 Impressum Herausgeber: MFG Stiftung Baden-Württemberg Breitscheidstraße Stuttgart Tel Fax Ansprechpartnerin: Dr. Andrea Buchholz buchholz@mfg.de MFG Stiftung Baden-Württemberg Gestaltung: Ingo Juergens, Südgrafik 2

4 Zusammenfassung Das Aufkommen von NoSQL-Datenbanken in den vergangenen Jahren hat zu einer fast unüberschaubaren Auswahl und Heterogenität an kommerziell einsetzbaren Datenbank-Systemen geführt. Die Fähigkeiten der innovativen Datenbank-Systeme decken nun Anwendungsbereiche ab, in denen die traditionellen relationalen Datenbanken ( SQL-Datenbanken ) an ihre Grenzen gestoßen waren. Aber auch für Anwendungen, die nicht in diesen Grenzbereichen liegen, tun sich neue Chancen auf, wenn eine effizientere Datenhaltung z. B. neue Anwendungsfunktionalitäten oder komplexere Datenanalysen erlaubt. Architekten und Entwickler von Informationssystemen sehen sich im Zuge des Software-Entwurfsprozesses einem neuen Entscheidungsproblem gegenüber. Während bisher das klassische Datenbank-Benchmarking bei der Auswahl unter den gesetzten SQL-Datenbanken behilflich war, werden die aufstrebenden NoSQL- Datenbanken nicht von diesen erfasst. Die funktionalen und nicht-funktionalen Eigenschaften der für eine bestimmte Anwendung infrage kommenden Datenbank- Systeme sind so divergent, dass sie sich nur schwer mit derselben Benchmark be - urteilen lassen werden. Der vorliegende Bericht stellt unseren Ansatz zur experimentellen vergleichenden Bewertung von Datenbank-Systemen vor, der für ein zu entwickelndes Informationssystem eine begründete Auswahl unter einer Menge sehr unterschiedlicher potenzieller Datenbanken ermöglicht. Die Vorgehensweise basiert auf dem Konzept der sogenannten Application-Mimes, d. h. auf funktional eingeschränkten Implementierungen, die ausschließlich auf die Interaktion des Informationssystems fokussiert sind und dessen Verhalten in dieser Beziehung so aussagekräftig wie möglich nachzuahmen versuchen. Nach einer Vorstellung der Hintergründe führt der Bericht zunächst in das Konzept der Application-Mimes ein und schildert, wie ein Anwender selbst zu geeigneten Application-Mimes gelangt, bevor am Beispiel von vier konkreten Anwendungsszenarien experimentelle vergleichende Bewertungen zwischen jeweils einer SQL- und einer NoSQL-Datenbank besprochen werden. Im Zuge der Experimentbeschreibungen werden sowohl die Erfahrungen mit dem Ansatz als auch mit den verschiedenen SQL- und NoSQL-Kandidaten dargestellt. Auf dieser Basis können Anwender des Konzepts selbständige Evaluierungen von Datenbanken in ihren eigenen Szenarien durchführen. 3

5 Inhalt Zusammenfassung 3 1 Einleitung 1. 1 Das Entscheidungsproblem Datenbank-Auswahl Ansatz Gliederung 8 2 Grundlagen 2.1 NoSQL-Datenbanken Definierende Eigenschaften Kernkonzepte NoSQL-Klassen und deren Hauptvertreter Benchmarking von Datenbanken Beschreibung von Anwendungsszenarien 16 3 Der Application-Mime Ansatz 3.1 Schritt 1: Application-Mime Entwicklung Schritt 1.1: Bestimmung der Anforderungen Schritt 1.2: Fokussierung des Application-Mime Schritt 1.3: Integration der Evaluierungsschicht Schritt 1.4: Vervollständigen der Versionen Schritt 1.5: Implementierung der Versionen Schritt 2: Aufbau des Testbeds Workload-Entwurf und Ausführung 22 4

6 4 Experimente 4. 1 Experiment 1: Project Relationship Management mit SQL und GDB Schritt 1: Application-Mime Entwicklung Schritt 2: Aufbau des Testbeds Schritt 3: Workload-Entwurf und Ausführung Experiment 2: Product Data Management mit SQL und DS Schritt 1: Application-Mime Entwicklung Schritt 2: Aufbau des Testbeds Schritt 3: Workload-Entwurf und Ausführung Experiment 3: Social Analytics mit SQL und WCS Schritt 1: Application-Mime Entwicklung Schritt 2: Aufbau des Testbeds Schritt 3: Workload-Entwurf und Ausführung Experiment 4: Product-Tracking mit SQL und KVS Schritt 1: Application-Mime Entwicklung Schritt 2: Aufbau des Testbeds Schritt 3: Workload-Entwurf und Ausführung 67 5 Schlussbetrachtung 71 A NoSQL Einsatzerfahrungen A.1 MongoDB 72 A.2 Redis 74 A.3 Neo4j 75 A.4 HBase 76 Literatur und Quellen 78 5

7 1 Einleitung 1 Die Landschaft der Datenbank-Systeme befindet sich in einem radikalen Umbruch: nachdem Jahrzehnte lang überwiegend Anpassungen und Erweiterungen der do - minierenden relationalen Datenbanken (auch SQL-Datenbanken ) erfolgt sind, drängt nun massiv eine neue Klasse moderner, nicht-relationaler Datenbanken auf den Markt die sogenannten NoSQL-Datenbanken (Redmond u. Wilson 2012; Mohan 2013). Die Bewegung ist getrieben von innovativen Anwendungsszenarien mit wechselhaftem Anwederverhalten und flexiblen Datenstrukturen, rasant wachsenden Datenmengen und Benutzerzahlen, denen SQL-Datenbanken nicht mehr gerecht werden können. Der Druck, der durch die neuen Mitbewerber entstanden ist, hat auch bei den relationalen Datenbanken zu einem Überdenken geführt, das sich in den sogenannten NewSQL-Datenbanken (Stonebraker 2012) widerspiegelt. In der Folge ist der Entwurfsraum für Informationssysteme enorm angewachsen und es stellt sich ein neues, nicht-triviales Entscheidungsproblem im Software-Entwurfsprozess mit wichtigen Konsequenzen. Die Auswahl einer angemessenen Datenhaltung für ein künftiges Informationssystem hat weitreichenden Einfluss auf dessen Architektur und damit auf die erreichbare Funktionalität und Leistungsfähigkeit. 1 Eine Kurzfassung der vorliegenden Arbeit in englischer Sprache wurde auf der International Conference on Enterprise Information Systems (ICEIS2014) unter dem Titel Application-Mimes: an Approach for Quantitative Comparison of SQL- and NoSQL-Databases präsentiert und veröffentlicht. 1.1 Das Entscheidungsproblem Datenbank-Auswahl Bei der Suche nach der am besten geeigneten Datenhaltungslösung für ein bestimmtes Anwendungsszenario gibt es einfache Fälle, die eindeutige und/oder extreme Eigenschaften als Indikatoren aufweisen. Soll z. B. ein neues Buchhaltungssystem für ein einzelnes Unternehmen entwickelt werden, dann ist in der Regel nach wie vor die Wahl einer SQL-Datenbank angezeigt aufgrund deren Stärke und Reife im Bereich Online Transaction Processing (OLTP) (Kemper u. Eickler 2011). Wenn auf der anderen Seite ein zweites Facebook entstehen soll, bieten sich vermutlich NoSQL-Datenbanken an, weil die Skalierbarkeit im Anwendungsszenario von herausragender Bedeutung ist. In den meisten Anwendungsszenarien gestaltet sich eine weitsichtige Auswahl des geeigneten Datenbanksystems in einem turbulenten und unkonsolidierten Markt jedoch zunehmend schwierig, weil deren Eigenschaften nicht eindeutig Schwarz oder Weiß indizieren. Das Verhaften in der althergebrachten SQL-Welt bietet Sicherheit, möglicherweise auf Kosten des Potenzials innovativer Produktideen der unbedachte Einsatz neuer Technologien birgt eventuell unnötige technische Risiken. In Konsequenz bedarf es für derartige Fälle eines systematischen Vorgehens zur Entscheidungsfindung. 6

8 1.2 Einleitung Die traditionellen Benchmarking-Verfahren zur Auswahl von Datenbanksystemen betrachten vor allem die Parameter Durchsatz und Antwortzeit (siehe Abschnitt 2.2). Moderne Datenbanken unterscheiden sich jedoch in einer Vielzahl weiterer Eigenschaften, die betrachtet werden müssen. Hierzu zählen funktionale Eigenschaften, wie z. B. das unterstützte Datenmodell und die Art des Zugriffes auf die Daten, ebenso wie semi- und nicht-funktionale Eigenschaften, wie z. B. Konsistenzmodell, Skalierbarkeit, Zuverlässigkeit, Wartbarkeit oder wirtschaftliche Über - legungen. Relationale Datenbanken bieten z. B. meistens die sehr ausdrucksstarke Struc - tured Query Language (SQL) zum Datenzugriff, die auch namensstiftend für diese Art der Datenbanken ist. Im Gegensatz hierzu besitzen NoSQL-Datenbanken in der Regel nur deutlich reduzierte Zugriffsschnittstellen und überlassen komplexere Datenbankanfragen der Programmlogik der Anwendung. Stattdessen umfassen manche NoSQL-Datenbanken weitere Funktionalitäten und Systemkomponenten, wie z. B. Web-Server, die in einer Anwendung Einsatz finden können und üblicherweise nicht von SQL-Datenbanken angeboten werden. Der bedeutendste Unterschied zwischen SQL- und NoSQL-Datenbanken liegt jedoch im unterschiedlichen Konsistenzmodell. Während relationale Datenbanken meist das ACID-Modell (Haerder u. Reuter 1983) mit seinen umfassenden Isolations- und Wiederanlaufgarantien realisieren, beschränken sich viele NoSQL-Systeme auf das BASE-Modell (Terry u. a. 1994) mit seinen eingeschränkten Garantien zugunsten einer verbesserten Skalierbarkeit. Für eine begründete Architektur- und Datenbank-Auswahlentscheidung ist es als Folge nicht ausreichend einen Workload zu definieren und damit einen traditionellen Benchmark auszuführen in vielen Fällen ist dies auch gar nicht möglich, weil verfügbare Benchmarks nicht generisch genug sind, die verschiedenen verfügbaren und infrage kommenden Datenbank-Kandidaten zu bewerten. 1.2 Ansatz In diesem Bericht stellen wir unseren Ansatz zur experimentellen, vergleichenden Bewertung von Datenbank-Systemen im Kontext eines zu entwickelnden Infor - mationssystems für ein gegebenes Anwendungsszenario vor, der eine begründete Auswahl unter einer Menge sehr unterschiedlicher potenzieller Datenbanken ermöglicht. Hierzu verwenden wir sogenannte Application-Mimes 2. So bezeichnen wir funktional auf das Nötigste eingeschränkte Umsetzungen eines Anwendungsszenarios, die ausschließlich dafür implementiert werden, das Verhalten des späteren voll funktionalen Informationssystems im Bezug auf die Datenhaltung so aussagekräftig wie möglich nachzuahmen. Für einen Vergleich verschiedenartiger Datenbanken findet zunächst eine Vorauswahl von Kandidaten statt. Für jeden dieser Kandidaten ist ein eigener individueller Application-Mime zu implementieren. Die verschiedenen Application- 2 Abgeleitet vom englischen Verb to mime. Definition nach Merriam Webster: to make the movements of someone who is doing (something) without actually doing it 7

9 1.3 Einleitung Mimes eines Szenarios werden dann verglichen, indem die Leistungsdaten unter demselben Lastprofil betrachtet werden. Primäres Ziel des Berichtes ist es, Architekten und Entwickler in die Lage zu versetzen, umfassende und aussagekräftige Vergleiche zwischen verschiedenen Datenbank-Systemen zu treffen und die hierzu erforderlichen Application-Mimes für die jeweiligen Anwendungsszenarien und Kandidaten zu entwickeln. 1.3 Gliederung Bevor in Kapitel 3 die Schritte der Application-Mime Methode eingeführt werden, sollen zunächst in Kapitel 2 einige einschlägige Grundlagen dargestellt werden. Hierzu gehören die Konzepte und Klassen der NoSQL-Datenbanken, ein Blick auf das traditionelle Datenbank-Benchmarking und Überlegungen zur Modellierung von Anwendungsszenarien. Unsere Erfahrungen mit der Application-Mime Methode zeigt Kapitel 4. Sie wird illustriert anhand von vier vergleichenden Experimenten, bei denen jeweils eine SQL- gegen einen NoSQL-Datenbank angetreten ist um die für das jeweilige Anwendungsszenario leistungsfähige Datenbank zu ermitteln. Die vier Anwendungsszenarien wurden so gewählt, dass ihre Merkmale im Grenzbereich vermutet werden können, d. h. dass sie sowohl den Einsatz einer SQL- als auch der jeweiligen NoSQL-Datenbank sinnvoll erscheinen lassen. Die Zahl von vier Experimenten wurde gewählt, um zu den vier etablierten NoSQL-Klassen Wide Column Stores (WCS), Document Stores (DS), Key/Value Stores (KVS) und Graphdatenbanken (GDB) jeweils ein eigenes Experiment vorzustellen und damit das gesamte aktuelle Spektrum der NoSQL-Datenbanken abzudecken. Im Vordergrund der Experimente steht dabei weniger das Ergebnis des konkreten Vergleichs der beiden Datenbanken es ist nicht ohne weiteres auf andere Anwendungsszenarien übertragbar. Vielmehr sollen die illustrierenden Experimente als Muster und Denkanstoß für eigene Evaluierungen dienen. Kapitel 5 fasst die zentralen Erkenntnisse noch einmal kurz zusammen und gibt einen Ausblick. Anhang A stellt als praktische Zusatzinformation die Erfahrungen mit den in den Experimenten eingesetzten NoSQL-Datenbanken dar. 8

10 2 Grundlagen Die Grundlagen des Application-Mime Ansatzes sind vor allem in den drei Bereichen NoSQL-Datenbanken (Abschnitt 2.1), Datenbank-Benchmarking (2.2) und Anwendungsmodellierung (2.3) zu finden. 2.1 NoSQL-Datenbanken Obwohl die NoSQL-Bewegung mit Recht als eine Revoluton der Datenbanklandschaft gesehen werden kann, beruht sie auf vielen althergebrachten und erprobten Konzepten. Diese fanden auch schon in den relationalen Datenbanken und verteilten Systemen ihre Anwendung und führen nun abgewandelt, ergänzt und in neuer Zusammenstellung zu den vier bekannten Klassen der NoSQL-Datenbanken Definierende Eigenschaften Vor einer Betrachtung der Kernkonzepte der NoSQL-Datenbanken sollen diese zunächst definiert werden, besonders in Abgrenzung zu den SQL-Datenbanken. Die Darstellung wurde entwickelt auf Basis von Edlich (2011). Hierbei lassen sich die definierenden Eigenschaften unterteilen in funktionale, semi-funktionale und nichtfunktionale Eigenschaften. Funktionale Eigenschaften: Das Datenmodell ist nicht relational im Gegensatz zu den SQL-Datenbanken, für die das relationale Modell definierend ist (siehe 2.1.3). Es gelten schwache Schemarestriktionen oder Schema-Freiheit. Das System bietet eine einfache Abfrage- bzw. Programmierschnittstelle, im Vergleich zum sehr mächtigen SQL. Semi-funktionale Eigenschaften: Häufig liegt ein abgeschwächtes Konsistenzmodell zugrunde im Vergleich zum ACID-Modell, das bei SQL-Datenbanken meist anzutreffen ist. Diese Eigen - schaft ist ursächlich für die Skalierbarkeit und spielt eine wichtige Rolle bei der Datenbankauswahl bzw. bei der Implementierung der Anwendungen. 9

11 2.1 Grundlagen Nichtfunktionale Eigenschaften: Das System ist auf horizontale Skalierung ausgerichtet (siehe 2.1.2). Die verteilte Architektur erleichtert die Datenreplikation (siehe 2.1.2) Kernkonzepte Die wichtigsten Kernkonzepte, die zu obigen Eigenschaften führen und in vielen NoSQL-Datenbanken und zum Teil auch schon früher in SQL-Datenbanken gefunden werden konnten, sind: Horizontale Verteilung und Replikation Horizontale Verteilung bezeichnet die Verteilung von Daten einer Datenbank auf mehrere Server innerhalb eines koordinierten sog. Datenbank-Clusters. Werden bei der Verteilung die Datensätze darüber hinaus vervielfältigt, so spricht man von Replikation. Verteilung und Replikation sind ursächlich für Skalierbarkeit und Leistungsfähigkeit der NoSQL-Datenbanken, erfordern jedoch zusätzliche Maßnahmen zur Sicherstellung der Datenkonsistenz. Sharding Sharding ist eine Form der horizontalen Verteilung und bedeutet, dass inhaltlich zusammengehörige Daten im Sinne eines Datensatzes zusammen auf einem Server abgelegt werden, dass jedoch verschiedene Datensätze aus einer gleich - förmigen Menge von Daten auf mehrere Server verteilt werden können. Consistent Hashing Consistent Hashing unterstützt Sharding und Replikation und beantwortet die Grundfrage, auf welchem Server bzw. auf welchen Servern ein bestimmter Datensatz gespeichert werden soll. Es bietet eine einfache und elegante Lösung, die beim Hinzufügen oder Entfernen von Servern des Clusters die Bewegung möglichst weniger Daten erfordert und dabei die Leistungsfähigkeit der einzelnen Knoten berücksichtigt. Paxos Paxos ist eine Familie von Konsensprotokollen für verteilte Systeme, wie z. B. NoSQL-Datenbanken. Es stellt die Erhaltung der Konsistenz replizierter Daten in einem Cluster mit unzuverlässigen Knoten sicher. Ausfälle einer Minderheit von Knoten, Abstürze von Transaktionen und der Verlust von Nachrichten können von Paxos toleriert werden. MultiVersion Concurrency Control (MVCC) MVCC wird auch in nicht-verteilten SQL-Datenbanken eingesetzt und erlaubt den konkurrierenden Zugriff mehrerer Transaktionen auf denselben Datensatz. Es wird gewährleistet, dass Änderungen an einem Datensatz von nachfolgenden Transaktionen berücksichtigt werden. Dies kann in manchen Situationen bedeuten, dass eine Transaktion wiederholt werden 10

12 2.1 Grundlagen muss und zu einem späteren Zeitpunkt mit dem korrekten Wert des Datensatzes erneut durchgeführt wird. Die genannten Grundprinzipien und weitere, wie die sog. Vector Clocks, und die Art wie diese kombiniert und ergänzt werden, z. B. durch Datenmodelle und Abfragesprachen, bestimmen maßgeblich die funktionalen und nicht-funktionalen Eigenschaften und damit das Wesen jeder Datenbank. Dies ist letzten Endes für ihre Auswahl von entscheidender Bedeutung. Die Datenmodelle der NoSQL-Datenbanken unterteilen die NoSQL-Welt in verschiedene Klassen, die im folgenden Abschnitt dargestellt werden NoSQL-Klassen und deren Hauptvertreter Bei der Einteilung der NoSQL-Welt in verschiedene Klassen werden heute in der Regel vier Hauptklassen unterschieden, was auch ausschlaggebend dafür war, den Application-Mime Ansatz in vier Experimenten zu veranschaulichen, um die komplette Bandbreite der NoSQL-Systeme abzudecken. Im Folgenden werden die vier Klassen Wide Column Stores, Document Stores, Key/Value-Stores und Graphdatenbanken kurz vorgestellt und ihre jeweils prominentesten Vertreter werden benannt. Durch die große Dynamik im Bereich der NoSQL-Datenbanken, kann die Auswahl der Vertreter aus den Klassen lediglich einen unvollständigen und subjektiven Schnappschuss darstellen. Für genauere Beschreibungen existieren mittlerweile eine Reihe von Überblickswerken, wie z. B. Edlich (2011) oder Spichale u. Wolff (2012) uvam. und im WWW gibt es Verzeichnisse, die versuchen, die aktuelle Situation bestmöglich abzubilden, wie z. B. unter Wide Column Stores Wide Column Stores (WCS) organisieren ihre Datenhaltung spaltenweise, d. h. die tabellarischen Daten werden nicht wie häufig in relationalen Datenbanken zeilenweise gespeichert, sondern alle Werte einer Spalte zusammen. Daraus ergeben sich Vorteile bei Abarbeitung von Aggregationsfunktionen, wie sie bei der Datenanalyse häufig auftreten und auch bei der platzeffizienten Speicherung. Dies wird erkauft durch Nachteile bezüglich des Lesens und Schreibens von Objektstrukturen, von inhaltlich zusammengehörigen Werten verschiedener Spalten (Edlich 2011; S. 53). Inspiriert wurden die WCS durch einen wissenschaftlichen Artikel von Google zur Architektur seiner Infrastruktur-Datenbank BigTable (Chang u. a. 2008). Google beschreibt dort den strukturellen Aufbau von BigTable mit: A Bigtable is a sparse, distributed, persistent multidimensional sorted map. Die Daten werden also zwar in Tabellen angelegt, diese sind jedoch multidimensional im Gegensatz zu den zweidimensionalen Relationen. Dabei wird jeder Zeile ein eindeutiger Schlüssel zugewiesen, welcher zum automatischen Sortieren der Zeilen dient. Diese bestehen aus belie - big vielen und sortiert angeordneten Spalten, die von Zeile zu Zeile variieren können. 11

13 2.1 Grundlagen Zur Laufzeit können entsprechend des schwachen Schemabegriffs neue Spalten aufgenommen werden. So entstandene neue Spaltennamen kann eine Applikation nicht unbedingt im Voraus kennen und die Datenbank akzeptiert deshalb Kommandos für Namensbereiche. Spalten werden innerhalb der Zeilen in Spaltenfamilien gruppiert, für die typischerweise Kompression, Replikation und Versionierung eingestellt werden können. Spalten können außerdem zur Performanceverbesserung nach typischen Zugriffsmustern organisiert werden. Neben der oben genannten Datenanalyse haben WCS auch Vorteile bei der Skalierbarkeit und können nahezu beliebig große Datenmengen speichern. Anhand der Zeilenschlüssel lassen sich Tabellen leicht horizontal partitionieren. Durch die nicht explizit vorhandenen Fremdschlüsselbeziehungen sind WCS gut für sog. Shared-Nothing Architekturen geeignet. Das schemafreie Datenmodell ist sehr flexibel und im Betrieb leicht zu ändern. WCS bieten sich somit an für analytische Informationssysteme, Suchmaschinen oder andere semantische Systeme und generell Systeme mit sehr großen Speicherbedarfen. Beispielsysteme: HBase (*) Cassandra Hypertable Document Stores Dokumentenbasierte Datenbanken, auch als Document Stores (DS) bezeichnet, speichern ihre verwalteten Daten in sog. Dokumenten, die im Allgemeinen keinem Schema unterliegen. Jedes Dokument besteht aus inhaltlich beliebig gestalten Schlüssel/Wert-Paaren und ist damit eher mit einem Objekt zu vergleichen als mit einem (digitalen) Dokument, wie man es von persönlichen Arbeitsumgebungen kennt. Die Werte, die einem Schlüssel zugewiesen werden, müssen nicht atomar sein, sondern können selbst wiederum z. B. Listen von Verweisen auf Dokumente beinhalten, wodurch eine verzweigte geschachtelte Objekthierarchie entsteht. Entlang der Objekthierarchie kann eine relativ unkomplizierte Verteilung und Replikation der Dokumente über mehrere Knoten eines Clusters erfolgen. Grundgedanke hierbei ist, dass in der Hierarchie zusammengehörige Daten auch zusammen gespeichert werden und nicht wie bei relationalen Datenbanken über mehrere Relationen hinweg verteilt und bei Anfragen wieder zusammengebaut werden müssen. Einfache Anfrage- und Navigationsmechanismen ermöglichen ein Auffinden von Dokumenten, die einem bestimmten Muster folgen. Die Schemafreiheit der DS erfordert von den Entwicklern, dass sie etwaige Überprüfungs - mechanismen z. B. auf bestimmte Wertebereiche oder Objektstrukuren in den Anwendungen selbst implementieren, anders als sie es von typsicheren objekt - orientierten Programmiersprachen gewohnt sind. Technisch werden die Dokumente von den Datenbanken nach außen häufig im JSON-Format (JavaScript Object Notation) über verschiedenartige Schnittstellen 12

14 2.1 Grundlagen angeboten. Während z. B der weitverbreitete DS MongoDB eine spezifische API besitzt, liefert CouchDB seine Dokumente über eine REST-Schnittstelle über das Web-Protokoll http aus. Auch in ihrem internen Aufbau unterscheiden sich die DS zum Teil erheblich. MongoDB speichert z. B. intern die Dokumente im optimierten BSON-Format, bietet Indizes um Anfragen zu beschleunigen und erlaubt Parallelverarbeitung der Daten über JavaScript. Durch die sehr stark voneinander abweichenden konkreten Implementierungen der DS-Systeme und ihren erheblich unterschiedlichen Funktionsumfang nach außen können die Systeme für unterschiedliche Anwendungsfelder inte - ressant sein. Besonders geeignet und daher auch häufig eingesetzt werden sie im Bereich der Web-Applikationen, wo sie beispielsweise die eingegebenen Formulardaten als Dokumente speichern oder aus Datenbank-Dokumenten html-seiten (also Web-Dokumente) dynamisch erzeugen. Beispielsysteme: CouchDB MongoDB (*) Amazon SimpleDB Key/Value-Stores Key/Value-Stores (KVS) haben das einfachste Datenmodell aller NoSQL-Systeme gespeichert werden lediglich Schlüssel und die dazugehörigen Werte ohne eine übergeordnete Struktur. Um eine Verknüpfung zwischen den Daten herstellen zu können sind als Werte auch komplexe Daten erlaubt, wie z. B. zusammengesetzte Werte, Mengen oder Listen. Datenbanken nach dem KVS-Prinzip sind schon seit den siebziger Jahren bekannt und bilden damit die ältesten Vertreter der NoSQL-Systeme. Auf der Einfachheit des Datenmodells beruht die überragende horizontale Skalierbarkeit der KVS, die den Ansatz bereits frühzeitig für Unternehmen mit großen Datenhaltungsanforderungen interessant werden lies. KVS erfuhren in der Folge des Web2.0 und Cloud Computings durch Anwender wie Facebook oder Amazon (durch die Amazon Web Services Cloud Angebote) eine Renaissance und gehören seitdem zu den am stärksten wachsenden NoSQL-Bereichen. Durch den Anwenderhintergrund ist ersichtlich, warum Amazon Dynamo als erstes verlässliches, skalierbares NoSQL-System betrachtet werden kann. Im Kern dessen Implementierung stehen die sog. verteilten Hashtabellen (engl. Distributed Hash Table, DHT), die für eine möglichst gleichmäßige Zuordnung von Daten auf die Server des Clusters und damit Lastverteilung sorgen sollen. Da jeder beteiligte Server eine Kopie der Hashtabelle besitzt, existieren keine sog. Single- Points-of-Failure, die die Toleranz gegenüber Netzwerk- oder Hardware-Störungen herabsetzen. Auch in dieser NoSQL-Klasse existieren unterschiedliche Systeme, die verschiedene Entwicklungsziele in den Mittelpunkt stellen. Riak folgt beispielsweise dem Vorbild durch Amazon Dynamo und hat sich auf den reibungslosen Betrieb 13

15 2.1 Grundlagen im Cluster weiter spezialisiert, in dem es z. B. zur Laufzeit das Aufnehmen neuer Serverknoten in das Cluster einfach unterstützt. Redis speichert hingegen im normalen Arbeitsmodus seine Daten im Hauptspeicher und erweitert den KV- Ansatz durch die Möglichkeit der Festlegung von Datentypen für die Werte. Die Persistenz der Daten lässt sich durch entsprechende Prozeduren zum Durchschreiben der Daten auf nichtflüchtigen Speicher der Knoten im Cluster erreichen. Durch die Auslegung als Hauptspeicherdatenbank eignet sich Redis besonders für Anwendungen, die extrem kurze Zugriffszeiten auf Daten von begrenzter Menge erfordern. Im Gegensatz hierzu bietet sich Riak durch seine konsequente Cluster-Orien - tierung besonders für Anwendungen mit extremen Skalierungsanforderungen an. Beispielsysteme: Redis (*) Riak Amazon Dynamo Graphdatenbanken Die Graphen von Graphdatenbanken (GDB) bestehen aus Knoten, die für Artefakte aus der Anwendungswelt stehen und (gerichteten oder ungerichteten) Kanten, die Beziehungen zwischen den Artefakten symbolisieren. Bei Knoten und Kanten können bei Bedarf angehängte Attribute weitere beschreibende Informationen aufnehmen. Indizes für Knoten und Kanten beschleunigen das Auffinden von Objekten und verhindern, dass bei jeder Anfrage der gesamte Graph traversiert werden muss. Einheitliche Abfragesprachen für GDB sind nicht vorgegeben, verbreitet sind jedoch SPARQL (aus der Welt der semantischen Netze) und Gremlin. Graphdatenbanken tragen der Tatsache Rechnung, dass sich Graphen in relationalen Datenbanken nur sehr ungenügend darstellen lassen, da sich Knoten und Beziehungskanten bei üblicher Normalisierung jeweils in einzelnen Tupeln niederschlagen und der zugrunde liegende Graph zur Traversierung nur aufwändig durch mehrfache rekursive Joins wieder rekonstruieren lässt. GDB unterstützen für große Graphen horizontale Skalierung, wobei sich die Verteilung der Teilgraphen auf die verschiedenen Server abhängig vom Anwendungsfall als nicht trivial er - weisen kann. Im Groben sollten eng vermaschte Teilgraphen auf einem Server zu - sammen gehalten werden. Bei hoher Anzahl von Lesevorgängen im Vergleich zu Schreib vorgängen bietet sich auch Replikation zur Performancesteigerung an. Prominentester Vertreter der Graphdatenbanken ist gegenwärtig Neo4j, das in Java entwickelt wurde und die starken ACID-Konsistenzeigenschaften erfüllt. Seine deklarative Anfragesprache Cypher erlaubt das effiziente Formulieren von Lese- und Schreiboperationen auf Graphen ohne notwendigerweise Codes zum Traversieren entwickeln zu müssen. Ein Blick auf potenzielle Anwendungsszenarien zeigt, dass die Speicherung von Graphen durchaus kein exotischer Bedarf ist, sondern dass diese vielen Anwendungen zugrunde liegen. Eine spezialisierte Anwendung ist die Speicherung sog. Ontologien, die Begrifflichkeiten gemäß ihrer Semantik zueinander in Bezug 14

16 2.2 Grundlagen setzen, häufig mittels sog. RDF-Graphen. Aber auch alltäglichere Anwendungen beruhen auf Graphen, wie z. B. soziale Netzwerke auf Beziehungsgraphen, Konstruktionsprogramme auf hierarchischen Stücklisten, Verkehrstelematikanwendungen auf Wegenetzen oder Suchmaschinen auf vernetzten Hypertextdokumenten. Im Allgemeinen bieten sich GDB also für alle Arten von Anwendungen an, bei denen Graphen oder Netze durchlaufen oder analysiert werden müssen. Beispielsysteme: Neo4j (*) HyperGraphDB InfiniteGraph Auswahl der NoSQL-Kandidaten für die vergleichenden Experimente Die Vorauswahl der NoSQL-Datenbanken für die vier vergleichenden Experimente erwies sich als sehr arbeits- und zeitaufwändig, was insbesondere auf den mangelnden Reifegrad der verschiedenen infrage kommenden Systeme zurückzuführen war. Die verfügbaren Überblickswerke waren dabei nur eingeschränkt hilfreich, durch die über - aus große Dynamik, die die Weiterentwicklung der Systeme im Moment aufweist. Häufig kann nicht einmal die Originaldokumentation der Systeme mit den Neuerungen in Funktionalität und Implementierung der Datenbanken Schritt halten, so dass Installations- und Bedienungsanleitungen veraltet oder inkonsistent sind. Hinzu kommen unzureichende Tests der freigegebenen Versionen durch die Entwickler, so dass die Systeme zwar in deren Testumgebungen fehlerfrei lauffähig sind, die Übertragbarkeit auf andere Gegebenheiten jedoch nicht gewährleistet ist. Als Folge aus dem beschriebenen Zustand wurde eine Reihe eigener Vortests mit verschiedenen Systemen erforderlich, wobei die oben namentlich aufgezählten Systeme näher betrachtet wurden, d. h., sie wurden installiert und zumindest Programmierversuchen unterzogen. Die mit (*) gekennzeichneten Systeme wurden schließlich für die vergleichenden Experimente als NoSQL-Vertreter ausgewählt. 2.2 Benchmarking von Datenbanken Die Auswahl von Datenbanken und anderer IT-Systeme orientiert sich an deren Leistungsfähigkeit, die häufig mittels standardisierten Benchmarks bestimmt werden kann. Aus diesem Grund wurde in Kammerer (2011) eine detaillierte Analyse einschlägiger populärer Benchmarks durchgeführt, um diese auf Eignung für das oben beschriebene Entscheidungsproblem zur Datenbankauswahl zu überprüfen. Abbildung 2.1 gibt einen Überblick über die Ergebnisse der Analyse. Die dort unter Metriken gelisteten Dimensionen des Rasters sind die wesentlichen Merkmale zur Leistungsbeurteilung von Datenbanken. In den unten näher beschriebenen Experimenten sind dies die primär zu bestimmenden Vergleichsparameter der Umsetzungsvarianten. 15

17 2.3 Grundlagen Die untere Hälfte Implementierung von Abbildung 2.1 deutet im Übrigen an, dass zum heutigen Zeitpunkt keines der existierenden Standardbenchmarks alle für das vorliegende Entscheidungsproblem relevanten Kriterien erfasst und somit die Entwicklung einer eigenen Vorgehensweise gerechtfertigt und notwendig ist. 2.3 Beschreibung von Anwendungsszenarien Unabhängig von der gewählten Entscheidungsunterstützung muss vor einer begründeten Datenbankauswahl zunächst Klarheit über einige grundlegende Fragen zum Anwendungsszenario geschaffen werden. Die zu beantwortenden Fragen sind den drei Kategorien Szenarienbeschreibung, Mengengerüst und Randbedingungen zuzuordnen. Allgemeine Beschreibung des Szenarios Welche Funktionalität soll die Anwendung erfüllen? Welche Akteure kommen in dem Szenario vor (z. B. Benutzer, Sensoren, andere Systemen/Anwendungen, )? Welche Aussagen können über die Struktur der Daten a priori getroffen werden (einfach, komplex, vernetzt, hierarchisch, verkettet, )? Stellt das Szenario besondere Anforderungen an die Datenhaltung? Aus welchen Gründen erscheint das Szenario sowohl für NoSQL- als auch für SQL-Datenbanken geeignet? Insbesondere welche Vorteile verspricht man sich vom Einsatz einer NoSQL- Datenbank aus einer bestimmten NoSQL-Klasse? Welche Nachteile können beim NoSQL-Einsatz entstehen und müssen evtl. kompensiert oder in Kauf genommen werden? Mit welchen anderen Anwendungsbereichen weist das Szenario Ähnlich - keiten auf und sind Querschlüsse zu dortigen Erfahrungen zulässig? Mengengerüst Wie viele Benutzer werden (in den verschiedenen Benutzerrollen) mit dem System arbeiten? Wie häufig tun sie dies? Wie viele Schreib- und Lese-Zugriffe sind aus den verschiedenen Anwendungsfällen zu erwarten? Wie geschäftskritisch ist das System und welche Verfügbarkeit soll in der Folge erreicht werden? Ist mit einer starken Zunahme der Datenmenge (oder der Zunahme anderer Anforderungen) während der Systemlebensdauer zu rechnen, z. B. durch inkrementelle Implementierung von Zusatzfunktionen? 16

18 2.3 Grundlagen Definition TPC-C YCSB Definition Metriken Wikipedia- NoSQL- Benchmark Cloudstone Malstone Consistency Benchmark Antwortzeit * Durchsatz * * Yield Harvest ** Reaktions-, Replikations-, Adaptionszeit Scaleout abb. 2.1 Einschlägige Datenbank-Benchmarks = unterstützt = nicht unterstützt o = nicht vorhanden + = vorhanden ++ = ausgeprägt * = ähnlich ** = geplant *** = Benchmark für spezifisches Datenbanksystem Speedout Fehlertoleranz ** Kosten pro Durchsatz Kosten pro Nutzer Verständlichkeit Applikationsszenario ++ o o Spezifikation ++ + o + + o Implementierung Skalierbarkeit Parametrisierbar Parallele Clients Übertragbarkeit NoSQL-Systeme *** NewSQL-Systeme Cloud-Storage-Systeme *** Konventionelle Systeme 17

19 2.3 Grundlagen Randbedingungen Sind Einschränkungen bzgl. der zur Verfügung stehenden Infrastruktur (Anzahl, Art, Kosten, ) abzusehen? Werden die Daten nur an einem Standort gehalten und verarbeitet oder liegt eine verteilte Infrastruktur vor? Besteht die Bereitschaft die ggf. anfallenden Lizenzgebühren überhaupt oder bis zu einem bestimmten Umfang zu tragen? Welche Betriebssysteme und Programmiersprachen können für das resul tie - rende System eingesetzt werden (ggf. getrennt zu betrachten für Clients und Server)? Sind für die Verwendung einer bestimmten Technologie die ausreichenden Kenntnisse vorhanden oder bestehen ggf. Bereitschaft und Ressourcen, sich diese anzueignen? Die Antworten auf einen Teil der aufgeführten Fragen stellen auch einen wesent - lichen Input in den im Folgenden beschriebenen Application-Mime Ansatz dar. 18

20 3 Der Application-Mime Ansatz Ein Application-Mime ist eine Software, die das typische Verhalten einer Zielanwendung in einem Anwendungsszenario für Evaluierungszwecke imitiert. Er muss daher dieselben funktionalen und nicht-funktionalen Anforderungen unterstützen, die das Szenario auch an die Zielanwendung stellt, kann aber eine völlig andere Realisierung aufweisen. Insbesondere werden mehrere Versionen eines Application-Mimes mit speziellem Fokus auf die Leistungseinflüsse gegenüber der Datenhaltung benötigt, wenn umfassende und aussagekräftige Vergleiche von SQL- und NoSQL-Datenbanken erzielt werden sollen. 3.1 Schritt 1: Application-Mime Entwicklung Schritt 1.1: Bestimmung der Anforderungen Der erste Schritt bei der Entwicklung eines Application-Mimes ist die Bestimmung der funktionalen und nicht-funktionalen Anforderungen aus dem Anwendungsszenario der Zielanwendung. Die Ableitung dieser Anforderungen erfolgt aus den entsprechenden Anwendungsfällen. Die Modellierung der Anwendungsfälle kann textuell oder mithilfe eines UML Use Case Diagramms (Rumbaugh u. a. 2010) erfolgen, wobei im Vordergrund steht, ein Gefühl für die Hauptverwendung der Anwendung und die hierfür notwendigen Anwendungsfunktionen zu gewinnen. Zugleich ist es wichtig, die nicht-funktionalen Anforderungen des Anwendungs - szenarios explizit zu machen. Beispielhafte Anforderungen könnten konsistente Daten, horizontale Skalierbarkeit oder Datenschutzerfordernisse sein, genauso wie der Einsatz einer bestimmten Programmiersprache oder andere Fragestellungen eher organisatorischer Natur. Es ist von besonderer Wichtigkeit, unter den genannten Anforderungen die Ausschlusskriterien zu erkennen. Diese stellen die wichtigste Informationsquelle bei der Auswahl derjenigen Datenbank-Kandidaten dar, die in der folgenden Eva - luierung genauer untersucht werden sollen. Qualitative Untersuchungen wie in Hecht u. Jablonski (2011) können diese Aufgabe weiter unterstützen. Die Erkenntnisse aus Schritt 1.1 sind für ein Anwendungsszenario allgemeingültig und gehen damit in die Entwicklung aller zugehörigen Application-Mimes ein. 19

21 3.1 Der Application-Mime Ansatz Schritt 1.2: Fokussierung des Application-Mimes Im Prinzip können Application-Mimes das generelle Verhalten einer Applikation nachahmen. Da sie jedoch in unserem Fall zur Entscheidungsunterstützung bei der Datenhaltungsauswahl eingesetzt werden sollen, muss hierauf auch bei der Entwicklung besonderes Augenmerk gelegt werden. Dies erfolgt durch eine eingehende Betrachtung der ausgewählten Kandidaten, bei der versucht wird, die Anforderungen des Anwendungsszenarios auf die entsprechenden funktionalen und nichtfunktionalen Fähigkeiten der Datenbank-Systeme abzubilden. Beispielsweise könnten gewöhnliche Datenbank-Operationen, wie das Verbinden von Datensätzen durch einen Join, in NoSQL-Datenbanken nicht äquivalent umgesetzt sein. Es bedarf also zusätzlichen Programmroutinen innerhalb der Anwendung um diese Lücke zu füllen. Dies ist auch ein Grund dafür, warum ein Vergleich von SQL- und NoSQL-Datenbanken auf Basis der sogenannten CRUD- Ope rationen (für Create, Read, Update und Delete) nicht stichhaltig sein kann. Die fehlende Funktionalität muss folglich auch in der NoSQL-Version des Application- Mimes implementiert werden. Auf der anderen Seite bringen die modernen NoSQL-Datenbanken teilweise auch hilfreiche und im Vergleich zu ihren SQL-Vorgängern überraschende Fähigkeiten mit. Falls diese Fähigkeiten die Anforderungen des Anwendungsszenarios adressieren und zur Architektur des Application-Mimes passen, dann sollten sie im Sinne eines fairen und nützlichen Vergleichs auch Eingang finden Schritt 1.3: Integration der Evaluierungsschicht Die Evaluierungsschicht ist der Teil des vereinfachten prototypischen Systems, der das Experiment antreibt und für die Messung des unter Beobachtung stehenden Teils des Application-Mimes verantwortlich ist. Für ihre Implementierung ist es zunächst wichtig, dass man diejenigen Anwendungsfälle identifiziert, die so exemplarisch sind, dass sie simuliert werden sollen. Von diesen Anwendungsfällen ist es abhängig, welche Funktionen und Prozesse im Application-Mime gemessen werden müssen und wie die Ergebnisse zu bewerten sind. Als nächstes muss festgelegt werden, wie die Simulation der Anwendungsfälle in der Evaluierungsschicht umgesetzt werden soll. Für diesen Zweck existieren eine Reihe von Frameworks, die zum Einsatz kommen können, wie das weit verbreitete JMeter der Apache Foundation (Halili 2008). Die Evaluierungsschicht stellt in Bezug auf ein Anwendungsszenario ein generisches Werkzeug dar, das in allen Versionen des Application-Mimes wieder - verwendet werden sollte, um vergleichbare Ergebnisse zu erzielen. Es bereitet die Ereignisse des Anwendungsszenarios vor, stößt diese an und es misst und bewertet die daraus resultierenden Aktionen. 20

22 3.2 Der Application-Mime Ansatz Schritt 1.4: Vervollständigen der Versionen Während der Fokussierung und Evaluierungsschichtimplementierung fängt das Gesamtbild der Application-Mime Versionen an, sich abzuzeichnen. Dennoch zeigen sich in diesem Bild vermutlich Lücken zwischen Datenhaltung und Evaluierungsschicht, die es nun auszufüllen gilt. Die fehlenden Funktionen werden in der Anwendungsschicht gebündelt, die das Verhalten der Anwendung gegenüber den zu untersuchenden Datenbanken nachahmt. Hierfür muss betrachtet werden, welche Funktionen vom Datenbank- System übernommen werden können (bzw. welche nicht) und wie die Evaluierungsschicht arbeitet und die Anwendungsschicht ansteuert. Die Lücken füllenden Bausteine komplettieren die Application-Mime Architektur. Als Folge der funktionalen Unterschiede zwischen den zu untersuchenden Datenbank-Systemen ist es erforderlich, diesen Teilschritt für alle Application-Mime Versionen zu wiederholen Schritt 1.5: Implementierung der Versionen Die Anwendungsschicht wird während der Experimente von der Evaluierungsschicht angesprochen, die ihrerseits versucht, das System unter hohe Last zu setzen. Daher ist es wichtig, bei der Realisierung der Anwendungsschicht auf horizontale Skalierbarkeit zu achten, weil es erforderlich sein kann, dass mehrere isolierte Instanzen gemeinsam auf die Datenbank zugreifen können. Eine weitere wichtige Überlegung bei der Implementierung der Versionen ist die Notwendigkeit, unabhängig vom jeweiligen Kandidaten seine Fähigkeiten so gut wie möglich auszureizen. Die unterschiedlichen in die Datenbank-Systeme eingebauten Fähigkeiten und die Abhängigkeiten zwischen funktionalen und nicht-funktionalen Eigenschaften können zu verfälschten und damit unbrauchbaren Ver gleichsergebnisse führen, wenn die Anwendungsschicht nicht im Hinblick auf die Datenbank optimal implementiert wurde. Folglich müssen alle verfügbaren Fähigkeiten vollständig ausgeschöpft und in der dafür vorgesehenen Weise eingesetzt werden. 3.2 Schritt 2: Aufbau des Testbeds Der Aufbau der Versuchsumgebung ( Testbed ) ist stark beeinflusst von der später für die Applikation vorgesehenen Infrastruktur. Um die Ergebnisse der Bewertungen so realistisch wie möglich zu machen, wäre es optimal, die Experimente direkt auf der späteren Infrastruktur auszuführen oder zumindest auf einer Infrastruktur die vergleichbaren technische und/oder finanziellen Einschränkungen unterliegt. Falls Experimente auf der Zielhardware nicht realisierbar sind, ist die Mindestanforderung, dass sie für alle Versionen auf identischer oder zumindest ähn licher 21

23 3.3 Der Application-Mime Ansatz Hardware durchgeführt werden, wobei sich die Ähnlichkeit in diesem Fall nicht unbedingt technisch, sondern eventuell sinnvollerweise besser finanziell bestimmen lässt. So wäre z. B. vorstellbar, dass eine SQL-Datenbank für ein bestimmtes Anwendungsszenario auf einem zentralisierten System mit hoher Speicherausstattung die besten Ergebnisse liefert, während die NoSQL-Version die höchste Leistung auf einem verteilten Cluster einfacher Knoten von identischen Gesamtkosten liefert. Diese Überlegung lässt sich von den Datenbanken, auch auf die Anwendungsund Evaluierungsschicht übertragen, wo sicherzustellen ist, dass die generierte Last für alle Versuchsaufbauten und -durchläufe gleich ist. Da es sich bei den Testbeds üblicherweise um verteilte Systeme handelt, müssen auch Netzwerk- und andere Infrastruktur-Komponenten wohlüberlegt gewählt werden. Andernfalls drohen Engpässe (engl. Bottlenecks) insbesondere zwischen Evaluierungs- und Anwendungsschicht, die zu verfälschten Ergebnissen führen können. Eine Option gegen die beschriebenen Engpässe ist die Integration von Instanzen der Evaluierungs- und Anwendungsschicht auf denselben Rechnerknoten. Dies senkt den Netzwerkverkehr und kann damit die mögliche Last auf den zu evaluierenden Datenbanken erhöhen. Aus der Erfahrung der eigenen Experimente (siehe Kapitel 4) soll festgehalten werden, dass die Hardware-Anforderungen an eine aussagekräftige Evaluierungsschicht nicht unterschätzt werden sollten. Moderne Datenbanksysteme sind überaus leistungsfähig und es bedarf umfangreicher Hardware auf Seiten der Evaluierungsschicht, um sie an die Leistungsgrenze zu führen, d. h. in den Bereich relevanter Untersuchungsergebnisse. 3.3 Schritt 3: Workload-Entwurf und Ausführung Die Belastung (engl. Workload), die von den Application-Mimes bewältigt werden soll, wird abgeleitet von den Anwendungsfällen des Anwendungsszenarios und wird daher von einer Reihe von Parametern beeinflusst. Das zu untersuchende Datenbank-System benötigt beispielsweise eine initiale Befüllung von ausreichendem Volumen und mit der notwendigen Komplexität, um eine Herausforderung für die Datenbank in Bezug auf Anzahl und Frequenz der Datenbank-Operationen darzustellen. Die Operationen hierfür werden wiederum indirekt von den Prozessen der Evaluierungsschicht angestoßen. Die Anzahl der Simulationsprozesse wird festgelegt durch die Menge der insgesamt verfügbaren Hardware und das Verhältnis, mit dem diese zwischen der Datenbank, der Applikationsschicht und der Evaluierungsschicht des Application- Mimes aufgeteilt werden soll. Da die Auswirkungen eines einzelnen Simulationsprozesses auf die Leistung des Application-Mimes a priori schwer zu bestimmen sind und für die verschiedenen Anwendungsfälle und Parametrisierungen des Anwendungsszenarios variieren können, kann die Ermittlung des Aufteilungsverhältnisses eine schwierige Aufgabe darstellen. 22

24 3.3 Der Application-Mime Ansatz Die Ergebnisse der Operation und auch deren Dienstgüteparameter werden innerhalb der Evaluierungsschicht gemessen und aufgezeichnet. Sie benötigt eine Schnittstelle zum Datenexport in einer interpretierbaren Darstellung. Zugunsten der Schlankheit der Application-Mimes und zur Aufwandsreduzierung ist der Einsatz generischer externer Werkzeuge zur Analyse und Visualisierung der Messwerte zu empfehlen. 23

25 4 Experimente Innerhalb des LEADS-Projektes wurden vier verschiedene Anwendungsszenarien konzipiert und umgesetzt. Die Anzahl ergab sich aus den vier prominenten unterschiedlichen NoSQL-Klassen (siehe Abschnitt 2.1.3). Jedes Anwendungsszenario wurde dann nach der Application-Mime Methode in einer SQL- und einer NoSQL- Version umgesetzt und vergleichend evaluiert. In diesem Kapitel werden die vier Anwendungsszenarien und die jeweiligen Experimente beschrieben. Deren Ergebnisse können sowohl eigenständig betrachtet werden, als auch als Illustration und Untermauerung des Application-Mime Ansatzes selbst. 4.1 Experiment 1: Project Relationship Management mit SQL und GDB Schritt 1: Application-Mime Entwicklung Es wird ein System zur Verwaltung von Projektbeziehungen entwickelt, das alle Daten, die innerhalb der Interaktionen zwischen Projektbeteiligten anfallen, integriert und im Kontext nutzbar macht. Die Interaktionen folgen dabei entweder vordefinierten Prozessen (z. B. bei einem Entwicklungsprojekt) oder können spontan erfolgen (z. B. bei Messekontakten oder telefonischen Nachfragen). Typische Daten, die innerhalb der Interaktionen anfallen, sind Dokumente wie Angebote, Verträge oder Rechnung, aber auch Kontaktdaten und Ansprechpartnerlisten. Der Zugang zu den Daten soll für verschiedene Anwenderrollen im Unternehmen geeignet sein, wie für Vertriebsmitarbeiter oder Controller. Aus dem beschriebenen Szenario entsteht ein komplexes Datenmodell mit eng vermaschten verschiedenartigen Beziehungen zwischen den Daten, den Workflows und den Benutzern. Der Zugriff auf die Daten muss sowohl navigierend als auch deskriptiv suchend möglich sein. Schritt 1.1: Bestimmung der Anforderungen Die Nutzer der Anwendungen sol - len über eine clientseitige Applikation folgende Funktionen ausführen können (siehe 4.1): ein Unternehmen anlegen und eine Unternehmensperspektive einnehmen aus Unternehmensperspektive Projekte erstellen, sich an Projekten beteiligen und die Beteiligung an bestehenden Projekten beenden 24

26 4.1 Experimente aus Unternehmensperspektive die offenen Bedarfe an Personenressourcen von Projekten ermitteln aus Unternehmensperspektive an einem Projekt beteiligte Unternehmen anzeigen aus Unternehmensperspektive an einem Projekt beteiligte Personen anzeigen aus Unternehmensperspektive Mitarbeiterprofile erstellen aus Unternehmensperspektive eigene Mitarbeiter und Projekte verlinken aus Unternehmensperspektive nach freien mittelbaren Personen (ohne Projekt- und Unternehmenslink) suchen ein Personenprofil anlegen und eine Personenperspektive einnehmen aus Personenperspektive andere Personen als Bekannte kennzeichnen aus Personenperspektive von eigens bekannten Personen andere bekannte Personen anzeigen Unternehmen 1 Unternehmen 2 abb. 4.1 PRM Anwendungsszenario beteiligt beteiligt beschäftigt Projekt 1 Bedarf beschäftigt P1 P2 P3 P4 P5 kennt kennt kennt kennt Neben diesen funktionalen Anforderungen sollen eine Reihe weiterer nicht-funktionaler Randbedingungen gelten: Programmiersprache: Als clientseitige Applikationssprache wird Java verwendet. Verfügbarkeit: Das System ist unternehmenskritisch und soll eine hohe Verfügbarkeit aufweisen, weshalb es die Daten repliziert und redundant vorhalten muss. Konsistenzanforderungen: Die Datenkonsistenz ist wichtig, da bspw. nicht in zwei unterschiedlichen Neuprojekten gleichzeitig dieselbe Person hinzugefügt werden soll. Datenmengen(prognose): Es wird erwartet, dass das Datenvolumen nicht sehr stark wächst. Es wird viel mehr vermutet, dass einzelne Unternehmensverbünde ein solches System gemeinsam pflegen würden, aber nicht unbedingt jedes andere hineinlassen. 25

27 4.1 Experimente Benutzerzahlen: Pro Unternehmensverbund wird mit eher gleichbleibender Benutzerzahl gerechnet, die nicht sehr hoch sein wird (im Vergleich zu Web- Szenarien). Lese- und Schreibzugriffe: Angenommen wird, dass wesentlich mehr Lese- als Schreiboperationen erfolgen, etwa im Verhältnis 10:1. Schritt 1.2: Fokussierung des Application-Mimes Aus den beschriebenen Nutzungsszenarien können in Bezug auf die erforderliche Unterstützung durch die Datenhaltung folgende generische Funktionen abgeleitet werden: Clientseitige Applikationen müssen auf ein (konzeptionell) zentrales Informationssystem zugreifen können. Es müssen Entitäten vom Typ Unternehmen mit dem Attribut Name persistent angelegt und gelöscht werden können. Es müssen Entitäten vom Typ Person mit dem Attribut Name persistent angelegt und gelöscht werden können. Es müssen Entitäten vom Typ Projekt mit dem Attribut Name und Bedarf persistent angelegt und gelöscht werden können. Die Entitäten müssen miteinander in Beziehung gebracht werden können: Unternehmen sind beteiligt an Projekten, Unternehmen können Personen als Mitarbeiter einstellen, Unternehmen können Mitarbeiter Projekten mit Bedarf zuweisen, Personen können andere Personen kennen. Es muss eine Suchfunktion nach frei verfügbaren Personen implementiert werden, die über mehrere Personen iterieren kann und unterschiedliche Entitätentypen als Ausgangspunkt bietet. Aufgrund der vielen Abhängigkeiten und der graphartigen Anordnung der Daten soll eine relationale Datenbank (MySQL) mit einer Graphdatenbank (Neo4j) ver - glichen werden. Schritt 1.3: Integration der Evaluierungsschicht In beiden Application-Mimes sollen die verschiedenen beschriebenen Funktionen des Anwendungsszenarios als Applikationslogik innerhalb einer Testapplikation auf Basis von Apache JMeter ohne eine graphische Ausgabe implementiert werden, die für einen Test der Datenbanken nicht relevant wäre. Mit einer definierten Abfolge von realistisch nachgebildeten Funktionen wird das Informationssystem belastet und die interessanten Parameter werden erfasst. Schritt 1.4: Vervollständigen der Versionen MySQL: Das relationale Schema (siehe Abbildung 4.2) zeichnet sich besonders durch die vielen erforderlichen Beziehungsrelationen zwischen den Entitäten aus, die aus den n:m-beziehungen zwischen diesen resultieren. 26