Weniger ist mehr? Skalierbares Datenmanagement zwischen NoSQL und klassischen DBS

Transkript

1 Weniger ist mehr? Skalierbares Datenmanagement zwischen NoSQL und klassischen DBS Herbsttreffen der FG DB, 17./ Kai-Uwe Sattler Ilmenau University of Technology, Germany

2 Stell dir vor GB Daten 1000 Nutzer/Tag 2

3 ... doch dann GB Daten Nutzer/Tag 3

4 Gliederung Skalierung von Datenmanagement Benchmarking für Skalierbarkeit Techniken für skalierbares Datenmanagement NoSQL als Alternative? Fazit 4

5 Scale up vs. Scale out Scale up: wenige, aber größere Server Scale out: viele, kleinere (Commodity-)Server Quelle: ibm.com Quelle: storagesystems1.com 5

6 Scale up Vorteil: transparent für DBMS Administrationsaufwand konstant Nachteil: 6

7 Scale out Vorteil: Nachteil: Verteilung von Last/Daten notwendig Maßnahmen zur Lastverteilung notwendig ggf. verteilte Protokolle (2PC, Replikation) 7

8 Benchmarking für Skalierbarkeit Ziele Bewertung/Vergleich des Systemverhaltens bei Zunahme von Last/Datenmenge Einfluss der Hinzunahme von Ressourcen (Server,...) Bewertungsmaße: Performanz, Preis/Performanz,... Benchmarks TPC-* Yahoo! Cloud Serving Benchmark Tractor Pulling... 8

9 TPC TPC-H: Decision Support, Data Warehousing einfaches, normalisiertes Schema mit wenigen Tabellen komplexe Ad-hoc-Anfragen Metriken: TPC-C: Order Entry Application (Bestellungen, Lieferungen, Warenbestand,...) einfaches Schema Updates, 5 Transaktionstypen (ACID) Metriken: tpmc, $/tpmc TPC-DS: potentieller TPC-H-Nachfolger komplexeres, realitätsnäheres Schema CH-BenCHmark (DBTest 2011): hybrider Lösung aus TPC-C und TPC-H Skalierung über DB-Größe Scale-Faktor bei TPC-H (LINEITEM) und TPC-C (WAREHOUSE) bei TPC-C auch über Nutzer/Requests 9

10 Yahoo! Cloud Serving Benchmark Yahoo! Research (SoCC 2010) eine Tabelle mit Records; verschiedene Datenverteilungen einfache Operationen: Lesen, Einfügen, Löschen von Records, Range Scans Metriken: Performanz: Latenz bei wachsendem Durchsatz Scaling: Scaleup konstante Performanz bei wachsender Datenmenge und Serveranzahl? Elastic Speedup: Performanzverbesserung beim Hinzufügen von Servern im laufenden Betrieb 10

11 Yahoo! Cloud Serving Benchmark Quelle: B. Cooper 11

12 Tractor Pulling (DBTest 2011) Ergebnis eines Dagstuhl-Seminars zu Robust Query Processing 2010 Ziel: Messen von Robustheit von DBMS 12

13 Tractor Pulling kontrollierte Zunahme von Last und/oder Datenvolumen Schrittweises Vorgehen; Schritt aus Änderungen am Katalog Daten laden, Indexe erzeugen Anfragen ausführen (konstante Anfragen, Anfragen mit zunehmender Komplexität, konkurrierend) Prinzip Uniform Zipf 13

14 0 Tractor Pulling: Tracks und Metriken Szenarien: Hills: langsam wachsende DB, komplexere Anfragen, konstante Nutzerzahl Meadows: konstante DB-Größe, zunehmende Anfragekomplexität Rockies: wachsende DB + Anfragekomplexität + Nutzer... Metriken (für Robustheit) Standardabweichung für Ladezeit, Speicherbedarf, Anfrageoptimierungs- und -ausführungszeit,... Step Zeit in s Meadows -CLIQUE 14

15 Techniken für skalierbares Datenmanagement Arbeit verteilen klassische Parallelisierungstechniken (Inter-Query- bzw. Intra-Query- Parallelität) Sharding Arbeit reduzieren IO als dominierenden Faktor reduzieren (Caching, Main Memory DBMS) Spezialisierung (Column Stores, OLTP- DBMS) Arbeit outsourcen Amazon RDS (5 GB..1 TB), SQL Azure (100 GB) 15

16 Partitionierung und Verteilung Voraussetzung: Problem (Last, Daten) ist partitionierbar Horizontale Partitionierung der Daten: pro Server = Partition transparent durch globales Verteilungsschema Sharding: explizit in der Applikation Kunden Brandenburg Kunden Thüringen Kunden Sachsen Kunden Bayern Vorteil: Aufteilung der Last Nachteile: Realisierung partitionsübergreifenden Operationen (Vereinigung, Join) Schemamanagement über viele Knoten ggf. Redistribution der Daten und Anpassung der Applikation notwendig 16

