Inhaltsverzeichnis
Werbung
Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Hochschule: Standort: Studiengang: Veranstaltung: Betreuer: Typ: Themengebiet: Autor(en): Studienzeitmodell: Semesterbezeichnung: Studiensemester: Bearbeitungsstatus: Prüfungstermin: Abgabetermin: Fallstudienarbeit Hochschule für Oekonomie & Management Berlin Bachelor Wirtschaftsinformatik Fallstudie / Wissenschaftliches Arbeiten Prof._Dr._Ralf Hötling Fallstudienarbeit Eine NoSQL-Evaluierung als flexiblere Alternative zu einem RDBMS. Boddin, D.; Franke, P.; Beckers, J.; Wiatr, S. Abendstudium SS12 2 Bearbeitung abgeschlossen 30.08.2012 Inhaltsverzeichnis • 1 Abkürzungsverzeichnis • 2 Abbildungsverzeichnis • 3 Tabellenverzeichnis • 4 Einleitung ♦ 4.1 Inhaltliche Einführung ♦ 4.2 Motivation ♦ 4.3 Fragestellung ♦ 4.4 Abgrenzung ♦ 4.5 Zur Methode ♦ 4.6 Nicht behandelte angrenzende Probleme ♦ 4.7 Zielstellung • 5 Grundlagen ♦ 5.1 Skalierung ◊ 5.1.1 Vertikale Skalierung ⋅ 5.1.1.1 Vorteile ⋅ 5.1.1.2 Nachteile ◊ 5.1.2 Horizontale Skalierung ⋅ 5.1.2.1 Vorteile ⋅ 5.1.2.2 Nachteile ⋅ 5.1.2.3 Fehlannahmen bei der Skalierung ♦ 5.2 Datenbanken ♦ 5.3 ACID ◊ 5.3.1 Einsatzgebiete ♦ 5.4 CAP Theorem ◊ 5.4.1 Consistency Inhaltsverzeichnis 1 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL ◊ 5.4.2 Availability ◊ 5.4.3 Partition tolerance ⋅ 5.4.3.1 Beispiele • 5.4.3.1.1 CA ? Consistency & Availability • 5.4.3.1.2 CP ? Consistency & Partition tolerance • 5.4.3.1.3 AP ? Availability & Partitiontolerance ♦ 5.5 BASE ◊ 5.5.1 Fazit ♦ 5.6 Multiversion Concurrency Control (MVCC) ♦ 5.7 Vector Clocks • 6 Problemstellung ♦ 6.1 Ist Zustand ◊ 6.1.1 Datenstrukturen ◊ 6.1.2 Datennavigation ◊ 6.1.3 CAP-Abwägung ◊ 6.1.4 Relationales Datenbankmodell ♦ 6.2 Anforderungen an das DBMS • 7 Architekturen ♦ 7.1 Dokumentenorientierte Datenbanken ◊ 7.1.1 Allgemeiner Verwendungszweck ◊ 7.1.2 Datenmodell ◊ 7.1.3 Vergleich zu RDBMS ◊ 7.1.4 Vor-/Nachteile ◊ 7.1.5 API ◊ 7.1.6 Produkte ♦ 7.2 Wide Column Store ◊ 7.2.1 Allgemeiner Verwendungszweck ◊ 7.2.2 Datenmodell ◊ 7.2.3 Vergleich zu RDBMS ◊ 7.2.4 Vor-/Nachteile Inhaltsverzeichnis 2 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL ◊ 7.2.5 API ◊ 7.2.6 Produkte ♦ 7.3 Objektorientierte Datenbanken ◊ 7.3.1 Allgemeiner Verwendungszweck ◊ 7.3.2 Datenmodell ◊ 7.3.3 Vergleich zu RDBMS ◊ 7.3.4 Vor-/Nachteile ◊ 7.3.5 API ◊ 7.3.6 Produkte ♦ 7.4 Architektur-/Datenbankevaluierung • 8 Auswertung ♦ 8.1 Die Featurematrix ♦ 8.2 Lizenzmodell ♦ 8.3 ACID/BASE ? Spektrum ♦ 8.4 Datentypen ♦ 8.5 Support ♦ 8.6 Dokumentation ♦ 8.7 API ♦ 8.8 Skalierbarkeit ♦ 8.9 Umgebung ♦ 8.10 Administration ♦ 8.11 Erweiterbarkeit ♦ 8.12 Abfragemöglichkeiten ♦ 8.13 Auswertung • 9 Fazit ♦ 9.1 Evaluierungsphase ♦ 9.2 Wirtschaftlichkeit ♦ 9.3 Ausblick • 10 Fußnoten • 11 Literatur- und Quellenverzeichnis 1 Abkürzungsverzeichnis Abkürzung ACID API BASE BSON CAD CAP CMS DBMS EDV Bedeutung Atomicity, Consistency, Isolation, Durability application programming interface Basically Available, Soft state, Eventual consistency Binary JavaScript Object Notation computer-aided design Consistency, Availability, Partition tolerance Content Management System Datenbankmanagementsystem Elektronische Datenverarbeitung 1 Abkürzungsverzeichnis 3 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL ER ERP ID IT JSON MVCC NoSQL OLAP OODB OOP RDBMS SQL WCS Entity Relationship Diagramm Enterprise Resource Planning Identifier information technology - Informationstechnologie JavaScript Object Notation Multiversion concurrency control Not only SQL Online Analytical Processing Objekt orientierte Datenbank Objekt orientierte Programmierung Relationales Datenbankmanagementsystem Structured Query Language wide column store 2 Abbildungsverzeichnis Abb.-Nr. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Abbildung steigende Datenanforderungen Datensatz mit vier Versionen Speichervorgang im MVCC Verfahren Konflikterkennung mittels Vector Clocks ER: Verbindungstabelle ER: Untertabelle Beispiel ER Diagramm Abbildung der Dokumente (JSON-Format) Blogeintrag - RDBMS vs. dokumentenorientierte Datenbank WideColumnStore Column Family Umsetzung eines ER in Wide Column Store Ein Objekt Auto in Assoziation mit einem weiteren Objekt Rad, http://www.matthiasmaas.de/info_klasse10_oom.gif,23.05.2012 Der Impedance Missmatch links und rechts die barrierefreie Importierung eines Objektes in eine objektorientierte Datenbank http://www.db4o.com/s/csharpdb.aspx, 26.07.2012 Balkendiagramm für die Auswertung der Featurematrix 3 Tabellenverzeichnis Tabelle Nr. 1 2 3 4 5 Quelle WideColumnStore - Relationale DBMS Anordnung von Daten WideColumnStore - Anordnung von Daten Featurematrix Auswertung der Lizenzmodelle Auswertung des ACID/BASE-Spektrums 2 Abbildungsverzeichnis 4 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 6 7 8 9 10 11 12 13 14 Auswertung der Datentypen Auswertung des Supports Auswertung der Dokumentationen Auswertung der API Auswertung der Skalierbarkeit Auswertung der Umgebung Auswertung der Administrationskomponenten Auswertung der Erweiterbarkeit Auswertung der Abfragemöglichkeiten 4 Einleitung 4.1 Inhaltliche Einführung Im Rahmen einer Fallstudie für die FOM-Berlin wird untersucht, ob es eine Alternative zur relationalen Datenspeicherung der Firma Synectic gibt. Gleichzeitig soll damit ein Leitfaden für diesen Evaluierungsprozess entstehen, welchen man durch austauschen gewisser Parameter für ähnliche Fälle verwenden kann. 4.2 Motivation Abbildung 1: steigende Datenanforderungen Mittlerweile finden digitale Daten in immer mehr Lebensbereichen Anwendung und den größten Bereich bildet das World Wide Web. Seit dem Start von ?Web 2.0? und den damit entstandenen Möglichkeiten im World Wide Web wird der Inhalt nicht mehr nur primär durch die jeweiligen Website-Betreiber bzw. Unternehmen geliefert, sondern jeder hat die Möglichkeit, Inhalte in Form von Blogs, Wikis, Communitys, Micro-Blogs, Foren, Portalen oder Social-Media-Netzwerken aktiv bereitzustellen. Mit derzeit 955 Millionen aktiven Benutzern im Monat[1] und Tendenz steigend verdeutlicht Facebook sehr gut, dass die mit Web 2.0 gestartete ?Mitmach-Gesellschaft? immer weiter zunimmt und permanent neue Daten bereitstellt. Basierend auf der Digital Universe Studie von 2011, welche vom Marktforschungsunternehmen International Data Corporation durchgeführt wurde, existiert ? Stand Juli 2011 ? ein weltweit digitales Datenvolumen von 1,8 Zettabyte (1021 Byte)[2]. Dieser Wert, im Verhältnis zur aktuellen Weltbevölkerung von 6,987 Milliarden[3] Menschen, entspricht 283 Gigabyte an Daten pro Mensch. Neben dem permanent wachsenden Datenvolumen steigen auch die Anforderungen im Hinblick auf die Verfügbarkeit der digitalen Daten. Im Laufe der nächsten zehn Jahre, bis 2020, wird sich die Zahl der Server verzehnfachen und das Datenvolumen, welches sich voraussichtlich um das 50-fache erhöhen wird, muss effizient gespeichert und verwaltet werden[4]. Daher müssen Mittel und Wege für das Speicher- und Informationsmanagement gefunden werden, um mit den steigenden Anforderungen Schritt halten zu können. 4 Einleitung 5 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 4.3 Fragestellung IT-Unternehmen werden sich zunehmend mit der Beantwortung den folgenden Fragen beschäftigen müssen: • Wie kann das immer größer werdende Datenvolumen gemeistert werden? • Wie wird ein hoher Grad an Verfügbarkeit erreicht? • Wie lassen sich Daten bestmöglich partitionieren? • Wie lassen sich die gegebenen Probleme bestmöglich lösen? 4.4 Abgrenzung NoSQL ist kein moderner Begriff, doch im Zuge des Datenwachstums und der daraus resultierenden Probleme gerät der Begriff oder sogar das Denken mehr und mehr in den Fokus der IT-Branche. Somit zielt dieser hier dargestellte Evaluierungsprozess auf die Ermittlung eines geeigneten NoSQL-Produktes, auf Grundlage einer konkreten Problemstellung, ab. 4.5 Zur Methode Zunächst muss die Problemstellung klar definiert werden. Davon ausgehend wird im vielseitigen Angebot der Datenbanken recherchiert. Viele DBMS lassen sich aufgrund ihrer fundamentalen Eigenschaften ausschließen und somit lässt sich nach vielen Untersuchungen eine Menge von Architekturen finden, welche ein gewisses Potenzial besitzen. Diese Architekturen werden auf ihre Vor- und Nachteile untersucht. Ausgehend der Entscheidung über die Architektur müssen die Produkte untersucht werden. In der Regel entscheidet man sich für die gängigen Produkte. Die Auswahl eines Produktes erfolgt anhand einer Featurematrix, die nach Kriterien der Problemstellung strukturiert ist. Diese Matrix ist das Mittel, auf das man nicht verzichten sollte. Sie ist in verschiedene Kategorien unterteilt und diese Kategorien werden mit Gewichtungen versehen. Je nach Grad der Erfüllung eines Kriteriums sammeln die Produkte Punkte. Das Produkt mit den meisten Punkten wird ausgewählt. 4.6 Nicht behandelte angrenzende Probleme Diese Arbeit beschäftigt sich ausschließlich mit dem Evaluierungsprozess und behandelt nicht eine gesamte Umwandlung von Datenspeichermedium und Softwareprodukt. Ebenfalls wird nicht untersucht, ob die Möglichkeit eines Umstieges sinnvoll wäre. 4.7 Zielstellung Zielstellung dieser Studie soll sein, IT-Unternehmen bei zukünftigen Projekten eine Handlungshilfe für Evaluierungskonzepte in Bezug auf eine mögliche Portierung in eine NoSQL-Datenstruktur zur Verfügung zu stellen. 4.3 Fragestellung 6 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 5 Grundlagen Folgend werden zum besseren Verständnis wichtige und grundlegende Themen erläutert. 5.1 Skalierung ?Einfach ausgedrückt ist es die Fähigkeit einer Anwendung wachsende Anforderungen an Durchgang, Nutzung und Kapazität zu verkraften. Sowohl horizontale als auch vertikale Skalierungsstrategien dienen der Fähigkeit eines Systems dieses Wachstum zu verkraften.? [5] 5.1.1 Vertikale Skalierung Die vertikale Skalierung ist die bekannteste und auch am einfachsten umzusetzende Skalierung. Im Großen und Ganzen fußt sie auf den Einsatz von noch leistungsstärkeren Komponenten. 5.1.1.1 Vorteile Vertikal skalierte Systeme sind einfacher zu warten, da hier keine Interdependenzen zu anderen Systemen bestehen. So müssen bestehende Anwendungen nicht umgeschrieben werden, sondern können wie gewohnt weiterhin eingesetzt werden. Dadurch, dass vertikal skalierte Systeme i.d.R monolithisch sind, besteht eine geringere Gefahr für Konsistenzprobleme. 5.1.1.2 Nachteile Die Einfachheit des Systems hat jedoch ihren Preis. Um die geforderte Leistung erbringen und die Ausfallgefahr gering halten zu können, ist der Einsatz von hochwertiger und somit teurer Hardware erforderlich. Diese Hardware muss in Anbetracht der Zukunftsfähigkeit mit Leistungsreserven angeschafft werden, was sich natürlich auch preislich niederschlägt.[6] Darüber hinaus sind oft Speziallösungen notwendig, um die Gesamtheit der bestehenden Ressourcen ausnutzen zu können. Da die vertikale Skalierung durch die Verfügbarkeit und Existenz von leistungsfähigen Komponenten abhängt, ist ihr ein natürliches Limit gesetzt. Dadurch werden diese Systeme am Ende ihrer Lebenszeit oft am äußersten Limit betrieben, was weitere Probleme nach sich ziehen könnte. Aus diesem Grund bietet es sich an, die Möglichkeit der horizontalen Skalierung zu betrachten. 5.1.2 Horizontale Skalierung Bei der horizontalen Skalierung wird, im Gegensatz zur vertikalen Skalierung, keine qualitative Steigerung der Leistungsfähigkeit angestrebt, sondern eine quantitative. Plakativ ausgedrückt kann man sagen, dass hier statt einem großen leistungsfähigen Rechner, mehrere weniger leistungsfähigere Rechner eingesetzt werden. Durch Nutzung horizontaler Skalierung ist es auch möglich, eine effiziente Regionalisierung zu realisieren. In Zeiten der Globalisierung haben Services heute häufig eine weltweite Verbreitung. Damit die geographisch verstreuten Anwender zuverlässig und mit möglichst geringen Latenzzeiten bedient werden können, ist eine lokale Platzierung von Servern von Vorteil. Ein weiterer häufiger Grund für die horizontale Skalierung ist der Ausfallsicherheit geschuldet. Dies kann sich zum einen auf die einzelnen Komponenten des Rechners beziehen, sprich Hard- und Software, aber auch auf den Ausfall von Übertragungswegen. 5 Grundlagen 7 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 5.1.2.1 Vorteile Einer der Hauptvorteile der horizontalen Skalierung ist, dass hier preiswerte Standard Hardware zum Einsatz kommen kann, die genau den aktuellen Bedürfnissen entspricht. Es ist hier nicht nötig in große Leistungsreserven zu investieren.[7]Durch die Möglichkeiten der breiteren Aufstellung und Replizierung von Daten kann die Ausfallgefahr in Bezug auf Störungen der Übertragungswege minimiert werden. Da die eingesetzte Hardware i.d.R. keine großen Besonderheiten aufweist, können meist Standardlösungen eingesetzt werden. 5.1.2.2 Nachteile Oft ist es nicht trivial ein bestehendes vertikales System horizontal zu skalieren. Hierfür ist meistens ein nicht zu unterschätzender konzeptioneller Aufwand nötig. Die Entscheidung wie streng mit Konsistenz umgegangen werden soll, muss in dieser Phase der Entwicklung geschehen. Es müssen Wege gefunden werden, wie bestehende Anwendungen in das horizontal skalierte System integriert werden können. Nicht alle Anwendungen sind auf dieses Modell eingerichtet. Aufgrund der nicht zu vermeidenden Interdependenzen sind horizontale Systeme schwerer zu warten. Insbesondere dann, wenn die einzelnen Teilsysteme von verschiedenen Personen administriert werden. Dieser Punkt führt uns direkt zu den Fehlannahmen, die bei der Skalierung bestehen. 5.1.2.3 Fehlannahmen bei der Skalierung Häufig scheitern horizontale Skalierungen aufgrund konzeptioneller Mängel. Hierbei ist zu beobachten, dass während der Konzeption bestimmte Fehlannahmen getätigt werden, die dadurch den beabsichtigten Erfolg verhindern. Bei diesen Fehlannahmen werden meist einzelne Aspekte im Bezug auf Konsistenz, Ausfallsicherheit oder Verfügbarkeit getätigt. Dies kann sich im Einzelfall auch nur auf die Einschätzung des individuellen Eintrittsrisikos beziehen. Eine häufige Annahme ist es, dass bei einem verteilten System alle Teile stets verfügbar sind und sich diese in einem konsistenten Zustand untereinander befinden. Wir werden hierauf im späteren Verlauf der Arbeit im Rahmen des CAP Theorems zurückkommen. Weitere häufige Fehlannahmen sind: • Das Netzwerk ist ausfallsicher. • Die Netzwerklatenzzeit ist gleich Null. • Datensatz ist unendlich. • Das NW ist sicher. • Die NW-Topologie ändert sich nicht. • Es gibt nur einen NW Administrator. • Das Netzwerk ist homogen[8]. 5.2 Datenbanken Eine Datenbank ist eine Sammlung von logisch schlüssigen Daten, die eine eigenständige Bedeutung haben. Datenbanken werden ausgehend von ihrem beabsichtigten Einsatzzweck erstellt. Die vorausgehende Konzeption richtet sich hierbei nach den Bedürfnissen der Nutzer und den geplanten Anwendungen. Deren Ziel es ist, eine abstrahierte Abbildung eines fest umgrenzten Bereiches der realen Welt zu erschaffen (?Miniwelt?). Änderungen in dieser Miniwelt müssen sich in den Datensätzen der Datenbank widerspiegeln, damit die darauf zugreifenden 5.1.2.1 Vorteile 8 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Anwendungen jederzeit genau und zuverlässig arbeiten können. Die hierfür konstruierten Datenbanken können eine beliebige Größe und Komplexität erreichen. Diese Komplexität entsteht z.B. dadurch, dass eine Änderung der realen Welt durch viele interdependente Operationen in der Datenbank abgebildet wird. Transaktionen sind ein probates und erprobtes Mittel, um dieser Komplexität Herr zu werden und einen konsistenten Zustand der Datenbank zu gewährleisten. Hierzu werden die nötigen Einzelschritte (Operationen) zu Transaktionen zusammengefasst. Relationale Datenbank Systeme beruhen auf dem ACID-Prinzip.[9] 5.3 ACID ACID beschreibt die Kernprinzipien der Architektur von transaktionsbasierten RDBMS. Transaktionen sind eine Folge von Operationen und Handlungen, die den Anspruch haben, entweder ganz oder gar nicht ausgeführt zu werden (COMMIT oder ROLLBACK/ABORT). Transaktionen bestehen aus fünf aufeinander folgenden Schritten: • BEGIN_TRANSACTION läutet den Start einer Transaktion ein. • READ or WRITE beinhaltet beliebig viele Lese- oder Schreiboperationen, die auf der Datenbank ausgeführt werden sollen. • END_TRANSACTION markiert den Abschluss der gewünschten Operationen und damit das Ende der Transaktion. Jetzt wird überprüft, ob die Transaktion dauerhaft gespeichert oder verworfen wird. Dies erfolgt entweder durch • COMMIT_TRANSACTION veranlasst eine dauerhafte Veränderung der Daten. Oder • ROLLBACK (or ABORT) signalisieren ein Scheitern der Transaktion. Nun müssen alle Änderung an der Datenbank rückgängig gemacht werden. Die vorgenannten Schritte werden durch den recovery manager der Datenbank ermöglicht. Dieser protokolliert die einzelnen Operationen der Transaktion, um diese abschließend im Gesamten auszuführen oder bei einem Scheitern den ursprünglichen Zustand der Datenbank wiederherzustellen.[10] Durch die Anwendung von Transaktionen nach dem ACID-Prinzip soll ausschließlich Konsistenz gewährleistet werden. ACID ist dann gewährleistet, wenn die folgenden vier Transaktionseigenschaften erfüllt wurden: • Atomicity ? Atomarität (Abgeschlossenheit): Jede Operation in einer Transaktion ist vollständig abgeschlossen (oder es ist gar keine, wie z.B. bei Rollback). • Consitency ? Konsistenz: Bei Transaktions-Start und -Ende ist die Datenbank in einem konsistentem Zustand. • Isolation ? Abgrenzung: Die Transaktion verhält sich so, als wäre sie die einzige Operation die auf der DB ausgeführt wird. • Durability ? Dauerhaftigkeit: Ist eine Transaktion einmal abgeschlossen, wird sie nicht mehr rückgängig gemacht.[11] 5.3.1 Einsatzgebiete Als klassisches Transaktionsmodell ist ACID heute bei Anwendungen in nahezu allen Einsatzgebieten anzutreffen. Naturgemäß können deren Ansprüche nicht immer gleich gut erfüllt werden. Als häufig angegebenes Beispiel, wo die ACID-Prinzipien optimal umgesetzt werden können, ist der Einsatz im Finanzsektor. Hier hat die 5.2 Datenbanken 9 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Gewährleistung von Transaktionssicherheit und Konsistenz allerhöchste Priorität. Eine z.B. nur teilweise Ausgeführte, oder nicht dauerhaft gespeicherte Überweisung hätte hier fatale Auswirkungen. Dasselbe gilt z.B. beim Einsatz in ERP-Systemen. Aufgrund der starken EDV-Abhängigkeit heutiger Unternehmen, würde eine inkonsistente Datenbank zu enormen Schwierigkeiten, bis hin zum finanziellen Ruin, führen. Eine weitere, nicht zu unterschätzende, Gefahr ist der komplette oder teilweise Verlust von Daten, wie er z.B. durch Hardwareschäden entstehen könnte. Aus diesem Grund sollten Datenbanken, deren ganz oder teilweiser Verlust existenzgefährdend ist, partitionstolerant konzipiert und betrieben werden. ACID stößt dort an seine Grenzen, wo die Datenbank nicht mehr unabhängig und homogen ist. Dies trifft insbesondere bei horizontal skalierten Systemen zu. Erste Versuche verteilte Datenbanksysteme zu entwickeln, die den ACID Prinzipien gerecht werden, wurden schon in den 1980er Jahren unternommen. Bis zum heutigen Tag konnte keines der seither entwickelten Systeme diesen Anspruch in Gänze erreichen[12]. Bis zur Mitte der 90er Jahre wurde das Ziel, eine ACID-Konforme verteilte Datenbank zu entwickeln, nicht in Frage gestellt. Bis dahin war die Aufgabe der Konsistenz als oberstes Ziel so verpönt, dass Entwickler eher ein Scheitern im Gesamten vorzogen, als hier hingehend Abstriche zu machen. Erst der Aufstieg des Internets führte zu einem Umdenken. Einen weiteren Wendepunkt bildete die Veröffentlichung des CAP-Theorems durch Eric Brewer. Nun wurde Verfügbarkeit zur wichtigsten Eigenschaft[13]. 5.4 CAP Theorem Das CAP Theorem ist eine von Eric Brewer im Jahr 2000, unter dem Titel 'Towards Robust Distributed Systems'[14] vorgestellte Theorie, die besagt, dass in verteilten Datenbanksystemen von den drei Eigenschaften, Konsistenz, Verfügbarkeit und Ausfalltoleranz nur zwei beliebige gleichzeitig erreicht und garantiert werden können. Brewers Theorie wurde 2002 von Seth Gilbert und Nancy Lynch formal bewiesen[15]. Im Einzelnen erläutert Brewer in seinem Theorem die Unmöglichkeit der gleichzeitigen Erfüllung aller Eigenschaften und die Notwendigkeit sich für zwei Merkmale zu lasten des Dritten zu entscheiden. Die hier gesetzten Schwerpunkte können im Einzelfall, auch in der selben Anwendung, variieren. Hierzu gilt: ?Pick any two? der folgenden Eigenschaften. 5.4.1 Consistency Konsistenz (Consistency) bedeutet, dass die von der Datenbank auf eine Abfrage zurückgelieferten Daten in sich stimmig und widerspruchsfrei sind. Dies muss nicht zwangsläufig bedeuten, dass die in der Datenbank gespeicherten Informationen widerspruchsfrei sind. Eine verteilte Datenbankanwendung ist dann konsistent, wenn eine bestimmte Abfrage zum Zeitpunkt T0 an allen Knoten dasselbe Ergebnis zurückliefert, selbst dann, wenn gleichzeitige Schreibvorgänge stattfinden. Insbesondere bei sehr großen horizontal skalierten Systemen ist diese Eigenschaft nur mit großem Aufwand zu realisieren. ?In der Praxis würde dies bedeuten, dass der geänderte Wert erst dann wieder gelesen werden kann, wenn alle replizierenden Knoten aktualisiert sind, was bei einem sehr großen Cluster mit vielen Knoten und einer hohen durchschnittlichen Last dauern kann?[16] 5.3.1 Einsatzgebiete 10 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 5.4.2 Availability Verfügbarkeit (Availability) bezeichnet eine akzeptable Reaktionszeit. Was akzeptabel ist, kann von Anwendung zu Anwendung variieren. Verfügbarkeit (Availability) ist hier von Zuverlässigkeit (Reliability) abzugrenzen. Zuverlässig ist ein System dann, wenn es während der Zeitspanne seines Einsatzes im Rahmen seiner Anforderungen ?tut was es soll?. Verfügbarkeit zeichnet sich durch Zuverlässigkeit zu einem speziellen Zeitpunkt aus (i.d.R. wenn der Service benötigt wird). Zuverlässigkeit wird hier unterstellt und ist die Basis für die Verfügbarkeit eines Systems. Für viele E-Commerce-Anwendungen ist Verfügbarkeit ein kritisches Systemmerkmal, welches einen direkten Einfluss auf die Geschäftsentwicklung hat. Beispielsweise sinkt der Umsatz von Amazons Buchhandel spürbar, wenn sich die Reaktionszeit beim Bestellvorgang aus technischen Gründen nur kurzzeitig verzögert. Ein verfügbares System muss eine für den konkreten Anwendungsfall akzeptable Reaktionszeit aufweisen. Diese muss bis zu einer vordefinierten Last eingehalten werden können, da die Erfahrung zeigt, dass Reaktionszeiten dann akzeptable Werte unterschreiten, wenn die Last der Anfragen ansteigt. [17] [18] 5.4.3 Partition tolerance Ausfalltoleranz (Partition tolerance) bedeutet, dass der Ausfall eines Knotens oder einer Kommunikationsverbindung zwischen den Knoten einer verteilten Datenbank nicht zum Ausfall des gesamten Systems führt, sondern das System weiterhin auf Anfragen von außen reagieren kann. Gerade für Webunternehmen ist es daher unverzichtbar, dass eine verteilte Datenbank solche Ausfälle abfangen kann.[19] 5.4.3.1 Beispiele Für die Verständlichkeit des CAP-Theorems sind im Folgenden drei Beispiele aufgeführt. 5.4.3.1.1 CA ? Consistency & Availability Die klassischen RDBMS sind in diesem Bereich des Cap-Theorems zu finden. Hierbei werden die Daten nach dem ACID-Prinzip verwaltet. Diese Datenbanken sind in der Regel unabhängig und nicht ausfallsicher. Das bedeutet nicht, dass hier z.B. keine Datensicherung gemacht wird, sondern eher das diese Datensicherung nicht jederzeit konsistent ist. Es handelt sich hier eher um eine Schadensminimierung als um eine Gewährleistung des nahtlosen Weiterbetriebs bei einem Teilausfall des Systems. Besteht der Anspruch darin, dass auch die replizierten Daten immer konsistent sind, ist dies nur durch einen zumindest zeitweisen Verzicht auf Verfügbarkeit realisierbar. 5.4.3.1.2 CP ? Consistency & Partition tolerance Das wohl einleuchtendste Beispiel in dem die beiden Eigenschaften Konsistenz und Ausfalltoleranz gleichzeitig gegeben sein müssen, ist der bereits erwähnte Finanzsektor. Ein Verlust von Daten oder das Auftreten eines inkonsistenten Zustands wäre hier fatal. Aus diesem Grund ist es hier angebracht, im Zweifel auf eine Verfügbarkeit des Dienstes zu verzichten, wenn entweder die Konsistenz oder die Partitionstoleranz nicht garantiert werden können. Ein Geldautomat, der nicht sicherstellen kann, dass die von ihm empfangene Daten konsistent sind oder nicht in der Lage ist, die Veränderung des Kontostandes ausfallsicher zu speichern, wird somit den Dienst verweigern. Der hieraus entstehende Schaden ist im Verhältnis zum Verlust von Daten oder Inkonsistenz fast unbedeutend. 5.4.2 Availability 11 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 5.4.3.1.3 AP ? Availability & Partitiontolerance Für viele auf Internetseiten verbreitete Informationen ist Konsistenz kein kritisches Merkmal. Insbesondere bei Onlineshops und sozialen Netzwerken genießen Verfügbarkeit, Geschwindigkeit und Ausfallsicherheit die höchste Priorität. Manchmal wäre eine zu strenge Konsistenz sogar schädlich. Dies ist zum Beispiel bei Onlineshops gegeben, die ihren Kunden Transparenz über ihre aktuellen Lagerbestände verschaffen möchten. Würde dieser z.B. neu berechnet werden, sobald ein Kunde einen Artikel in seinen Warenkorb legt, könnte dies dazu führen, dass gleichzeitig einem anderen interessierten Kunden dieses Produkt als nicht mehr verfügbar angezeigt wird. Da man sich nie sicher sein kann, ob ein Kunde den Bestellvorgang abschließt, ist es in diesem Fall praktikabler. beiden Kunden zu ermöglichen, das Produkt in Ihren Warenkorb zu legen und ggf. einem der Kunden im späteren Verlauf eine Fehlermeldung anzuzeigen. Ein in der Literatur häufig angegebenes Beispiel für eine verteilte AP-Architektur ist der DNS Dienst. Der Verzicht auf eine strenge Konsistenz ermöglicht hier eine einfache horizontale Skalierung. 5.5 BASE Bei BASE dreht sich, im Gegensatz zu ACID alles um Verfügbarkeit und Partitionstoleranz. Um diesen AP Ansatz gewährleisten zu können, werden die Anforderungen der Konsistenz der Daten gelockert. Konsistenz wird innerhalb von BASE, im Unterschied zu ACID, nicht als fester Zustand nach Ende einer Transaktion gesehen, sondern als Übergangsprozess. Systeme, die nach BASE arbeiten, erreichen auch irgendwann den Status der Konsistenz, die Betonung liegt dabei aber auf irgendwann, i.d.R. in einem der Anwendung angemessenem Zeitraum. In der Praxis bedeutet dies, dass z.B. bei einem Update eines Datensatzes verschiedene Knoten zeitweise unterschiedliche Ergebnisse zurück liefern. Dieser Zeitraum wird als 'inconsistency window' bezeichnet.[20] BASE setzt sich aus folgenden Begriffen zusammen: Basicly available,was bedeutet, dass die Applikation grundsätzlich immer verfügbar ist, gefolgt von soft stated, womit gemeint ist, dass die Datenbank nicht immer in einem konsistenten Zustand sein muss, in etwa stimmende Daten sind akzeptabel. Zuletzt eventualy consistent, was dafür steht, dass die Applikation ihren aktuellen Zustand kennt. Die Applikation weiß, dass die Konsistenz der zurückgelieferten Daten nicht garantiert ist. 5.5.1 Fazit Das CAP-Theorem ermöglicht uns den Blick auf das Spektrum zwischen Konsistenz und Verfügbarkeit. Hierbei bilden ACID & BASE die jeweiligen Pole.[21] Dies ist i.d.R. jedoch nicht ohne Einbußen der Praktikabilität erreichbar. Wie so oft liegt auch hier die Wahrheit, je nach Anwendungsfall, irgendwo dazwischen. Mal näher am einen, mal näher an dem anderen Pol. Gemäß des CAP-Theorems können in einem verteilten System maximal zwei der drei Eigenschaften Konsistenz, Verfügbarkeit und Ausfalltoleranz zum selben Zeitpunkt garantiert werden. Deshalb muss anhand der jeweiligen Problemstellung entschieden werden, welche der drei Eigenschaften die geringste Priorität hat, um diese vernachlässigen zu können. Das Verständnis des CAP-Theorems ist elementar, um bei der Planung die richtigen Entscheidungsgrundlagen zu haben und sich nicht in unerreichbaren Idealvorstellungen zu verrennen und ?... zentral für das Verständnis der Veränderungen, die in der Datenbankwelt aktuell durch die NoSQL-Bewegung vor sich gehen.?[22] 5.4.3.1.3 AP ? Availability & Partitiontolerance 12 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 5.6 Multiversion Concurrency Control (MVCC) Die ordnungsgemäße Speicherung aller Datensätze sowie das Sicherstellen der semantischen Integrität gehören zu den primären Aufgaben eines DBMS. Um dies zu gewährleisten, werden innerhalb der klassischen Zugriffsverfahren (pessimistischen Sperrverfahren), durch den jeweiligen Prozess, die Datensätze für weitere Zugriffe durch andere Prozesse exklusiv gesperrt. Unabhängig vom Sperrmodus werden bei der klassischen Methode Leseprozesse von Schreibprozessen geblockt und müssen warten, bis die Transaktion abgeschlossen oder abgebrochen wurde. Als Alternative, kann das Zugriffsverfahren Multiversion Concurrency Control (MVCC) angewendet werden, welches einen parallelen Zugriff auf dieselben Daten ermöglicht. MVCC wird in den meisten verteilten Datenbanksystemen verwendet und in einigen relationalen Datenbanksystemen. Durch diese Alternative wird ein Zugriffsverhalten angeboten, bei dem Schreibprozesse keine Leseprozesse blockieren und andersrum. Der konkurrierende Zugriff auf die Datensätze wird durch verschiedene und unveränderliche Versionen der Datensätze kontrolliert, welche mittels eindeutigen Versionsnummern gekennzeichnet werden (Abbildung 1)[23]. Abbildung 2: Datensatz mit vier Versionen Abbildung 3: Speichervorgang im MVCC Verfahren Dies stellt Herausforderungen an das DBMS, denn sobald mehrere Versionen eines Datensatzes in der Datenbank vorgehalten werden, muss die Versionsverwaltung intransparent für den Anwender erfolgen (?alte? Versionen ausblenden). In periodischen Abständen sollten jedoch die ?alten? Versionen der Datensätze aus der Datenbank entfernt werden. Um eine eindeutige Versionsnummer zu erhalten, können verschiedene Ansätze in Betracht kommen, beispielsweise: Transaktionsnummer, Timestamp oder Vector Clocks, welche abhängig vom verwendeten Datenbanksystem sowie deren Einstellungen sind[24]. Sollten Timestamps als eindeutige Versionsnummer verwendet werden, müssen alle Datenbankinstanzen synchronisierte Zeiten besitzen. Des Weiteren kann es vorkommen, dass zwei Instanzen zeitgleich denselben Datensatz beschreiben und somit die Konflikterkennung nicht möglich ist. Um dies zu vermeiden, sollten zeitunabhängige Verfahren, wie Vector Clocks oder Hash Histories, bevorzugt verwendet werden[25]. Beim schreibenden Zugriff auf einen Datensatz, wird nicht nur die ID des Datensatzes ermittelt, sondern auch die aktuelle Versionsnummer. Nachdem der Datensatz aktualisiert wurde, wird die aktuelle Versionsnummer innerhalb des Prozesses mit der Versionsnummer in der Datenbank abgeglichen. Sollte die Versionsnummer des Datensatzes innerhalb des Prozesses identisch mit der Versionsnummer in der Datenbank sein, wird der Datensatz gespeichert und die Versionsnummer innerhalb der Datenbank inkrementiert. Die vorherige Version innerhalb der Datenbank wird als abgelaufen markiert. Diese Version befindet sich solange innerhalb der Datenbank, bis das DBMS mittels Aufräumroutine diesen Datensatz entfernt. Wenn die Versionsnummer im Prozess nicht identisch mit der Versionsnummer innerhalb der Datenbank sein sollte, dann muss ein anderer Prozess die Daten inzwischen geändert haben und es muss eine Konfliktlösung durch den Client durchgeführt werden. Dieser Versionskonflikt kann während des Schreibvorgangs auftreten, bei denen die Transaktion zum Beispiel neu gestartet oder abgebrochen wird. Ferner kann dies durch asynchrone Replizierung durch einzelnen Datenbankinstanzen ebenfalls auftreten. In der Regel werden alle Konfliktversionen 5.6 Multiversion Concurrency Control (MVCC) 13 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL der Datensätze aufbewahrt, bis der Client entscheidet, wie diese bereinigt werden.[26] 5.7 Vector Clocks Wie erwähnt muss jeder Datensatz eine eindeutige Versionsnummer besitzen, um festzustellen, welche Version die aktuelle Version des Datensatzes ist. Dieses Problem ist in verteilten NoSQL-Systemen mit verschiedene Datenbankinstanzen alles andere als trivial. Die Festlegung der Versionsnummer mittels Timestamp kann dazu führen, dass mehrere Prozess zeitgleich denselben Datensatz verändern und das System dies nicht mitbekommt, da der Timestamp identisch ist und somit keine Konflikterkennung an den Client gemeldet wird. Ziel der Vector Clocks ist es, die Probleme der Synchronisation, Ordnung der Ereignisse und Konflikterkennung auch in verteilten NoSQL-Systemen zu lösen und an den Client zu melden, damit diese behoben werden[27]. Anhand der nachfolgenden Abbildung wird die Funktionsweise der Vector Clocks erläutert: Der Datensatz X enthält den Vector ([A,0]), da dieser initial vom Prozess A geschrieben wurde. Prozess B aktualisiert den Wert des Datensatzes X und startet seine Vector Clock für dieses Item. Somit besitzt der Datensatz X den Vector ([A,0],[B,1]). Da es ein serieller Zugriff war, kam es zu keinem Konflikt. Im Anschluss aktualisieren beide Prozesse parallel auf verschiedenen Replikationen den Datensatz X und erhöhen den Vector Clock[28]. Bei der nächsten Synchronisation des Datensatz X besitzen beide Vector Clocks Unterschiede, welches darauf zurückführt, dass es zu einem Konflikt kam. Diese Konflikterkennung wird an den Client gemeldet, welcher diesen Konflikt auflösen muss.[29] Abbildung 4: Konflikterkennung mittels Vector Clocks Das Prinzip der Vector Clocks ist dienlich, um eine eindeutige Versionsnummer für die Datensätze bereitzustellen. Allerdings lösen Vector Clocks keine Konflikte, sondern können diese lediglich aufzeigen und mit jedem schreibenden Prozess auf den Datensatz werden die Vector Clocks größer. 6 Problemstellung Die zu betrachtende Komponente ist eine API, auf dessen Basis einige Webanwendungen betrieben werden. Die API unterteilt sich im mehrere Bereiche, um diverse Funktionen zur Verfügung, zu stellen wie zum Beispiel Userverwaltung, Datenhaltung, unterstützende GUI Funktionen, Datenaustausch über weitere Protokolle. Die API wurde in der Programmiersprache C# implementiert. Momentan kommt im Backend das relationale Datenbankmanagementsystem PostgreSQL zum Einsatz. Jedoch gibt es seitens des Betreibers die Frage, in wie weit das Antwortverhalten sowie die Ausfallsicherheit bei einem immer weiter steigendem Datenvolumen gewährleistet werden kann und ob hierfür NoSQL-Datenbanken eine Alternative darstellen. Daher soll hier untersucht werden, ob es geeignetere DBMS gibt oder inwieweit Teile ausgegliedert werden könnten. Der Fokus dieser Studie richtig sich dabei auf den Teil der API,der den direkten Datenaustausch zwischen Applikation und Datenquelle ermöglicht und andere Funktionen, die auf das Datenbankbackend zurückgreifen. 6 Problemstellung 14 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 6.1 Ist Zustand Die Daten der Anwendungen werden momentan in dem RDBMS PostgreSQL gespeichert. Zwischen Datenbank und Anwendungen befindet sich eine Schnittstelle, die den Zugriff auf die Datenbank reglementiert (folgend DB-API genannt). 6.1.1 Datenstrukturen Den Anwendungen werden von der Schnittstelle mehrere Datenstrukturen zur Verfügung gestellt, die letztendlich die Beziehungsmöglichkeiten des relationalen Datenbankmodells repräsentieren. Innerhalb dieser Strukturen gibt es keine referenzelle Integrität anhand von Fremdschlüsseln. Ein Bezug zu einem Datensatz wird mit Hilfe einer ID beschrieben, wobei an der Schnittstelle die Konsistenz dieser Beziehung sicherstellt. Eine Struktur, welche Entitäten ohne Bezug abbildet, ist eine so genannte Haupttabelle. Diese Struktur beinhaltet einen Primärschlüssel sowie beliebige Attribute. Eine weitere Struktur ist eine Untertabelle. Untertabellen bilden eine 1:N-Beziehung ab und bestehen daher neben einem eigenen Primärschlüssel aus einer ID, welche auf einen Datensatz einer Haupttabelle verweist. Zusätzlich können auch hier weitere beliebige Attribute enthalten sein. Verbindungstabellen dienen der Abbildung von N:M-Beziehungen zwischen Datensätzen von Haupttabellen. Ein Datensatz besteht hierbei aus zwei IDs, die auf die jeweiligen Hauptdatensätze verweisen. Abbildung 5: ER: Verbindungstabelle Abbildung 6: ER: Untertabelle Des Weiteren werden durch die API noch Funktionen zur Ablage von Dateien innerhalb einer Datenquelle sowie Funktionen zur Speicherung von Cache- und Konfigurationsdaten. Das Caching und die Konfigurationsablage sind Key/Value Collections, die einen Bezug zu Usern oder Gruppen haben können. Die datenbankgestützte Dateiablage beinhaltet neben der eigentlichen Datei in Form eines Bytearrays Metainformationen (z.B. Name, Dateityp) sowie einen Hash und einen Verweis zu einer beliebigen ID. Die Datenanalyse ist notwendig, um zu ermitteln, welche Daten momentan vorhanden sind, welches Volumen durch diese verwendet wird, ob und wie diese miteinander verknüpft sind und welche Operationen auf diese angewandt werden. Eine Betrachtung der vorhandenen Daten hat ergeben, dass sie die wie folgt Kategorisieren lassen: • Logdaten • Businessdaten • Rechte und Rollen • Cachedaten • Dateidaten Das größte Datenvolumen wird von Logdaten in Anspruch genommen. Diese haben nur einen Bezug zu 6.1 Ist Zustand 15 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Userdatensätzen. Auf die Logdaten werden fast ausschließlich Hinzufüge- und Leseoperationen angewandt. Die Protokolldaten sind in einer Tabelle hinterlegt. Erfasst werden hier Meldungen bezüglich sicherheitsrelevanter Vorgänge, wie z.B. Logins oder Bearbeitungen von Rechten. Das nächste größere Volumen wird von Businessdaten verwendet. Diese können untereinander über die gegebene Struktur in Bezug zueinander stehen. Auf diese Daten wird mit allen Operationen, also Hinzufügen, Schreiben, Lesen und Löschen, zugegriffen. Die Businessdaten werden in den oben beschriebenen Strukturen hinterlegt und werden von den Applikationen vorgegeben. Die DB-API stellt, wie weiter oben beschrieben, neben den anwendungsbezogenen Daten, noch weitere Funktionen für Caching, Konfigurationsablage, Userverwaltung, datenbankgestützte Dateiablage und für die Sicherheit der Daten relevante Systemtabellen zur Verfügung. Diese Daten werden, mit Ausnahme der Userdaten, eher hinzugefügt, gelesen oder gelöscht. Bei Userdaten kann eine Bearbeitung der Datensätze durchaus vorkommen. Zurzeit werden folgende Typen innerhalb der Relationalen Datenbank verwendet: • Boolean • Integer • BigInteger (Int64) • Datetime • Char Array (vchar) • Text • Byte Array 6.1.2 Datennavigation Die API kapselt den Zugriff auf die oben beschriebenen Tabellen. Die aufsetzenden Applikationen können ausschließlich über die angebotenen Methoden der API auf die Datenbanken zugreifen. Die Ausführung von SQL-Befehlen ist über die DB-API nicht möglich. Des Weiteren stellt die API momentan keine Methoden zur Anwendung von relationaler Operatoren wie JOINS, UNIONS oder Ähnlichem bereit. Die Filtermöglichkeiten über die DB-API beschränken sich auf IDs. Es ist jedoch geplant, Datensätze über bestimmte Attribute zu ermitteln. Dies soll jedoch gekapselt, von der jeweiligen Datenbankabfragesprache, geschehen. Die Methoden der Haupt- und Untertabelle geben einen Objekt zurück, welches das Ergebnis der Abfrage kapselt. Dieses ist wie folgt aufgebaut (gekürzt): Die Objekte innerhalb der DataSource für den eigentlichen Zugriff auf die Daten sind Teil des Ado.Net Frameworks.Der Zugriff auf die Daten ist wie folgt möglich: IDataSource.DataTable.Rows[ID][Column] Das Objekt hat folgende Eigenschaften: • DataTable ist vom Typ System.Data.DataTable • Rows ist eine Collection des Typs System.Data.DataRow ? der Zugriff auf einzelne Rows erfolgt über Indizes 6.1.1 Datenstrukturen 16 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL • System.Data.DataRow enthält eine Item-Collection für den Zugriff auf die einzelnen Zellen; ein Item aus der Item-Collection ist vom Typ Object; die Werte sind abhängig vom Datenbankschema getypt Verbindungstabellen werden von der API in Form von integertypisierten Arrays zurückgegeben. Über die Methoden werden Child- bzw Parentids zu einer bestimmten Child- bzw. Parentid erfragt. 6.1.3 CAP-Abwägung Die Frage der gewünschten CAP-Eigenschaften lässt sich schwer beantworten, da hier viele unterschiedliche Datenarten aufeinander treffen. Dennoch ist eine Definition zwingend erforderlich, um auf dessen Basis ein geeignetes Produkt ermitteln zu können. In der Datenkategorie Protokollierung ist die Konsistenz nicht so wichtig, da diese in der Regel nicht bearbeitet und nur geschrieben und analysiert werden. Wichtig wäre hier jedoch, dass die Daten jederzeit geschrieben werden und aufgrund der Datenmenge verteilt werden können. Die Cache-, Konfigurations- und Fileeinträge benötigen keine strikte Konsistenz, da auch hier Datensätze eher erzeugt und gelesen werden. Hier wäre es irrelevant, falls Daten nicht sofort von allen Clients gelesen werden können. Die gewünschte Konsistenz der Businessdaten hängt stark von den Anforderungen der Applikation ab. Userdaten, sowie Daten zu den Rechten und Rollenzugehörigkeiten (Sicherheitsdaten), müssen aufgrund Ihrer Eigenschaft als Sicherheitsfunktionen konsistent sein. Business- und Sicherheitsdaten können Partitioniert werden. Es ist jedoch wichtig, dass die Businessdaten von Verfügbarkeit der Sicherheitsdaten abhängen. Das bedeutet, dass Businessdaten nur dann von der Schnittstelle zurückgegeben werden dürfen, wenn auch die dazugehörigen Sicherheitsdaten gelesen werden konnten. Natürlich müsste dies von der Implementierung der Schnittstelle umgesetzt werden. 6.1.4 Relationales Datenbankmodell Folgendes Entity Relationship Diagramm soll Beispielhaft Businessdaten, die über die beschrieben Datenstrukturen erzeugt und verwendet werden, und deren Abhängigkeiten zueinander darstellen. Abbildung 7: Beispiel ER Diagramm 6.2 Anforderungen an das DBMS Aus den oben beschriebenen Punkten ergeben sich folgende Anforderungen an das DBMS: • Die Datenbank muss in der Lage sein, die gegebene Datenstruktur zu erfassen. • Das Interface der API darf sich, aufgrund der Tatsache das diese schon im Einsatz ist und eine Änderung auch Anpassungen in den darauf aufbauenden Applikationen nach sich ziehen würde, nicht oder nur im 6.1.2 Datennavigation 17 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL geringen Umfang verändern. • Des weiteren muss ein Connector zu der verwendeten Programmiersprache (C#) zur Verfügung stehen. • Das DBMS muss unter den Betriebssystemen Windows oder Linux lauffähig sein. • Aufgrund der Unterschiedlichsten Applikationen, die auf die zentrale Schnittstelle und deren Daten aufbauen, ist eine möglichst variable Konsistenz erwünscht. • Um einen Mehrwert zur bestehenden Lösung zu erhalten und um auf künftige Anforderungen schnell reagieren zu können, muss das System horizontal skalierbar sein. • Die oben erwähnte Datennavigation muss berücksichtigt werden. • Für den Fehlerfall sollte eine Supportmöglichkeit seitens des Herstellers oder eines Drittanbieters, der mindestens fünf Tage die Woche, acht Stunden pro Tag, zur Verfügung steht, vorhanden sein. 7 Architekturen Eine Analyse der Mathe-, Graphen-, und Key-Value-Datenbank ergab, dass diese die fallspezifischen Anforderungen nicht erfüllen und wurden deshalb im weiteren Verlauf dieser Studie nicht betrachtet. In diesem Abschnitt werden die Architekturen der NoSQL-Datenbanken erläutert, welche aufgrund der Recherche die Anforderungen erfüllen könnten. 7.1 Dokumentenorientierte Datenbanken Falls eine Analogie zu einer dokumentenorientierten Datenbank hergestellt werden soll, könnte diese Form der NoSQL-Datenbank mit einem Karteikasten verglichen werden[30]. Die Daten werden schemafrei innerhalb des Karteikasten in Karteikarten (Dokumenten) abgelegt und können aus beliebigen Feldern bestehen, welche beispielsweise Zahlen, Listen, Texten oder Dateien abbilden. Aufgrund der Schemafreiheit ist keine Definition der Werte, wie Datentyp oder Länge innerhalb des Dokuments notwendig [31]. 7.1.1 Allgemeiner Verwendungszweck Die dokumentenorientierten Datenbanken eignen sich besonders, sobald eine umfangreiche und zusammenhängende Datenstruktur mit unbestimmten Formaten gespeichert werden sollen. Anwendungsfälle wären beispielsweise ein Blog-System, CMS oder Wiki[32]. 7.1.2 Datenmodell Abbildung 8: Abbildung der Dokumente (JSON-Format) 7 Architekturen 18 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Die Speicherung der Dokumente erfolgt zumeist im JSON (JavaScript Object Notation) bzw. mit der binären Variante im BSON Format (Siehe Abbildung 8)[33]. Zusammenfassungen der Attribute (Felder, Typen) werden in Dokumenten gespeichert, welche über eine einmalig existierende Dokumentenid innerhalb der Datenbank gekennzeichnet sind. Für gezielte Abfragen wird das MapReduce-Verfahren angewendet. Aufgrund der Schemafreiheit in den einzelnen Dokumenten liegt die Entscheidung beim Entwickler, welche Daten innerhalb eines Dokuments gespeichert werden sollen. Es könnte beispielsweise die Komplette Anwendung innerhalb eines Dokuments gespeichert werden. Es muss beachtet werden, dass bei jedem Zugriff auf ein Dokument alle Einträge ausgelesen werden. Doch welche Regel sollte ein Entwickler nun befolgen? Eine eindeutige Regelung gibt es nicht, denn jedem Entwickler ist diese Entscheidung selbst überlassen. In der Regel sollten keine Inhalte eingebettet werden, welche viel Speicherplatz verbrauchen, aber nie benötigt werden. Des Weiteren eignen sich eingebettete Dokumente nur, wenn die Daten nicht in mehreren Dokumenten gleichzeitig zugeordnet werden. Sollte die Liste zu groß werden, könnte alternativ ein Relationsdokument erstellt werden, ähnlich der N:M-Beziehung in relationalen Datenbanken. Doch dies würde nicht dem Konzept der dokumentenorientieren Datenbanken entsprechen und in solch einem Fall ist eine relationale Datenbank anzuraten. Der CouchDB-Guide empfiehlt folgenden Leitsatz: ?Real-world data is managed as real-world documents?[34]. Beispiele wären alle Daten einer Rechnung oder Visitenkarte. 7.1.3 Vergleich zu RDBMS Innerhalb der dokumentenorientierten Datenbank sind die zugehörigen Daten auf einen Blick sichtbar, wobei diese in einer relationalen Datenbank auf verschiedene Tabellen verteilt sind. Im Vorfeld muss für die dokumentenorientierte Datenbank kein festes Schema definiert werden und die Länge der jeweiligen Werte benötigen ebenfalls keine Definitionen. Nachfolgende Abbildung verdeutlicht anhand eines Blog-Eintrags schemenhaft die Unterschiede zwischen einem RDBMS und einer dokumentenorientierten Datenbank. Abbildung 9: Blogeintrag - RDBMS vs. dokumentenorientierte Datenbank In einem relationalen Datenbanksystem ist das Datenmodell in einer normalisierten Form abgebildet. Beispielsweise ist das Lesen eines Blog-Eintrags in der normalisierten Form zeitaufwendig, da die Daten von verschiedenen Tabellen gelesen und die Abhängigkeiten aufgelöst werden müssen. Im Vergleich zu einer dokumentenorientierten Datenbank ist dieser Vorgang sehr einfach gestrickt, da nur das entsprechende Dokument gelesen werden muss, welches den Blog-Eintrag beinhaltet. Allerdings ist das Ändern der Datensätze zeitaufwendiger, da dass komplette Dokument gespeichert werden muss. Ohne die Schemavorgabe in dokumentenorientierten Datenbanken erhalten die Entwickler mehr Flexibilität und es können die zeitintensiven Schemaänderungen bei großen Datenbanken vermieden werden. 7.1.4 Vor-/Nachteile Aufgrund des Prinzip der Schemafreiheit wurde die Schemaverantwortung komplett an die Entwickler übergeben und somit ist ein Umdenken der Entwickler notwendig. Die Abbildung von referentieller Integrität sowie Normalisierung können nicht abgebildet werden. Neben der vertikalen Skalierung wird eine horizontale Skalierung ermöglicht und es können alle zusammenhängenden Informationen innerhalb eines Dokuments abgebildet werden (Blog-Artikel, Wikiseite, ?). Einige dokumentenorientieren Datenbanken verwenden den MVCC-Mechanismus, um einen gleichzeitigen Zugriff auf denselben Datensatz zu ermöglichen, um somit mehr Zugriffe auf die Datensätze zu ermöglichen [35] [36]. Hohe Verfügbarkeiten sind realisierbar, da die Datenreplikationen in jedem Produkt der dokumentenorientierten Datenbanken vorhanden sind. Allerdings kann 7.1.2 Datenmodell 19 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL eine Volltextsuche nur mittels Zusatzsoftware, wie zum Beispiel Apache Lucence ermöglicht werden. Wenig geeignet für Datensätze mit einem hohen Maß an Integrität, sondern eher geeignet für Anwendungen mit vielen Nutzern, hohe Verfügbarkeit und unstrukturierten Datensätzen. Innerhalb des CAP-Theorems lassen sich die dokumentenorientierten Datenbanken AP (Verfügbarkeit und Partitionierung) anzutreffen. 7.1.5 API Die Abfragemöglichkeiten variieren vom jeweils verwenden Datenbankprodukt, wobei die gängigsten Programmiersprachen von allen Produkten unterstützt werden. Beispielsweise bietet MongoDB eine API für eine Vielzahl von Programmiersprachen, zum Beispiel: Java, C++, C#, Erlang, Python, Ruby, PHP, uvm. [37]. Der Zugriff auf CouchDB erfolgt komplett über die REST-API und ermöglicht somit die Kommunikation mittels einfachen Webservices, welche auf Basis von HTTP angesprochen werden [38]. 7.1.6 Produkte Als die am weit verbreitetste dokumentenorientierte Datenbank gilt Lotus Notes von IBM. Damien Katz, Entwickler von Lotus Notes, hat 2005 begonnen, die CouchDB zu entwickeln, welche mittlerweile als Apache Project frei Verfügbar ist. Weiterhin gibt es u.a. noch MongoDB, Terrastore oder Riak, welche ebenfalls frei verfügbar sind. 7.2 Wide Column Store Die Architektur ?Wide Column Store?, im deutschsprachigen Raum auch unter dem Begriff spaltenorientiertes Datenbanksystem bekannt, speichert Daten zusammenhängender Einträge, im Gegensatz zu relationalen Datenbanksystemen, in Spalten. Folgend soll dieses Verhalten anhand eines Beispiels veranschaulicht werden.[39] In einer relationalen Datenbankarchitektur werden die Daten der zusammenhängenden Einträge wie folgt gespeichert[40]: ID Name Vorname Adresse 1 Name Vorname Straße1 2 Mustermann Hans Straße1 3 Musterfrau Anne Straße3 Tabelle 1: WideColumnStore - Relationale DBMS Anordnung von Daten In spaltenorientierten Datenbanksystemen wären die zueinander gehörigen Daten in Spalten angeordnet[41] [42]: ID Name Vorname Adresse 1 Name Vorname Straße1 7.1.4 Vor-/Nachteile 2 Mustermann Hans Straße2 3 Musterfrau Anne Straße3 20 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Tabelle 2: WideColumnStore - Anordnung von Daten 7.2.1 Allgemeiner Verwendungszweck Aufgrund der beschriebenen Eigenschaften eignen sich spaltenorientierte DBMS besonders für die Verarbeitung und Analyse großer Datenmengen, bei denen nur einzelne Felder der Datensätze berücksichtigt werden[43]. Spaltenorientierte Datenbanksysteme finden häufig in folgenden Bereichen Anwendung: • OLAP • Data-Warehouse • Suchmaschienen • Soziale Netzwerke • Logging 7.2.2 Datenmodell Die kleinste Einheit dieser Architektur ist die einzelne Column. Diese besteht aus einem eindeutigen Namen, Wert und Timestamp. Einzelne Columns werden in Column Families gruppiert wobei hier jede Zeile eindeutig über einen Schlüssel identifizierbar ist.[44] Abbildung 10: WideColumnStore Column Family Viele Produkte bieten hier die Freiheit aus beliebigen Columns einen Datensatz zu bilden. So ist es möglich, dass ein Datensatz aus Name und Vorname besteht, der Zweite innerhalb dieser Column Family aber eine weitere Column, z.B. Geburtsdatum, beinhaltet. So lassen sich neue Anforderungen bei neuen Datensätzen problemlos umsetzen. Die meisten Datenbankprodukte erweitern dieses Schema in der Dimension. So werden oft als höchste Gruppierungsebene Keyspaces bereitgestellt. Keyspaces sind vergleichbar mit Datenbanken aus dem Relationalen Datenbankmodell und gruppieren mehrere Column Families zu einer Einheit.[45] Je nach Produkt gibt es hier noch Erweiterungen. So stellt Cassandra eine Super Column und eine Super Column Family zur Verfügung. Eine Super Column enthält einen Namen und anstatt eines direkten Wertes eine Auflistung beliebiger Columns. Eine Super Column Family gruppiert eben diese Super Columns zu einer Einheit.[46] 7.2.3 Vergleich zu RDBMS Spaltenorientierte Datenbankmanagementsysteme stellen keine Foreignkeys zur Verfügung. Daher sind auch keine relationalen Operationen wie JOINs oder Ähnliches möglich.[47] Das oben beschriebene beispielhafte Datenbankbankmodell ließe sich hier wie folgt umsetzen: 7.2 Wide Column Store 21 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Abbildung 11: Umsetzung eines ER in Wide Column Store Da keine referenzielle Integrität vorhanden ist, obliegt es der Implementierung, also der zentralen Anwendungsschnittstelle, die Konsistenz zwischen einzelnen Beziehungspartnern sicherzustellen. Um das Ergebnis von relationalen Operatoren, also aggregierte Datenbestände, zu erhalten wird häufig empfohlen, Daten redundant zu Speichern. Es wäre also möglich, das Ergebnis solcher Abfragen in weiteren Tabellen, also Column Families, zu speichern. Auch dies müsste letztendlich in der Implementierung umgesetzt werden. Dies hätte jedoch den Vorteil, dass solche Abfragen sehr performant durchgeführt werden können, da hier letztendlich auf eine bestehende Tabelle zurückgegriffen wird. Dies ist unter dem Begriff ?Materialized View? bekannt.[48] 7.2.4 Vor-/Nachteile Aufgrund des oben beschriebenen Art zur Speicherung zusammenhängender Daten ergeben sich einige Vorteile. Es lassen sich so die Verarbeitung und Analyse einzelner Felder, also das Lesen und Schreiben einzelner Spalten mehrerer Datensätze, beschleunigen, da nur auf die Spalten zugegriffen werden muss, die tatsächlich benötigt werden und die Verarbeitung von unnötigen Informationen vermieden wird. Des Weiteren lassen sich die Werte der einzelnen Spalten gut komprimieren.[49]Nachteilig ist dieses Verfahren beim Schreiben vieler Datensätze, die aus mehreren Feldern bestehen. Auch die Suche von Datensätzen anhand von vielen Feldern könnte die Performance beeinträchtigen.[50] [51] Spaltenorientierte Datenbanksysteme bieten keine referenzielle Integrität (Fremdschlüssel). Daher sind relationale Operatoren über mehrere Column Families nicht möglich. Dies hat jedoch den Vorteil, dass sich Daten gut verteilen lassen. Innerhalb des CAP- Theorems sind spaltenorientierte DBMS unter den Punkten CP oder AP anzutreffen. 7.2.5 API Je nach Datenbankprodukt stehen unterschiedliche Abfragemöglichkeiten zur Verfügung. Häufig ist als Schnittstelle das Thrift Framework anzutreffen. In der Implementierung ließe sich auf Datensätze wie auf mehrdimensionales Array zugreifen: NameDerSuperColumn[Key][Column] Mitarbeiter[0001][Name] In vielen Produkten lassen sich mittlerweile aber auch Daten über eine SQL ähnliche Syntax ansprechen. 7.2.6 Produkte Seit den 80'er Jahren beschäftigt sich das Unternehmen Sybase mit dieser Architektur. Daraus entstand die erste Implementierung. Nach der Veröffentlichung von Google's BigTable Design sind mehrere Anbieter auf den Markt gedrungen. Einige der erfolgreicheren Implementierungen sind die OpenSource Produkte Hbase, Cassandra 7.2.3 Vergleich zu RDBMS 22 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL und Hypertable. Aber auch kommerzielle Anbieter veröffentlichten nach und nach eigene Produkte. So hat Amazon das eigene Cloudportfolio um das Produkt ?Amazon SimpleDB? erweitert, welches als Webservice zur Verfügung steht. 7.3 Objektorientierte Datenbanken Relationale Datenbanksysteme sind sehr populär und die wahrscheinlich meist genutzte Form der Datenhaltung. Für die gängigen Probleme der Datenhaltung mögen sie ausreichend sein, doch sobald es darum geht, komplexe Datenstrukturen wie etwa multimediale Daten, CAD-Objekte oder firmenspezifische Eigenentwicklung in ein relationales System zu speichern, ist der Aufwand enorm[52], die Daten zu zerteilen und in die Relationen zu transformieren. So wird es immer komplizierter, den Durchblick zu behalten. Objektorientierte Programmiersprachen sind ein fester Bestandteil der Softwareentwicklung und für viele komplexe Projekte die Lösung[53]. Durch die Abstraktion der Dinge der natürlichen Welt in Objekte sind die Softwarelösungen leicht verständlich und anzuwenden[54]. Die wachsende Komplexität von Anwendungen wirkt sich auch auf die Datenhaltung aus. Auch mittels der Normalisierung lassen sich komplexe und vielschichtig vernetze Daten nur schwer und ungenügend in relationalen Datenbanken abbilden. Objektorientierte Datenbankmodelle könnten hier die Alternative sein[55], was folgend untersucht werden soll. 7.3.1 Allgemeiner Verwendungszweck Eine objektorientierte Datenbank stellt eine Alternative dar, wenn es darum geht, vielschichtig vernetzte Daten möglichst einfach und ohne großen Aufwand persistent aufzubewahren. Sie eignet sich besonders bei komplexen Datenstrukturen, welche in einem relationalem System in einer Vielzahl von Relationen aufgeteilt werden müsste[56][57]. Im Zeitalter der Navigationssysteme oder sozialen Netzwerke haben sich objektorientierte Datenbanken bereits bewährt, was der Fakt beweist, dass die Internetriesen ihre eigenen Datenhaltungssystem auf NoSQL?Basis entwickeln. So werden spezielle objektorientierte Datenbanken für die Identifizierung von Zusammenhängen zwischen Wikipediaeinträgen verwendet oder aber die Speicherung von Beziehungen von verschiedenen Individuen in einem sozialen Netzwerk.[58] 7.3.2 Datenmodell Abbildung 12: Ein Objekt Auto in Assoziation mit einem weiteren Objekt Rad, http://www.matthiasmaas.de/info_klasse10_oom.gif,23.05.2012 Den objektorientierten Datenbanken liegt das Modell der Objektorientierung vor. Es ist eine Abstraktion der realen Welt, was bedeutet, dass es keine klare Trennung zwischen Daten und Funktionen gibt[59]. Ein Objekt hat Eigenschaften(Daten) und Fähigkeiten(Funktionen) wie z.B. ein Mensch. Ein Mensch hat Eigenschaften wie seine Haarfarbe oder etwa seine Körpergröße. Zusätzlich hat er die Fähigkeiten, zu stehen, zu laufen und vieles mehr. Weiter sind Objekte in der Lage, mit einander zu kommunizieren, also Daten von anderen Objekten zu empfangen und natürlich Daten an andere Objekte zu senden.[60] 7.2.6 Produkte 23 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 7.3.3 Vergleich zu RDBMS Durch den objektorientierten Ansatz lassen sich menschliche Probleme mit Dingen der natürlichen Welt sehr gut für Menschen verständlich darstellen [61]. Durch den Sachverhalt der Verwendung von Objekten ist das auch die niedrigste Ebene. Im Vergleich zu einem RDBMS, bei dem die niedrigste Ebene das Atom oder auch das Attribut einer referenzierten Sache ist. Das Objekt ist die Grundeinheit, welchem Attribute, die wiederum Objekte sein können, eindeutig ohne die Verwendung von Schlüsseln zugeordnet sind. Zusätzlich lassen sich in Ihren Klassen Methoden speichern, somit ist der Umgang für jedes Objekt gegeben. 7.3.4 Vor-/Nachteile Ein starker Vorteil ist die Verständlichkeit, denn in Zeiten wachsender Daten werden relationale Schemen komplexer, verschachtelter und vernetzter. Das objektorientierte Datenmodell hilft dem Menschen, die Datenhaltung besser zu verstehen, da das Konzept an die natürliche Welt angepasst ist.[62] Bei Benutzung einer objektorientierten Sprache kann es nicht zu einem ?Impedance Missmatch? kommen. Abbildung 13: Abbildung 1: Der Impedance Missmatch links und rechts die barrierefreie Importierung eines Objektes in eine objektorientierte Datenbank http://www.db4o.com/s/csharpdb.aspx, 26.07.2012 Da die Speicherung in einem relationalem System in Relationen erfolgt und man in einer objektorientierten Sprache Objekte verwendet, müssen die Daten beim Auslesen aufwendig gesucht und in eine geeignete Struktur transformiert werden. Ebenso müssen die Teile eines Objektes beim Speichern in ein relationales System zerteilt und verteilt werden. Bei der Nutzung einer objektorientierten Datenbank entfallen all diese aufwendigen Schritte.[63] Für die parallele Nutzung einer objektorientierten Sprache gibt es weitere Vorzüge wie die Wiederverwendbarkeit, denn viele Programmiersprachen bieten Betriebssystem unabhängige Laufzeitumgebungen an, welche also auch die Datenbank unabhängig machen und somit ein betriebssystemunabhängigen Verbund aus Programm und Datenbank möglich macht[64]. Das Datenmodell der objektorientierten Programmierung bietet eine hohe Flexibilität in der Erweiterbarkeit. Objekte haben zur Zeit ihres Entwurfs eine bestimmte Anzahl an Daten und Funktionen, welche sich im Laufe der Zeit ändern oder erweitern können[65]. Trotzdem können Objekte derselben Sache mit unterschiedlichen Daten und Funktionen nebeneinander existieren, während das in einem relationalen System durch Filter im Design viel schwieriger ist und somit erheblich unflexibler[66]. Weiterhin entfällt die Kontrolle der Schlüssel. Durch die natürliche Vernetzung von Objekten ist der Einsatz von Fremdenschlüsseln nicht nötig. Zusätzliches wird jedes Objekt wird durch die Datenbank mit einer eindeutigen Objektnummer versehen, anhand dieser man das Objekt immer eindeutig identifizieren kann, nicht der Entwickler kümmert sich um die Schlüssel, sondern die Datenbank[67]. Auch das Entwickeln von Tabellen und Verbindungstabellen entfällt, da dieser Architektur das Datenmodell der objektorientiert Programmierung zu Grunde liegt. Somit sind komplexe Abbildungen speicherbar, denn durch das flexible Gestalten von Klassen und die natürlichen Verbindungen von Objekten lassen sich komplizierte Abbildungen sehr leicht und unkompliziert speichern. Das hat zur Folge, dass kein Wissen in SQL vorausgesetzt wird und Schulungsmaßnahmen für SQL entfallen und können somit eingespart und an anderen Stellen sinnvoller eingesetzt werden.Nach Recherchen der gängigen Vertreter der OODB ist eine OODB mit wenig Logik ausgestattet[68] und bietet ihre Vorteile eher in ihrer Erweiterbarkeit und demnach wird viel Logik zur Datenhaltung in der Anwendung selber gespeichert. So verschiebt dich die Logik der Datenhaltung aus der Datenschicht in die Logikschicht der Anwendung, was einen erheblichen Nachteil für die Anwendungsentwicklung in der Entwicklungsphase darstellen kann und der Aufwand von Planung stark erhöht wird[69]. So muss gewährleistet, dass der Umgang mit einer objektorientierten Sprache und die objektorientierte Philosophie bekannt ist, wenn das Team, welches an dem Projekt arbeitet wenig bis gar keine Erfahrung mit OOP 7.3.3 Vergleich zu RDBMS 24 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL hat, und das eigentliche Projekt ebenfalls nicht in einer OOP-Sprache verfasst ist, sollte eine OODB nicht verwendet werden. Ebenfalls ist zu beachten, dass je nach Klassenaufbau viel Speicherbedarf für Leerstellen besteht, sobald eine Klasse über viele Attribute verfügen kann, diese aber nicht erfüllt sein müssen, dann wird natürlich auch für die Leerstellen eine gewisser Speicherbedarf benötigt, was sich je nach Projektgröße stark summieren kann. 7.3.5 API Durch das Datenmodell der objektorientierten Programmierung lassen sich Klassen in der Regel leicht durch einen Parser in eine andere Typklasse umwandeln. Alle untersuchten OODB bieten in ihrer Sprach-API entsprechende Mechanismen.[70] 7.3.6 Produkte db4O - http://www.db4o.com/ ObjectDB - http://www.objectdb.com/ Neo4J ?http://www.objectdb.com/ 7.4 Architektur-/Datenbankevaluierung Objektorientierte Datenbanken haben den Vorteil, dass die Abstraktion zwischen Datenbankmodell und Programmiersprache entfällt. Entwickler müssen sich somit nicht mehr mit einem Datenbankmodell oder die Frage, wie Datenstrukturen des Programms in und aus einer Datenbank übertragen werden können, auseinandersetzen. Beziehungen zwischen Entitäten können direkt über die Objektorientierte Programmiersprache definiert werden und werden entsprechend in der Datenbank hinterlegt. Auch die eingesetzte Programmiersprache wird von vielen Produkten unterstützt. Dennoch ist ein Nachteil die Skalierbarkeit. Objektorientierte Datenbanken sind aufgrund ihrer Art Beziehungen darzustellen eher im Bereich CA des CAP-Theorems anzutreffen. Es bliebe also des selbe Problem, welches durch das momentan eingesetzten Datenbankmanagementsystem besteht. Um diese Architektur sinnvoll anzubinden, wäre eine Änderung der Schnittstelle notwendig, welche aufgrund der gegebenen Problemstellung nicht möglich ist. Ferner entsprechen die gegebenen Möglichkeiten der Skalierung nicht den gewünschten Anforderungen der Problemstellung. Dokumentenorientierte DBMS haben den Vorteil, dass Beziehungen einer Entität zusammen mit der Entität in einer Datei gespeichert werden. Dadurch lassen sich die Daten gut Skalieren. Diese Datenbankarchitektur ist innerhalb des CAP Theorem in den Bereichen CP oder AP anzutreffen. Dennoch bilden die dokumentenorientierten DBMS die in der Problembeschreibung erläuterte Datenstruktur ungenügend ab. Dokumentenorientierte DBMS sind aufgrund ihrer Architektur eher auf 1:N Beziehungen ausgelegt. N:M Beziehungen und komplexere Referenzen lassen sich schwer konsistent halten da das Design der Datenbanken eher auf wenige Dokumente mit direkten 1:1-Beziehungen und 1:N-Beziehungen beruht. Um die komplette gegebene Datenstruktur für den direkten Datenaustausch abbilden zu können, würde das Datenbankdesign viele Referenzen enthalten, deren Integrität zum Teil durch die Implementierung gewährleistet werden müsste. Daher scheidet auch diese Architektur für eine nähere Betrachtung aus. Spaltenorientierte DBMS bieten einen hohen Grad an Flexibilität bezogen auf die Datenstruktur. Auch ist das Resultat des Outputs der Datenbank, also ein Ergebnis in Form einer Tabelle, vergleichbar mit denen der verwendeten Datenbank. Eine eventuelle Umstellung würde also daher weniger Aufwand nach sich ziehen. Diese Architektur ist im CAP Spektrum in den Bereichen CP oder AP anzutreffen. Der Fokus liegt auch hier in der Partitionierung der Daten. Spaltenorientierte DBMS bieten keine referenzielle Integrität. Derartige Anforderungen 7.3.4 Vor-/Nachteile 25 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL müssten daher über die Schnittstelle umgesetzt werden. Da jedoch innerhalb der bestehenden Lösung kaum Fremdschlüssel verwendet werden, stellt dies aber kein Problem dar. Die Eigenschaften der spaltenorientierten DBMS eignen sich von den drei vorgestellten Architekturen am besten zur Lösung der Problemstellung. 8 Auswertung Verschiedene DBMS wurden untersucht und ausgewertet, daraus resultierten potentielle Architekturen, welche näher beleuchtet und verglichen wurden, um daraus bezüglich der Problemstellung eine geeignete Architektur zu finden. Nachdem potentielle Architekturen untersucht wurden und die Wide Column Stores die besten Voraussetzungen bieten, wurden gängige Vertreter dieser Architektur untersucht und verglichen. Nach einigen Recherchen ergaben sich als Repräsentanten der WCS: HBase, Hypertable und Cassandra. Der Vergleich erfolgte über eine Featurematrix. 8.1 Die Featurematrix Die Featurematrix ist das Herzstück des Evaluierungsprozesses. Sie besteht aus fünf Spalten. In Spalte eins sind die Kriterien, die untersucht wurden, aufgeführt. In den Spalten zwei bis vier sind die jeweiligen Vertreter der WCS zu sehen, welche in jeder Zeile für die Erfüllung eines Kriteriums eine ?1? beinhalten. In der letzten Spalte steht die Gewichtung eines Kriteriums. Die Auswertung erfolgt über ein Punktesystem und ganz klassisch gewinnt der Vertreter mit den meisten Punkten. Die Vergabe der Gewichtungen erfolgt nach Absprache und unter Bezug auf die Problemstellung. Kriterien, welche für die Problemstellung eine hohe Relevanz aufweisen, werden mit einer höheren Gewichtung versehen als sekundäre Kriterien. Jeder Vertreter wird pro Kriterienabschnitt wie z.B. Lizenzmodell oder Support in einer Summe und letztendlich durch einen Score zusammengefasst. Das Einteilen der Kriterienabschnitte und der einzelnen Kriterien ist sehr zeitaufwendig und natürlich immer mit einem gewissen subjektiven Anteil behaftet. Nachfolgend wird die Featurematrix aufgelistet. Hbase Hypertable Cassandra Gewicht Lizenzmodell - OpenSource - Kommerziell Summe Score ACID/BASE-Spektrum - Atomic at Row Level - Commitlog - MVCC - Archivierung - Turnable consistency - Strict Consistency - Eventual Consistency Summe Score 8 Auswertung 1 0,800 0,064 1 1 1,000 0,080 1 1 1,000 0,080 0,800 0,200 0,080 0,080 1 1 1 1 1 1 1 1 1 1 0,100 0,100 0,100 0,050 0,300 0,300 0,050 0,200 0,200 1 1 0,650 0,130 0,650 0,130 1 1 1 0,850 0,170 26 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Datentypen String Integer Boolean BigInteger (Int64) Datetime Text/Long Text Byte Double Summe Score Support 8/5 - Englisch 8/5 - Deutsch 24/7 - Englisch 24/7 - Deutsch Summe Score Dokumentation - Hersteller - Community - Literatur Summe Score API - C# Summe Score Skalierbarkeit - Multimaster - Master/Slave - Auto Sharding Summe Score Umgebung Windows Linux Summe Score Administration Monitoring 8.1 Die Featurematrix 1 1 1 1 1 1 1 1 1,000 0,040 1 1 0,300 0,021 1 0,125 0,005 1 1 1 1 1,000 0,070 1 1 1 1 1 1 1 1 1,000 0,040 0,125 0,125 0,125 0,125 0,125 0,125 0,125 0,125 0,040 0,040 1 0,100 0,200 0,200 0,500 0,070 0,070 1 0,300 0,021 1 1 1 1,000 0,100 1 1 1 0,500 0,050 0,750 0,075 0,500 0,250 0,250 0,100 0,100 1 1,000 0,050 1 1,000 0,050 1 1,000 0,050 0,050 0,050 0,050 1 1 1 1,000 0,200 1 1 1,000 0,200 1 1,000 0,200 0,500 0,500 0,500 0,200 0,200 1 0,500 0,005 1 1 1,000 0,010 1 1 1,000 0,010 0,500 0,500 0,010 0,010 1 1 1 1,000 27 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Summe Score 1,000 0,100 1,000 0,100 1,000 0,100 Programmiersprache der Implementierung Java C++ Java Erweiterbarkeit - Stored Procedures / Trigger Summe Score 1 1,000 0,050 Abfragemöglichkeiten - MapReduce - SQL ähnlich - Volltext - RegEx Summe Score Summe Tabelle 3: Featurematrix 1 0,250 0,025 0,785 0,000 0,000 0,000 1 1 1 1 1 0,750 0,075 0,770 0,500 0,050 0,796 0,100 0,100 1,000 0,050 0,050 0,250 0,250 0,250 0,250 0,100 0,100 1,000 8.2 Lizenzmodell Hbase Hypertable Cassandra Gewicht Lizenzmodell - OpenSource 1 1 1 - Kommerziell 1 1 Summe 0,800 1,000 1,000 Score 0,064 0,080 0,080 Tabelle 4: Auswertung der Lizenzmodelle 0,800 0,200 0,080 0,080 In der Softwareherstellung ist es üblich, das Rad nicht ständig neu zu erfinden, so werden also schon fertige Komponenten in ein Projekt integriert, jedoch ist es wichtig, für den späteren Vertrieb die Bedingungen des Lizenzvertrages jeder integrierten Komponente zu kennen. Dabei wird für die Untersuchung zwischen OpenSource (offener Quellen) und kommerziellen Vertrieb unterschieden. Mit Bezug auf die Umstände ausgehend der Problemstellung wird das Lizenzmodell OpenSource vorausgesetzt, um einen unkomplizierten und flüssigen Vertrieb zu gewährleisten. Alle drei Vertreter erfüllen diese Anforderung, doch HBase bietet im Gegensatz zu Cassandra und Hypertable nur das Lizenzmodell OpenSource an, was objektiv weniger ist als die beiden anderen Vertreter. Somit erfüllen Hypertable und Cassandra zusätzliche Eigenschaften im Abschnitt ?Lizenzmodell?, was mit einer größeren Flexibilität im Vertrieb verbunden ist. 8.3 ACID/BASE ? Spektrum Hbase Hypertable Cassandra Gewicht ACID/BASE-Spektrum 8.2 Lizenzmodell 28 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL - Atomic at Row Level 1 1 1 - Commitlog 1 1 1 - MVCC 1 1 - Archivierung 1 1 - Turnable consistency 1 - Strict Consistency 1 1 1 - Eventual Consistency 1 Summe 0,650 0,650 0,850 Score 0,130 0,130 0,170 Tabelle 5: Auswertung des ACID/BASE-Spektrums 0,100 0,100 0,100 0,050 0,300 0,300 0,050 0,200 0,200 In der Datenspeicherung ist es enorm wichtig, welchen Ansatz das Medium der Speicherung verfolgt. Wie im Abschnitt zu ACID/BASE bereits geklärt, kann ein Medium nicht alle Ansätze zu 100% gleichzeitig erfüllen, somit müssen die Ansätze der Produkte bezüglich der Problemstellung untersucht werden. Für die Auswertung ist hervorzuheben, das Cassandra mit ihrer Eigenschaft, sich auf die Erfüllung des Spektrums, variabel auf den Sinn und Zweck des Produktes einzustellen, am besten in dieser Kategorie abschneidet. 8.4 Datentypen Hbase Hypertable Cassandra Gewicht Datentypen String 1 1 Integer 1 Boolean 1 BigInteger (Int64) 1 Datetime 1 Text/Long Text 1 Byte 1 Double 1 Summe 1,000 0,125 Score 0,040 0,005 Tabelle 6: Auswertung der Datentypen 1 1 1 1 1 1 1 1 1,000 0,040 0,125 0,125 0,125 0,125 0,125 0,125 0,125 0,125 0,040 0,040 Für die Problemstellung ist es wichtig, den genauen Datentyp einer gespeicherten Information zu kennen, somit entfällt das Parsen von einem Datentyp zu einem anderen und es gibt weniger Komplikationen in der Bedeutung der einzelnen gespeicherten Werte. HBase und Cassandra unterstützen alle relevanten Datentypen, somit erfüllen sie alle Anforderungen im Gegensatz zu Hypertable. 8.3 ACID/BASE ? Spektrum 29 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 8.5 Support Hbase Hypertable Cassandra Gewicht Support 8/5 - Englisch 1 1 8/5 - Deutsch 1 24/7 - Englisch 1 1 24/7 - Deutsch 1 Summe 0,300 1,000 Score 0,021 0,070 Tabelle 7: Auswertung des Supports 1 1 0,300 0,021 0,100 0,200 0,200 0,500 0,070 0,070 Sofern man nicht über geschultes Personal verfügt, ist ein gut verfügbarer Support enorm wichtig, sowohl für Hersteller, also auch für Nutzer. Für die Problemstellung sind die Formen acht Stunden an fünf Tagen in der Woche und Vollzeit 24 Stunden an sieben Tagen die Woche relevant. Um hier eine gewisse Flexibilität aufzuweisen, sind der Support sowohl in deutscher als auch in englischer Sprache akzeptabel. HBase und Cassandra bieten aufgrund ihrer noch geringen Popularität nur einen Support in englischer Sprache an, im Gegensatz zu Hypertable, welche alle Supportformen unterstützt, welche für den deutschen Markt relevant sind. 8.6 Dokumentation Hbase Hypertable Cassandra Gewicht Dokumentation - Hersteller 1 1 1 - Community 1 1 - Literatur 1 Summe 1,000 0,500 0,750 Score 0,100 0,050 0,075 Tabelle 8: Auswertung der Dokumentationen 0,500 0,250 0,250 0,100 0,100 Herstellerinformationen, Erfahrungsberichte und professionelle Anwendertipps sowie Rezensionen sind für den Einsatz neuer Technologien wichtig und sogar unverzichtbar. Es wird in der Herkunft der Informationen unterschieden, bereitgestellt vom Hersteller, den Communitys oder aus der Literatur. Dabei wurde die Fülle der Informationen der Hersteller untersucht, was bei allen Vertretern ausreichend ist. In einschlägigen Gruppenportalen findet man Tests, Vergleiche und Nutzertipps von HBase und Cassandra, zusätzlich bietet HBase eine große Auswahl an Fachliteratur. HBase bietet ein umfangreiches Angebot, sich ausgiebig über das Produkt zu informieren. 8.5 Support 30 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 8.7 API Hbase Hypertable Cassandra Gewicht API - C# 1 1 1 Summe 1,000 1,000 1,000 Score 0,050 0,050 0,050 Tabelle 9: Auswertung der API 0,050 0,050 0,050 Ausgehend von der Problemstellung ist es erforderlich, dass die Produktapi eine Schnittstelle zu C# aufweisen muss. HBase, Hypertable und Cassandra bieten diese Schnittstelle an. 8.8 Skalierbarkeit Hbase Hypertable Cassandra Gewicht Skalierbarkeit - Multimaster 1 - Master/Slave 1 1 - Auto Sharding 1 1 1 Summe 1,000 1,000 1,000 Score 0,200 0,200 0,200 Tabelle 10: Auswertung der Skalierbarkeit 0,500 0,500 0,500 0,200 0,200 In Zeiten steigender Anforderungen ist das Verteilen von Systemen enorm wichtig. Alle untersuchten Produkte bieten ein Multimaster- oder Masterslavesystem. Zusätzlich dazu bieten alle drei Produkte einen Autoshardingmechanismus. 8.9 Umgebung Hbase Hypertable Cassandra Gewicht Umgebung Windows 1 1 Linux 1 1 1 Summe 0,500 1,000 1,000 Score 0,005 0,010 0,010 Tabelle 11: Auswertung der Umgebung 0,500 0,500 0,010 0,010 Für die Problemstellung ist es wichtig, dass die untersuchten Produkte flexibel im Zusammenspiel mit dem Betriebssystem sind. Somit müssen Kunden und Hersteller sich nicht festlegen oder umstellen. HBase bietet bisweilen nur vollständige Unterstützung für Linuxsysteme. Cassandra und Hypertable laufen auf allen gängigen 8.7 API 31 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Systemen, was eine höhere Flexibilität beinhaltet. 8.10 Administration Hbase Hypertable Cassandra Gewicht Administration Monitoring 1 1 1 1,000 Summe 1,000 1,000 1,000 0,100 Score 0,100 0,100 0,100 0,100 Tabelle 12: Auswertung der Administrationskomponenten In Zeiten des Internets und der Globalisierung ist die Überwachung und Wartung des Produktes von verschiedenen Standorten ein wichtiger Teil des Serviceangebot eines Softwareunternehmen. Alle drei untersuchten Produkte verfügen über Mechanismen für das Monitoring. 8.11 Erweiterbarkeit Hbase Hypertable Cassandra Gewicht Erweiterbarkeit - Stored Procedures / Trigger 1 Summe 1,000 Score 0,050 0,000 Tabelle 13: Auswertung der Erweiterbarkeit 1,000 0,050 0,050 0,000 0,000 Bei der Benutzung von Datenbanksystem kann die Möglichkeit, die internen Funktionen einer Datenbank zu erweitern,viele Vorteile bringen. HBase ist das einzige untersuchte Produkt, welches die Möglichkeit bietet, Funktionen hinzuzufügen oder zu erweitern. 8.12 Abfragemöglichkeiten Hbase Hypertable Cassandra Gewicht Abfragemöglichkeiten - MapReduce 1 1 1 - SQL ähnlich 1 1 - Volltext - RegEx 1 Summe 0,250 0,750 0,500 Score 0,025 0,075 0,050 Tabelle 14: Auswertung der Abfragemöglichkeiten 8.9 Umgebung 0,250 0,250 0,250 0,250 0,100 0,100 32 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Die untersuchten Produkte bieten verschiedene Formen von Abfragemöglichkeiten, wobei alle untersuchten Produkte das MapReduceverfahrne unterstützen. Doch Hypertable unterstützt daneben eine SQL ähnliche Abfragesprache sowie eine Suche mittels regular Expressions. So bietet Hypertable die meisten Abfragemöglichekeiten. 8.13 Auswertung Abbildung 14: Balkendiagramm für die Auswertung der Featurematrix Im direkten Vergleich bietet Cassandra die meisten Vorteile und kommt als Lösung für die Problemstellung in Betracht. Doch zusammengefasst liegen alle Produkte nach Punkten dich bei einander und unterscheiden sich nur in sehr speziellen Bereichen. Das ist begründet durch die Tatsache, dass alle drei untersuchten Produkte der selben Architektur angehören. 9 Fazit Zusammenfassend lässt sich sagen, dass sich das Datenbankmanagementsystem Cassandra für die gesamte Problemstellung am besten eignet. Während des Evaluierungsprozesses hat sich herausgestellt, dass der Aufwand aufgrund der Fülle der unterschiedlichsten Datenbankarchitekturen und Produkte nicht zu unterschätzen ist. Es ist jedoch zu beachten, dass sich das aus der Evaluierung hervorgegangene Produkt Cassandra für die oben beschriebene Problemstellung eignet und sich nicht automatisch auf ein anderes Problem übertragen lässt. Unter dem Begriff NoSQL existieren viele unterschiedliche Datenbanksysteme die jeweils ihre Vor- und Nachteile haben. Es ist also erforderlich, ein geeignetes System bezogen auf die Individuelle Probleme zu ermitteln. Als Schwierigkeit erwies sich die Ausgangssituation mit einer Komponente, die als Schnittstelle für den Datenaustausch zwischen Datenbank und beliebigen Applikationen dient und die unterschiedlichen Datenkategorien und deren Anforderungen innerhalb des CAP Theorems. Die Entscheidung über ein geeignetes DBMS ist von den CAP Abwägungen abhängig. Generell haben NoSQL-Datenbanken die Frage aufgeworfen, ob eine strikte Konsistenz, wie sie bei RDBMS gegeben ist, überhaupt für alle Datenkategorien notwendig sind. Es empfiehlt sich, so wie hier vorgestellt, ausgehend von der Problemstellung aus dem großen Fundus von unterschiedlichsten Datenbanksystemen das geeignetste Produkt zu ermitteln. Letztendlich ist zu erwähnen, dass NoSQL-Datenbanken nicht automatisch Relationale Datenbanksysteme ablösen können. Jedes System hat seine Vor- und Nachteile und es obliegt den Entwicklern ein geeignetes System aus dieser Vielzahl von Datenbankmanagementsystemen auszuwählen. So kann es auch sinnvoll sein, an bestehenden Lösungen festzuhalten. Aufgrund der möglichen Eigenschaften, z.B. Skalierbarkeit, Performance, lohnt sich jedoch die Prüfung und gegebenenfalls eine Teilmigration. 9.1 Evaluierungsphase Innerhalb der Evaluierungsphase ist es wichtig den roten Pfad sowie den Bezug zur Motivation und Problemstellung nicht zu verlieren. Mittels immer feiner werdenden Filter während der Evaluierungsphase, 9 Fazit 33 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL konnte schlussendlich, bezogen auf die Problemstellung ein passendes NoSQL-Produkt festgestellt. Diese Herangehensweise hat sich während der Fallstudie als äußerst praktikabel erwiesen und kann für weitere Evaluierungskonzept empfohlen werden. 9.2 Wirtschaftlichkeit Ein Wechsel ist mit Kosten verbunden. Dazu muss der Umstieg oder das Integrieren eines neuen DBMS grob in drei Abschnitte gegliedert werden, Konzeption, Einführung und zuletzt die Wartung. 1. Konzeption Die Informationen über NoSQL sind vielfältig. Von Fachliteratur bis Benutzerwertungen sind alle Arten an Informationsquellen vertreten. Für ein Team, welches eine Benutzung eines DBMS vorbereiten soll, müssen folgende Ressourcen zur Verfügung stehen: Personal, Kapital und Zeit. Diese Arbeit beschäftigt sich hauptsächlich mit dem Evaluierungsprozess, dafür mussten viele Informationen gesammelt, aufbereitet, verarbeitet und ausgewertet werden. Es muss also geschultes Personal für diesen Prozess eingestellt, oder vorhandenes Personal muss geschult werden, wofür ebenfalls wieder Kapital und Zeit benötigt wird. Am Ende der Konzeptionsphase ist nicht einmal gesichert, dass die Integration überhaupt stattfinden wird. 1. Einführung Das Konzept, welches lange geplant und finanziert wurde, wird nun in die Entwicklungsprozesse integriert. Schnittstellen müssen geschaffen werden, die Entwicklung muss mit dem neuen Produkt neu verschmolzen, die Entwicklungsprozesse müssen bezüglich der Integration des neuen DBMS angepasst werden. Diese Abläufe müssen wieder geplant, durchgeführt und überwacht werden. Dafür werden wieder Ressourcen in Form von Personal, Kapital und Zeit benötigt. 1. Wartung Das neue Produkt muss selbstverständlich kontrolliert und gewartet werden, was geschultes Personal oder den Einsatz von Fremdfirmen erfordert. Man benötigt viel Zeit und man darf die Höhe der aufzubringen Ressourcen für eine Integration des neuen Produktes nicht unterschätzen, dieser Tatsache muss man sich bewusst sein und bereit sein, die erforderlichen Ressourcen zu investieren. 9.3 Ausblick NoSQL-Datenbanken sind keine Eierlegendenwollmichsäue sondern entfalten ihre Stärken aufgrund ihrer Spezialisierung. Aus diesem Grund sollte man ohne die Complexity Costs zu vernachlässigen immer einen Architekturmix in Betracht ziehen. Deshalb ist es ökonomisch sinnvoll, nur Bereiche umzustellen die auch einen 9.1 Evaluierungsphase 34 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL entsprechenden Gewinn oder Leistungszuwachs erwarten lassen. So kann man z.B. das Caching in eine Key-Value Datenbank auslagern um einen Geschwindigkeitszuwachs zu erhalten oder zusammenhängende Datensätze wir z.B. Belege aus der Warenwirtschaft in einer Dokumentenorientierten Datenbank zu archivieren. Oft macht es jedoch auch Sinn, wie bei Businessdaten diese in Relationalen Datenbanken zu belassen insbesondere dann wenn Ihre natürliche Darstellung bereits in Tabellenform ist. ?Wer neue Heilmittel scheut, muss alte Übel dulden.[71]? 10 Fußnoten 1. ? Facebook (2012) 2. ? Vgl. EMC Corporation (2012) 3. ? Central Intelligence Agency (2012) [3] 4. ? Vgl. EMC Corporation (2012) 5. ? Vgl. Wallroth, S. (2007) 6. ? Vgl. Wallroth, S. (2007) 7. ? Vgl. Wallroth, S. (2007) 8. ? Vgl. Rotem-Gal-Oz,A. (2012) 9. ? Vgl. Elmasri, R. et al. (2010) S.2 10. ? Vgl. Elmasri, R. et al. (2010) S.729 11. ? Nach Süß,N. et al. (2012) 12. ? Vgl. Elmasri, R. et al. (2010) S.971 13. ? Vgl. Vogels, W. (2012) 14. ? Vgl. Brewer, E. (2000) 15. ? Vgl. Gilbert, et. al. S. (2002) 16. ? Vgl. Edlich, et. al. (2010) S. 32 17. ? Vgl. Browne, J. (2009) 18. ? Edlich, et. al. (2010) S. 32 19. ? Edlich, et. al. (2010) S. 32 20. ? Vgl. Vogels, W. (2012) 21. ? Vgl. Brewer, S. 22. ? Edlich, et. al. (2010) S. 31 23. ? Vgl. Edlich, et. al. (2010) S. 56 24. ? Vgl. Faeskorn-Woyke, H. (2012) 25. ? Vgl. Edlich, et. al. (2010) S. 54 26. ? Vgl. Edlich, et. al. (2010) S. 57 27. ? Vgl. Edlich, et. al. (2010) S. 58 28. ? Vgl. Sheety,J. (2010) 29. ? Vgl. Edlich, et. al. (2010) S. 59 30. ? Vgl. TEDIC GmbH (2010) 31. ? Vgl. Schnelle,J. (2010) 32. ? Vgl. Edlich, et. al. (2010),S.116 33. ? Vgl. Tiwari,S. (2011),S.18 34. ? CouchDB (2012) 35. ? Vgl. Bertelsmeier, B. (2012) 36. ? Vgl. Gull, C. (2011), S.21 37. ? Vgl. MongoDB (2012) 10 Fußnoten 35 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL 38. ? Vgl. CouchDB (2012) 39. ? Vlg. Edlich, et. al. (2010), S. 53 40. ? Vgl. Geisler, F. (2006), S.62. 41. ? Vgl. Faeskorn-Woyke, H. (2011) 42. ? Vlg. Edlich, et. al. (2010), S. 53 43. ? Vgl. Faeskorn-Woyke, H. (2011) 44. ? Vgl. Faeskorn-Woyke, H. (2011) 45. ? Vgl. Faeskorn-Woyke, H. (2011) 46. ? Vgl. Faeskorn-Woyke, H. (2011) 47. ? Vgl. Wolff, E. & Spichale, K. (2012), S. 30 48. ? Vgl. Grinev, M. (2010) 49. ? Vlg. Edlich, et. al. (2010), S. 53 50. ? Vlg. Edlich, et. al. (2010), S. 53 51. ? Vgl. Faeskorn-Woyke, H. (2011) 52. ? Vgl. Rosenberger, Carl (2007) S.8 53. ? Vgl. Göers, Jutta (1995) 54. ? Vgl. Kersken, Sascha (2008) S. 447 55. ? Vgl. Grehan, Rick (2007) S.1 56. ? Vgl. db4objects, Inc. (2007) S.1 57. ? Vgl. Neumann, Alexander (2011) S. 2 58. ? Vgl. Neumann, Alexander (2011) S. 2 59. ? Vgl. Lemay, et. al. (2001) S. 60ff 60. ? Vgl. Lemay, et. al. (2001) S. 60ff 61. ? Vgl. Lemay, et. al. (2001) S. 60ff 62. ? Vgl. Lemay, et. al. S. 60ff 63. ? Vgl. db4objects, Inc. (2007) S.1 64. ? Vgl. db4objects, Inc. (2007) S.6 65. ? Vgl. Bloch, Joshua (2005) S. 39 66. ? Vgl. Grehan, Rick (2007) S. 12 67. ? Vgl. Brenner, Ina (2007) S. 24 68. ? Vgl. db4objects, Inc. (2007) S.5 69. ? Vgl. db4objects, Inc. (2007) S.3 70. ? Vgl. db4objects, Inc. (2007) S.3 71. ? Francis Bacon (1561-1626) - Philosoph 11 Literatur- und Quellenverzeichnis Kurzverweis Facebook (2012) EMC Corporation (2012) Central Intelligence Agency (2012) Wallroth, S. (2007) Quelle Facebook 2012: Key Facts - Facebook News. URL:http://newsroom.fb.com/content/default.aspx?NewsA EMC Corporation 2012: Digital Universe Study. URL:http://germany.emc.com/leadership/programs/dig Central Intelligence Agency 2012: CIA - Factbook. URL:https://www.cia.gov/library/publications/the-w 06.2012. Wallroth, S. 2007: Das uneindeutig unklare Duo: Horizontales Skalieren und Vertikales Skalieren. URL:http://habacht.blogspot.de/2007/11/das-uneindeutig-unklare-duo-scale-out.html , Abruf am 08.201 Rotem-Gal-Oz,A. 2012: Fallacies of Distributed Computing Explained. URL:, Abruf am 08.2012. 11 Literatur- und Quellenverzeichnis 36 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Rotem-Gal-Oz,A. (2012) Elmasri, R. et al. Elmasri, R. & Navathe,B. (2010): Database Systems, 6th ed., Global ed. 2010.. Aufl., Boston (USA) 201 (2010) Süß,N. et al. Süess,N. & Vollenweider,M. 2012: CAP Theorem, ACID & BASE . (2012) URL:http://web.fhnw.ch/plattformen/mvdbs/modulunterlagen/nosql/cap-theorem-acid-base, Abruf am 0 Vogels, W. Vogels, W. 2012: Eventually Consistent - Revisited. URL:http://www.allthingsdistributed.com/2008/12 (2012) 08.2012. Brewer, E. Brewer, E. 2000: Towards Robust Distributed Systems. URL:Towards Robust Distributed Systems, Abr (2000) Gilbert, et. al. S. Gilbert, S. & Lynch, N. 2002: Brewer's Conjeture and the Feasibility of Consistent, Available, Partition(2002) URL:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf, Abruf am Edlich, et. al. Edlich, S. & Friedland, A. & Hampe, J. & Brauer, B. (2010): NoSQL - Einstieg in die Welt nichtrelation (2010) 2010 Browne, J. Brown, J. 2009: Brewer's CAP Theorem. URL:http://www.julianbrowne.com/article/viewer/brewers-cap (2009) Faeskorn-Woyke, Faeskorn-Woyke, H. 2012: MVCC - Multiversion Concurrency Control. URL:http://wikis.gm.fh-koeln. H. (2012) 05.12. Sheety,J. (2010) Sheety,J. 2010: Why Vector Clocks Are Hard. URL:http://basho.com/blog/technical/2010/04/05/why-ve TEDIC GmbH 2010: Datenmodelle und Einsatz dokumentorientierter Datenbanken. TEDIC GmbH URL:http://tedic.de/en/technology/database/306-datenmodelle-und-einsatz-dokumentorientierter-datenb (2010) Abruf am 08.2012. Schnelle,J. Schnelle,J. 2010: NoSQL ? Jenseits der relationalen Datenbanken. URL:http://www.pro-linux.de/artikel (2010) CouchDB (2012) CouchDB 2012: Why CouchDB?. URL:http://guide.couchdb.org/editions/1/en/why.html, Abruf am 07.2 Tiwari,S. (2011) Tiwari, S. 2011: Professional NoSQL, 1. Aufl., Indianapolis, USA 2011 Gull, C. (2011) Gull, C. 2011: web-Applikationen entwickeln mit NoSQL, 1. Aufl., München 2011 Bertelsmeier, B. Bertelsmeier, B. 2012: CouchDB. URL:http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/CouchDB, A (2012) CouchDB (2012) CouchDB 2012: The Core API. URL:http://guide.couchdb.org/draft/api.html, Abruf am 07.2012. MongoDB MongoDB 2012: MongoDB API. URL:http://api.mongodb.org/, Abruf am 07.2012. (2012) Geisler, F. (2006) Geisler, F. (2006): Datenbanken. Grundlagen und Design, 2. Aufl., Heidelberg 2006 Faeskorn-Woyke, Faeskorn-Woyke, H. 2011: Spaltenorientierte Datenbanksysteme. H. (2011) URL:http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/SpaltenorientierteDatenbank, Abruf am 08.1012 Faeskorn-Woyke, Faeskorn-Woyke, H. 2011: Cassandra. URL:http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/Cassand H. (2011) Faeskorn-Woyke, Faeskorn-Woyke, H. 2011: Keyspace. URL:http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/Keyspac H. (2011) Wolff, E. & Spichale, K. Wolff, E. & Spichale, K. 2012: NoSQL: Konzepte und Prinzipien, in: Java Magazin 2012, Nr. 4, S. 28-3 (2012) Grinev, M. Grinev, M. 2010: Grinev. URL:http://maxgrinev.com/2010/07/12/do-you-really-need-sql-to-do-it-all-in(2010) 11 Literatur- und Quellenverzeichnis 37 Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL Göers, Jutta (1995) Grehan, Rick(2007) Göers, Jutta 1995: Objektorientierte Datenbanken -- Entstehung, Konzepte, Systeme. URL:http://www.informatik.uni-osnabrueck.de/um/95/95.1/oodb/oodb.html, Abruf am 01.08.2012. Grehan, Rick 2007: The Database Behind the Brains. URL:http://www.db4o.com/deutsch/db4o%20Whitepaper%20-%20The%20Database%20Behind%20th 03.07.2012. Visengeriyeva, L. Visengeriyeva, Larysa et.al. (2007): db4o, 1. Aufl., entwickler.press (2007) Kersken, Sascha Kersken, Sascha (2008): IT-Handbuch für Fachinformatiker, 4. Aufl., Galileo Computing (2008) db4objects, Inc. db4objects, Inc. 2007: Product Information. URL:http://www.db4o.com/deutsch/db4o%20Product%20I (2007) Abruf am 10.07.2012. Neumann, Neumann, Alexander 2011: GraphDB identifiziert Zusammenhänge zwischen Wikipedia-Einträgen. Alexander (2011) URL:http://www.heise.de/ix/meldung/GraphDB-identifiziert-Zusammenhaenge-zwischen-Wikipedia-Ei Lemay, et. al. Lemay, Laura , Cadenhead, Roger (2001): Java2 in 21 Tagen, 1. Aufl., Markt+Technik Verlag (2001) Brenner, Ina Brenner, Ina 2007: Datenbankentwicklung mit db4o. (2007) URL:http://1895312/03bfa2d5/downloading/community.versant.com/Projects/html/projectspaces/db4oBloch, Joshua Bloch, Joshua (2002): Effektiv Java programmieren, 1. Aufl., Addison-Wesley (2005) 11 Literatur- und Quellenverzeichnis 38
