The R(E)volution of Data Stores

Transkript

1 The R(E)volution of Data Stores

2 Willkommen Schön, dass sie in diese Session kommen, ich bin Dominik Wagenknecht NoSQL Initiative Lead Technology Architect Accenture Wien Mobil: Fragen? Jederzeit! 2

3 Accenture Architecture Innovation Technologieradar PaaS Dynamic languages OSS Business Rules Automation Inner Source BPM Distributed Architectures Distributed Caching Techniques Hadoop EDA / CEP Architecture Innovation Data Architecture Principles and Practices Digital Solutions Lightweight Architectures XD A4 Tool IaaS NoSQL Data storage 3

4 Es tut sich was im Datenbankmarkt. Die Datenmenge steigt, schneller als antizipiert, und die Natur der Daten ändert sich. Daten sind Groß Die Komplexität wächst Gespeicherte Daten in Exabytes (10 18 ) Datenverlust Agilität Struktur Kosten Echtzeit / Anlytics WIE Infrastruktur Service Levels unstrukturiert Source: IDC s Digital Universe Study (sponsored by EMC), June

5 Ganz klar: Ein neues Buzzword musste her und jeder ist dabei Source: geekandpoke.com 5

6 Basierend auf einem soliden theoretischen Fundament werden aktuelle Data Stores aus verschiedenen Blickwinkeln betrachtet Agenda des Workshops Intelligente Entscheidungen für den richtigen Datenstore ermöglichen Kurze Zusammenfassung von Schlüsselbegriffen Das Paper, das alles verändert hat Bigtable Ein theoretisches Fundament welches den Möglichkeitsraum eines verteilten Systems absteckt CAP Ein Modell durch welches Daten gleichmäßig verteilt und mit konfigurierbarer Konsistenz gespeichert werden können Dynamo Klassifizierung von NoSQL Datenbanken Relevante Stores aus Architektonischen Gesichtspunkten Evaluierung der Tradeoffs basierend auf der Natur der Daten, erforderlicher Performance und Abfragekomplexität 6

7 Skalierungs und Verteilungsansätze sind die Grundlage für die folgende Diskussion Schlüsseltermina Sharding/Datenverteilung Die Daten sind zu groß um auf einer Maschine gespeichert (geschweige denn analysiert) zu werden Stückelung Aktiv/Passiv Einfache Hochverfügbarkeitsmaßnahme. Eine passive Maschine steht bereit sollte die Aktive ausfallen. Master/Slave Klassisches Skalierungsmodell. Konsistenz bei Schreibvorgängen wird über den Master sichergestellt, Abfragen über Slave(s) skaliert Locks/Versioning Strategien um mit dem gleichzeitigen Zugriff mehrerer Anwendungen umzugehen und dennoch konsistent zu sein; entweder man blockt oder verwaltet Versionen. 7

8 Die ACID Eigenschaften von relationalen Datenbanken bringen leider auch gewisse Nachteile mit sich Womit klassische RDBMS kämpfen Skalierbarkeit Latenz Rigidität des Schemas Teure Hardware Skalierbarkeit und Amdahlsches Gesetz: Nach Amdahl wird der Geschwindigkeitszuwachs vor allem durch den sequentiellen Anteil des Problems beschränkt, da sich dessen Ausführungszeit durch Parallelisierung nicht verringern lässt. 8

9 Daten wachsen, aber sie ändern sich auch und sie müssen auf immer neue Arte zur Verfügung stehen Eine neue Art von Daten Firmen wie Amazon, Google und Facebook hatten es als erste mit neuen (Daten)Herausforderungen zu tun, selbige: Fallen global an, werden global angefragt Müssen mit niedriger Latenz verfügbar sein Semi- bis unstrukturiert Und: Groß! Collective Content: The External Information Deluge Die Antwort Neue DB s Neue Zugriffsmuster Source: Gartner (September 2010) 9

10 Google ist ein Pionier von BigData und hat mit MapReduce und BigTable die relevantesten Artikel dazu veröffentlicht Google Bigtable: Die Definition von großen Daten Präsentiert auf der OSDI 2006 findet sich das Ziel schon im Abstract: Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers. Warum? Pagerank! Eine Karte des gesamten Web speichern, bereit für die Analyse Gigantische Tabelle mit flexiblen Spalten (dünnbesetzt) Jede Zeile = eine Webseite / URL Spalten sind z.b. gesamter HTML-Code, Sprache, die Links, die Anzahl variiert stark abhängig von der Webseite Zugriff per Zeilen- und Spaltenschlüssel sowie Zeitstempel (Historie!), garbage collection für alte Daten (konfigurierbar) fortgesetzt 10