17 Partitionierung und Verteilung Denormalisierung Unterstützung von Sharding + Concurrency durch Normalisierung Probleme: Redundanz,... Consistent Hashing Schlüssel (Daten + Serveradressen) als Punkte auf einem Ring abbilden (über Hashfunktion) Server ist für Schlüsselbereich zuständig Vermeidet aufwendiges Remapping aller Schlüssel bei Hinzunahme/Entfernen von Serverknoten K49 K57 K40 K33 N42 N58 N32 K23 K31 K59 K5 N8 N21 K10 K15 17

18 IO-Aufwand reduzieren Disk-Zugriffe eliminieren Vorberechnung (Materialized Views) Caching: Memcached Cache-Server: Zwischenspeichern von serialisierten Objekten (Werte, Dokumente, Anfrageergebnisse) unter einem Schlüssel Beschleunigt nur Leseoperationen Main-Memory-DBMS: Vollständige Verwaltung der Datenbank im Hauptspeicher Beispiele: TimesTen, ParAccel, HANA, Membase, MonetDB,... Hauptspeichergrenze weiterhin vorhanden Spaltenorientierte Datenorganisation: Reduzierung der zu lesenden Daten auf den für die Anfrage notwendigen Teil Vektorisierte Verarbeitung statt Iterator-Prinzip MonetDB, Sybase IQ, VectorWise, Vertica,... Ergebnis: siehe aktuelletpc-h-rangliste 18

19 Grenzen: Hardware als limitierender Faktor Hauptspeicher: Adressierbarkeit, Kosten,... IO: Bandbreite von SATA (3/6 GBit), Fibre Channel,... CPU-Takt: 19

20 Grenzen: CAP-Theorem [Brewer 2000] Consistency: alle Clients (Anwendungen) haben die gleiche Sicht auf den Datenbestand auch im Fall von Updates Availability: es ist immer eine Kopie der Daten verfügbar, auch im Fehlerfall Partition Tolerance: Systemeigenschaften bleiben auch bei Partitionierung des Netzwerks erhalten Für verteilte Shared-Data-Systeme sind zu jeder Zeit nur maximal zwei dieser drei Eigenschaften erreichbar. 20

21 CAP-Theorem Im Partitionierungsfall: warten bis Daten wieder konsistent sind Sperrverfahren Consistency Keine Konsistenzgarantien Updates erfordern Konfliktbehandlung Availability Partition Tolerance Jeder Knoten ist mit jedem verbunden oder alle bilden eine atomare Einheit 2PC 21

22 Außerdem... Optimierung und Ausführung von Anfragen formuliert in SQL: SQL/XML über 1000 Knoten hinweg?? Umgang mit Ausfällen 1 Server 1 Ausfall alle 3 Jahre (1000 Tage) Server 10 Ausfälle pro Tag! Konsequenz: Einschränkung der Funktionalität AP, CA, (CP)-Systeme Transaktionssemantik (begrenzte Atomarität) Anfrageoperationen (Schlüsselzugriffe, keine Verbunde) 22

23 NoSQL eine Alternative? Klasse von Datenbanksystemen, die einen nicht-relationalen Ansatz verfolgen 23 im Datenmodell: Graphen, Dokumente,... in der Anfragesprache: kein SQL, keine Anfragesprache,... in Architektur und Features: massiv verteilt, eingeschränkte ACID- Eigenschaften (Konsistenz, Isolation) kein SQL, keine Transaktionen, kein Schema und keine Integritätsbedingungen

24 Markt & Beispiele Key-Value-Stores: Speicherung von Schlüssel-Wert-Paaren, Lookup-Operationen Beispiele: S3, Riak,... Dokumentenzentrierte Systeme: kein oder flexibles Schema (JSON-Dokumente) Beispiele: CouchDB, mongodb,... Graphenorientierte Systeme: Verwaltung von Graphstrukturen (z.b. für soziale Netze) Beispiele: Sones,... Row und Column Stores: klassische tupelstrukturierte Daten, SQL-ähnliche Anfragen Beispiele: BigTable, SimpleDB,... 24

25 Cassandra entwickelt von Facebook und 2008 als Open Source veröffentlicht seit 2010 Top-Level-Projekt bei Apache Kombination von Amazon Dynamo (massiv verteilt) und BigTable (ColumnFamily) Basis: DHT mit Consistent Hashing Replikate im Ring verteilt asynchrone und synchrone Replikation 25

26 Cassandra: Datenmodell Column = Tripel aus (Name, Wert, Zeitstempel) ColumnFamily (CF) = Tabelle aus Rows mit eindeutigem Schlüssel Immer sortiert nach Schlüssel (Index) Zusätzliche Sekundärindexe möglich Keyspace: Bestellsystem CF: CUSTOMER Key Column: Name Column: Address 42 Felix Potsdam 43 Alfons München CF: ORDERS... 26

