NoSQL-Datenbanken. Kapitel 2: Key-Value Stores. Lars Kolb Sommersemester Universität Leipzig 2-1

Transkript

1 NoSQL-Datenbanken Kapitel 2: Key-Value Stores Lars Kolb Sommersemester 2014 Universität Leipzig 2-1

2 Inhaltsverzeichnis Key-Value Stores File/Object Storage Services Beispiele: Microsoft Azure Storage Amazon S3 / Dynamo 2-2

3 Object Storage Services Dienst zum Speichern von Objekten (Binärdaten) in der Cloud Upload + Speicherung auf mehreren Knoten Einfache Strukturierung Buckets: einfache (flache) Container Objekte: beliebige Daten (z.b. Datei), beliebige Größe Authentifizierung, Zugriffsrechte Einfache API HTTP-Requests (REST-ful API): PUT, GET, DELETE Einfache Nutzung durch Anwendungen, z.b. DropBox (Online Backup & Sync Tool) Performanz Schnell, skalierbar, hochverfügbar Kosten Pay as you go : #Request, Datenmenge, Upload- und Download-Menge Beispiele: Microsoft Azure Storage, Amazon S3, Google Cloud Storage 2-3

4 Probleme Mehrere Nutzer können auf die gleichen Daten zugreifen Youtube-Videos, kollaborative Arbeit an Dokumenten,... Problem 1: Konkurrierende Schreibzugriffe Conditional Updates: IF AktuelleVersion=X THEN Update Knoten-basierte Versionierung Kopien von Daten werden auf verschiedenen Knoten gespeichert Zuverlässigkeit Redundanz zum Schutz gegen Knoten-Ausfall Lese-Geschwindigkeit mehre Clients können verschiedene Kopien parallel lesen Ausnutzung von Lokalität Problem 2: Synchronisation der Replikate Strong Consistency: Nach Write lesen alle Clients sofort die aktuellen Daten Eventual Consistency: Nach Write lesen alle Clients letztendlich die aktuellen Daten Read-your-writes Consistency: EC + schreibender Client liest sofort aktuelle Daten 2-4

5 Azure Storage: Architektur 2-5

6 Azure Storage: Request Lifecycle Beispiel: PUT <account>.blob.core.windows.net DNS-Auflösung Ermittle IP-Adresse eines Front-End-Server der Geo-Location des Accounts Front-End-Server Authentifizierung, Autorisierung Partition Map: Object-Name Partition Server Partition Server GET: Falls Daten nicht im Memory-Cache Request an einen DFS-Server PUT: Request an primary DFS-Server DFS Server: Replikation Primary DFS Server + Replikation bei 2 Secondary Servern Strong Consistency 2-6

7 Azure Storage: Ausfall-Behandlung Front-End-Server Entfernen von DNS-Liste Partition Server Partitionen werden von anderem Server verwaltet Anpassung der Partition Map des zu Hilfe eilenden Front End Server Keine Verschiebung der Daten (nur Metadaten-Anpassung) DFS Server Nutzung eines neuen DFS Servers Erstellung eines neuen Replikats 2-7

8 Zeit Azure Storage: Conditional Updates Update-Request enthält Versionsnummer (ETag) der aus Client-Sicht aktuellen Version Erfolg, wenn Client-Versionsnummer = Knoten-Versionsnummer; sonst Fehler bei Neuerstellung Version=0 Verhindert unbeabsichtigtes Überschreiben Konsistenzwahrung wird auf Anwendung übertragen Beispiel GET V7 UPD V7 OK V8 GET V7 UPD V7 ERROR 2-8

9 Azure Storage: Content Delivery Network Erweiterung um ein CDN sinnvoll für Daten mit hohen Lesezugriffen (in einem bestimmten Zeitraum) Daten mit geografisch stark verteilten Zugriffen Einführung von Edge locations Server nahe vom Client/Nutzer performanter Zugriff fungieren als Proxy-Server für Zugriffe auf Azure Storage Request Lifecycle Client fragt CDN-URL für Objekt an DNS routet an nächstgelegene Edge Location Wenn Datei im Cache Response andernfalls Request an Azure Storage; Speicherung im Cachel; Response Time-to-Live für Cache-Objekt Aufgabe der Strong-Consistency Updates werden wegen Cache verzögert repliziert 2-9

10 Amazon Dynamo: Übersicht Amazon S3 basiert auf Amazon Dynamo Verteilter, skalierbarer Key-Value-Speicher v.a. für kleine Datensätze (z.b. 1 MB/Key), z.b. Warenkörbe (Software/API-gestützte Aufteilung größerer Daten) Eigenschaften hochverfügbar geringe Latenz Eventually consistent data store Schreibzugriffe sollen immer möglich sein reduzierte Konsistenzzusicherungen zugunsten Verfügbarkeit Performance SLA (Service Level Agreement) response within 300ms for 99.9% of requests for peak client load of 500 requests per second P2P-artige Verteilung keine Master-Knoten alle Knoten haben selbe Funktionalität 2-10 Quelle: [Dynamo]

11 Amazon Dynamo: Partitionierung Knoten bilden logischen Ring Position entspricht zufälligem Punkt im Wertebereich einer Hashfunktion Zuordnung zwischen Daten und Knoten Bestimme Hash-Wert des Keys Speicherung auf den im Uhrzeigersinn N Folgeknoten Bsp: Hash-Wert zwischen A und B bei N=3: Knoten B, C und D Einfügen, Löschen, Verschieben von Knoten performant, da nur Nachbarknoten betroffen Präferenzliste Liste der N Knoten, die zur Datenspeicherung für einen Key zuständig wird von jedem Knoten geführt Consistent-Hashing Geeignete Hash-Funktion für Daten-Lokalität und Lastverteilung F G E A D Hash(key) B C 2-11