11 Die Veröffentlichung von BigTable führte zum Hadoop Projekt welches BigTable & MapReduce OpenSource implementiert Google Bigtable: Schema und Funktionsweise Bigtable s Datenmodell ist konzeptionell simpel: Spaltengruppierung in families Für jede Zeile kann jede column family beliebig viele Spalten enthalten Einzelne Zeile wird nie verteilt, und ist stets konsistent und wurde in Hadoop folgendermaßen umgesetzt: Hadoop Distributed File System: Organisiert in Blöcken und repliziert über mehrere Server plus zentrale Name Node für Metadaten HBase: Die BigTable Implementierung welche auf HDFS aufsetzt und ad-hoc Zugriffe mit RDBMS-ähnlichen Eigenschaften 11

12 Das CAP Theorem besagt, dass sich ein verteiltes System in seinen Eigenschaften entscheiden muss CAP Consistency, Availability and Partition tolerance CAP beweist, dass eine verteilte Datenbank welche Consistent Konsistent (Schreibvorgänge sind atomar und folgende Lesevorgänge bekommen den neuen Wert), und Available Verfügbar (die Datenbank wird Zugriffe bearbeiten so lange ein einziger Server läuft), und Partition tolerant Partitionstoleranz (das System wird weiter funktionieren, selbst wenn die Kommunikation zwischen Servern temporär verloren geht) stets nur zwei dieser Eigenschaften haben kann CAP wurde 2000 von Eric Brewer als Therem formuliert und 2002 von Seth Gilbert und Nancy Lynch (beide MIT) bewiesen. Eine intuitive (englische) Erklärung findet sich hier: 12

13 Das CAP Theorem sollte nicht religiös angewandt werden, es ist aber relevant die entstehenden Abwägungen zu verstehen CAP Auswirkung im Praxisbetrieb Typischerweise hat ein System einen Fokus, Extrembeispiele: CA: RDBMS C A AP: DNS CP: Banking Es ist wichtig die Auswirkungen zu verstehen, um bei der richtigen Wahl für die Applikation zu helfen. Partitionstoleranz (P) ist bei verteilten Systemen Pflicht, daher kommt es zu einer Abwägung zwischen Konsistenz und Verfügbarkeit (BASE). P 13

14 Amazon s Dynamo ist eine äußerst elegante Methode um Daten gleichmäßig zu verteilen und darauf zuzugreifen Dynamo: Grundlagen Daten identifiziert durch Schlüssel Position im Ring wird durch konsistentes Hashing ermittelt Prüfsummenergebnis befindet sich innerhalb eines ekannten Zahlenraums Partitionierung Was ist speziell daran? Jede Node ist exakt gleich Nahezu-lineare skalierbarkeit Replikation ist direkt eingebaut, man nehme N Nodes danach Amazon Dynamo wurde 2007 am SOSP vorgestellt Illustrations: wiki.basho.com fortgesetzt 14

15 Beeindruckend an Dynamo ist, dass jede Anwendung die Abwägung zwischen Konsistenz und Verfügbarkeit selbst trifft Dynamo: Konfigurierbare Konsistenz Positionierung innerhalb von CAP (Annahme: 3 Repliken) Es ist unmöglich P, zu opfern da verteilt A AP: Trotz 3 Repliken wird stets von einer gelesen und zu einer geschrieben. Typische Implementierungen erlauben die Konfiguration von/zu wie vielen Nodes gelesen/geschrieben werden soll pro Aufruf. Daher kann man je nach Kritikalität und Performancebedarf flexibel entscheiden wie vorgegangen werden soll. C P CP: Beschluss jeden Schreib- als auch Lesevorgang gegen alle Repliken auszuführen 15

16 Die derzeit meistverbreitete Klassifizierung baut darauf auf, wie die Datenbanken ihre Daten speichern und verknüpfen. Eine Klassifikation Key-Value Das Einfachste : Ein beliebiger Wert (Binär) wird unter einem Key (meist auch Binär) abgelegt Spaltenorientiert Dem Paper von Google folgend sind dies extrem große Dünnbesetzte Matrizen Dokumentenbasiert Ein Key wird assoziiert mit einem Dokument (oftmals JSON). Die DB kann mit den Werten arbeiten. Graphen Knoten und Kanten zwischen ihnen kombiniert mit leistungsfähigen Abfragemöglichkeiten ergeben Möglichkeiten die mit RDBMS kaum realisierbar sind. Key Value C1 C2 C3 C4 C5 A 1 Z B Fr Z C 2 En D 3 GE Z 16