27 Cassandra: Anfragen Thrift-API (RPC-Zugriffe) CQL einfachste Anfragen Selektion über indexierte Spalten Keine Joins Operationsspezifische Beeinflussung der Konsistenz ZERO (keine Garantien), ANY, ONE (Schreiben auf mind. 1 Knoten), QUORUM (Mindestanzahl von Knoten beim Schreiben), ALL (alle Knoten) Konflikterkennung über Zeitstempel Commit-Logs, nicht nur Replikation 27

28 VoltDB In-Memory OLTP-System basierend auf H-Store Beobachtungen Disk-IO als Bottleneck viele Anwendungen benutzen nur eine kleine (und bekannte) Anzahl verschiedener Transaktionen Datenplatzierung (Replikation, Partitionierung) mit großem Einfluss auf Performanz, jedoch abhängig von Schema und Workload Stripped-down-Systeme (Single threaded, Recovery durch Zustandskopieren,...) versprechen bessere Performanz Features Shared-Nothing-Cluster mit Main-memory-Datenbank automatische Partitionierung von Relationen ACID-Transaktionen Performanzziel: Durchsatz; nicht Latenz 28

29 VoltDB: Prinzip StoredProc(KUNDE) StoredProc(KUNDE) Tabelle KUNDE Tabelle BEST StoredProc(BEST) StoredProc(KUNDE Tabelle 1 1 ) Tabelle KUNDE 2 StoredProc(KUNDE Tabelle 3 3 ) StoredProc(BEST Tabelle 1 1 ) Tabelle BEST 2 Tabelle BEST 3 Knoten #1 Knoten #2 Knoten #3 29

30 VoltDB: Transaktionen Transaktion = Instanz einer Stored Procedure (Java + SQL-Anfrage) abgeleitet von einer vordefinierten Java-Klasse Annotation für Optimierungsmöglichkeiten Single Partition: kann auf einer einzelnen Partition (=ein Knoten) ausgeführt werden erlaubt Transfer der Ausführungskontrolle zu dem entsprechenden Knoten Partitionsinfo (Partitionierungsspalte, Parameter der Stored Procedure) 30

31 Amazon SimpleDB NoSQL-Cloud-Service von Amazon Alternative zu S3 (Storage) und RDS (MySQL-Instanzen) Hochverfügbar und hochskalierbar (AP-System) Pay-per-Use-Preismodell (Datentransfer, Anzahl Requests) Bsp. 1 Mill. Items a 25 Attribute (500 GB Speicher); 500 GB In/Out, Requests => $185/Monat Tools: AWS Toolkit for Eclipse Scratchpad (Javascript/HTML) SDK für Java, PHP,.NET,... 31

32 Amazon SimpleDB Datenmodell Tupelmodell: Domain = Kollektion von Items beschrieben über Key-Value-Paare; max. Größe10 GB Attribute können pro Item hinzugefügt werden (max. 256) API Storage Account Customer Order Customer #1 Customer #2 Domain Item Name: Wolfgang City: Dresden Attribute: Value Domain: CreateDomain, ListDomain,... Item: PutAttributes, DeleteAttributes bzw. GetAttributes 32

33 Amazon SimpleDB Anfragen Beschränkt auf einzelne Domain SFW-Syntax + count() + Multiattribut-Prädikate Stringwertige Daten: Vergleich nur lexikographisch Einschränkungen Standardfall: Eventually Consistent Reads Lesen garantiert nicht Ergebnisse des letzten Schreibens (erst nach Wiederholung, max. 1 Sekunde) Consistent Read für einzelne Leseanforderungen Atomares Schreiben nur pro Item Synchronisation von Hand über bedingte Put/Delete- Operationen möglich 33

34 Fazit & Take Home Message frischer Wind im Datenbankmarkt mit > 122 Einträgen NoSQL-Systeme zielen (nicht nur) auf Skalierbarkeit ab verschiedene (Optimierungs-)Ziele Durchsatz Datenvolumen flexible Schemata sind schon im produktiven Einsatz in kommerziellen Cloud-Angebote (Amazon SimpleDB, Google AppEngine,...) in Web2.0-Unternehmen (Facebook, Foursquare,...) auch von Oracle ;-) aber nicht immer dauerhaft (siehe Facebook: Cassandra HBase) 34

35 Fazit & Take Home Message TINSTAAFL There's no such thing as a free lunch Skalierbarkeit hat einen Preis: Kosten oder Funktionalität fehlende Funktionalität im DBMS (Anfragesprache, Verbunde, Transaktionsunterstützung,...) wird in Anwendung eventuell nicht vermisst oder muss in der Anwendung nachimplementiert werden daher: Bsp.: Joins in GQL für GAE, OCC in SimpleDB,... Skalierbarkeit welche Dimension? Anwendungsanforderungen Benchmarking We don't have Hadoop because we have large data; we have large data because we have Hadoop. Doug Buzzwords