12 Amazon Dynamo: Datenzugriff Key-Value-Store-Interface Primary-Key-Zugriff; keine komplexen Queries Anfrage kann an beliebigen Knoten des Ringes gesendet werden Weiterleitung an einen (meist ersten) Knoten der Präferenzliste dieses Keys Put (Key, Context, Object) Koordinator erstellt Vector Clock (Versionierung) auf Basis des Contexts Lokales Schreiben des Objektes inkl. Vektor Clock Replikation Get (Key) Write-Request an N-1 andere Knoten der Präferenzliste Erfolg, wenn (mindestens) W-1 Knoten antworten asynchrone Aktualisierung der Replikate W<N Konsistenzprobleme Read-Request an N Knoten der Präferenzliste Rückgabe von Responses von R Knoten Kann mehrere Versionen eines Objektes zurückliefern: Liste von (Object, Context)-Paaren 2-12

13 Amazon Dynamo: Replikation Verwendung von Read/Write-Quoren R/W = minimale Anzahl der N Replikat-Knoten, die für erfolgreiche Read/Write Operation übereinstimmen müssen Anwendung kann (N,R,W) an Bedürfnisse an bzgl. Performanz, Verfügbarkeit und Dauerhaftigkeit einstellen Aktuelle Version wird immer gelesen wenn R + W > N Basis-Konsistenz = kein Informationsverlust Ggf. nutzergesteuerte Konfliktbehandlung für abweichende Versionen nötig Varianten Optimierung der Lesezugriffe: R=1, W=N Optimierung der Schreibzugriffe: R=N, W=1 üblich ist (3,2,2) 2-13

14 Amazon Dynamo: Versionierung Verwenden von Vector Clocks um Abhängigkeiten zwischen verschiedenen Versionen eines Objektes darzustellen Versionsnummer/zähler pro Replikat-Knoten z.b. D ([S x, 1]) für Objekt D, Speicherknoten S x, Version 1 Vector Clock : Liste von (node,counter)-paaren zur Anzeige welche Objektversionen bekannt sind Beispiel zur Entwicklung von Objektversionen Sx Sy Sz 2-14

15 Amazon Dynamo: Versionierung (2) mit Vector Clocks feststellbar, ob zwei Objektversionen aufeinander aufbauen oder nicht Counter der 1. Vector Clock alle Counter der 2. Vector Clock 1.Version ist Vorfahr, kann gelöscht werden sonst Konflikt Leseoperation liefert im Konfliktfall alle bekannten Versionen inkl. Vector Clocks darauf folgendes Update führt verschiedene Versionen wieder zusammen Anwendung kann Konfliktlösung bestimmen z.b. Mischen verschiedener Warenkorbversionen 2-15

16 Amazon Dynamo: Temporäre Fehler Knoten können temporär nicht verfügbar sein Sloppy Quorum (N, R, W) Alle Operationen auf den ersten N verfügbaren ( healthy ) Knoten ausgeführt Damit auch bei Ausfall eines Replikat-Knoten writable (z.b. W=N) Hinted Handoff Wenn ein Knoten bei Replikation nicht verfügbar ist, wird Anfrage an anderen Knoten weitergereicht ( hinted replica ) Background-Job: Wenn Original-Knoten wieder verfügbar, wird Hinted Replica mit Original-Knoten synchronisiert 2-16

17 Amazon Dynamo: Synchronisation v. Replikaten Hash-Tree (Merkle Tree) für Key-Range Blätter sind Hash-Werte der Key-Werte Eltern-Knoten sind Hash-Werte der Kind-Knoten-Werte H(...) Vorteile Effiziente Überprüfung ob zwei Replikate synchron sind: Wurzel- Knoten haben gleichen Wert Effiziente Identifikation nichtsynchroner Teile: Rekursive Analyse der Teilbäume Nachteile Neuberechnung bei Re-Partitionierung (z.b. neue Knoten) H(H(H(k 1 ), H(k 2 )), H(H(k 3 ), H(k 4 ))) H(H(k 1 ), H(k 2 )) H(H(k 3 ), H(k 4 )) H(k 1 ) H(k 2 ) H(k 3 ) H(k 4 ) K1 V1 K2 V2 K3 V3 K4 V

18 Amazon Dynamo: Techniken (Übersicht) Problem Technologie Vorteil Partitionierung Consistent Hashing Hochverfügbarkeit von Schreibzugriffen Temporärer Ausfall von Knoten Recovering Vector Clocks mit Konfliktbehandlung bei Lesezugriffen Sloppy Quorum und Hinted Handoff Hash Tree (Merkle Tree) Weitere Techniken u.a. Gossip-artiges Protokoll für P2P-Organisation (neue Knoten, Ausfallerkennung,...) 2-18

19 Vergleich Azure Storage vs. Amazon S3/Dynamo Azure Storage (CP) Amazon Dynamo (AP) Partitionierung Objekt-Name Hash-Funktion Dynam. erweiterbar + + Routing hierarchisch P2P Replikation Synchron Asynchron Konsistenz Strong Consistency Eventual Consistency Behandlung konkurrierender Writes Performanz (Fokus) 2-19

20 Literatur [Azure]: Calder et al.: Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency, SOSP 11 [Dynamo] DeCandia et al.: Dynamo: Amazon s Highly Available Keyvalue Store, SOSP