17 Redis und Riak zeigen zwei Extreme: Geschwindigkeit bei Redis und auf Skalierbarkeit bei Riak Key-Value: Redis, Riak Kurz Redis Nicht nur Key/Value, hat Listen, Queues, usw Riak Dynamo basierter KV Store mit Metadaten für Links, Indizes, Skalierbarkeit Cluster Datencenter Replikation Master/Slave Master/Master Konsistenz Eventuell (verzögerter Sync) Konfigurierbar Schnittstellen Text auf TCP HTTP, protobuf Warum Geschwindigkeit! O Notation für jede Operation Für: Sessions, Caches, beliebige Datenobjekte, usw Hochverfügbar, Links, Map Reduce bald Dokumenten DB Andere: Voldemort, LevelDB (eine Bibliothek von Google) 17

18 Während HBase mit direkter Integration in Hadoop glänzt ist Cassandra ohne Master sehr flexibel Spaltenorientiert: HBase, Cassandra Kurz HBase Original OpenSource Implementierung von BigTable Skalierbarkeit Datencenter Cassandra Dynamo basierte BigTable Implementierung Datencenter Replikation Master/Slave Master/Master Konsistenz Konsistent (Zeile) Konfigurierbar Schnittstellen HTTP, Thrift Warum Für sehr große Anwendungen, direkte Hadoop Integration HTTP, Thrift Perfekt für sehr hohe Schreibraten im tabellarischen Format, Abfragefunktionen Für: Große schwach besetzte Matrizen: Logging, meter, s, Andere: Hypertable, DynamoDB (SaaS) 18

19 Während MongoDB auf einfache Nutzung und vertraute Features setzt, punkt CouchDB mit Robustheit und Durability Dokumentenbasiert: MongoDB, CouchDB/BigCouch Kurz MongoDB Einfaches BigData mit vertrauten Funktionen wie ad-hoc Abfragen Skalierbarkeit Cluster/Datencenter CouchDB/BigCouch Let-it-crash Philosophy, ungemein Robust BigCouch = Dynamo + CouchDB Datencenter Replikation Master/Slave Master/Master Konsistenz Eventuell Konfigurierbar Schnittstellen Custom TCP, Basis HTTP HTTP Warum Abfragbarkeit, MapReduce, niedrige Einstiegsschwelle MapReduce, _changes feed, skaliert bis zum Mobiltelefon Für: Datengetriebene Applikationen mit flexiblem Schema (kein ORM!) Andere: RavenDB (.net), oder content repositories wie JackRabbit 19

20 Neo4J bietet beindruckende Abfragen und ad-hoc Realtionen, zahlt jedoch den Preis durch fehlendes Sharding Graph DB: Neo4J Neo4J Kurz Nach unserer Überzeugung die derzeit einzige relevante Graphendatenbank, Robust, kann allerdings nicht Sharden Skalierbarkeit Cluster (via HA) Replikation Konsistenz Master/Slave Eventuell; verzögerte Replikation von Transaktionen, ACID Schnittstellen Typischerweise Embedded (100% Java) und/oder HTTP Warum Power des Graphenmodells >> RDBMS Modell Hervorragende Abfragemöglichkeiten und Beziehungen Für: Alles was Netzwerk ist : Sozial/CRM, Bestände bis Logistik Andere: InifiniteGraph, HyperGraphDB 20

21 Daten lassen sich bezüglich ihrer Performanz und Abfragekomplexität in eine Matrix eingeordnen Eine Klassifikation Dies ist eine sehr grobe Einteilung, zeigt jedoch klar die Extreme zwischen schnellen KV-Stores (Redis) und Graph DB s die in msec s die Freunde 8ten Grades bestimmen können (= 8x inner join auf RDBMS) KV Stores Key Value Spaltenorientiert C1 C2 C3 C4 C5 A 1 Z B Fr Z C 2 En D 3 GE Z Dokumentenorientiert Performance Graphen Die meisten Applikationen befinden sich hier Kein Union/Join Abfragekomplexität Rekursive Abfrage 21

22 Vielen Dank! 22