Key-Value Stores - Abteilung Datenbanken Leipzig

Transcription

NoSQL-Datenbanken
Kapitel 2: Key-Value Stores
Dr. Anika Groß
Wintersemester 2015/16
Universität Leipzig
http://dbs.uni-leipzig.de
2-1
Inhaltsverzeichnis
• Key-Value Stores
–
–
–
–
Einführung
Amazon Dynamo
Redis
Object Storage Service: Microsoft Azure Storage
2-2
Quelle: http://db-engines.com/en/ranking/
DB Ranking
• Key-Value-Stores
• alle
2-3
Key-Value-Store
• Einfache, sehr flexible Form eines Datenbankmanagementsystems
• Datenstruktur: assoziative Arrays
– dictionary, map, hash, hash map, hash table …
– Kollektion von (ggf. komplexen) Objekten
• Einfache API
– put(key, value)
– get(key)
– remove(key)
• Häufiger Einsatz in verteilter Umgebung
• Beispiele: Amazon DynamoDB, Redis, Memcached,Riak …
2-4
Anwendungen
• z.B. Session-Daten, E-Commerce Warenkörbe
Eigenschaften:
• Große, unstrukturierte Datensätze
– hohe Performanz für große Objektanzahl erforderlich
• Einfaches Datenmodell und einfache Anfragen
– Zugriff + Speicherung via Schlüssel
– Keine Fremdschlüssel, seltene Joins
• Hohe Lese-/Schreibraten
– Einfache Indizierung nach Primärschlüssel
2-5
Keys und Values
• Key: eindeutig innerhalb einer DB bzw. eines Namespace ( =collection of
keys, auch ‘bucket‘)
Sales
Inventory
Product
descriptions
key 1
value
key 1
value
key 1
value
key 2
value
key 2
value
key 2
value
key 3
value
key 3
value
key 3
value
…
…
…
…
…
…
key n
value
key n
value
key n
value
• Values
– Untersch. Länge & Datentypen (String, Integer, BLOB..)
– Keine DB-seitigen Integritätsbedingungen
(applikationsseitig z.B. Wertebereich prüfen)
Quelle: Dan Sullivan: “NoSQL for Mere Mortals“, Pearson Education (Us), 2015
2-6
Key Naming Convention
• Bezug zu relationaler Modellierung
– z.B. Konkatenation Tabellenname, Primärschlüssel, Spaltenname
Kunden
cust 123.address
ID (PK)
name
address
123
…
…
…
[1]
• Composite keys
– Nutzung z.B. für Indexierung
und Aggregationen
Beispiel
Index
[1] Dan Sullivan: “NoSQL for Mere Mortals“, Pearson Education (Us), 2015
[2] Ilya Katsov: NoSQL Data Modeling Techniques. Highly Scalable Blog, 2012
https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniqes/
2-7
[2]
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-8
Quelle: [Dynamo]
Konsistentes Hashing
• Abbildung von Werten aus einer üblicherweise sehr großen Quellmenge
auf Hashwert v=h(x) aus einer deutlich kleineren Wertemenge
– Geht in konstanter Zeit
• Einfache Hashfunktion
– Modulo-Funktion: h(x,n):= x mod n
• Ziel:
– Zuordnung zu Speicherort
– Dabei: Anzahl der Neuzuordnungen minimieren (wenn Knoten hinzukommen oder
entfernt werden)
Quelle: Stefan Edlich, Achim Friedland, Jens Hampe,Benjamin Brauer: “NoSQL:
Einstieg in die Welt nichtrelationaler Web 2.0
2-9Datenbanken”, Carl Hanser Verlag, 2010
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
A
G
B
C
F
E
D
– 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
2-10
Hash(key)
Beispiel N=3
Hashwert
Knoten
Replika
5
19
A:[0,10)
G:[60,69]
B:[10,20)
A
38
B
G
F:[50,60)
20
50
B’
B‘:[20,25)
F
C
E
E:[40,50)
C:[20,30)
C:[25,30)
D
69
Einfügen von B‘
Hashwert
5
19
D:[30,40)
20
38
B‘ ist Replikatknoten von A und B
Replikatlöschungen bei C und D
50
69
2-11
Knoten
Replika
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
• Write-Request an N-1 andere Knoten der Präferenzliste
• Erfolg, wenn (mindestens) W-1 Knoten antworten
• asynchrone Aktualisierung der Replikate W<N  Konsistenzprobleme
• Get (Key)
– 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
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 bzgl. Performanz, Verfügbarkeit und
Dauerhaftigkeit anpassen
• Aktuelle Version wird immer gelesen wenn R + W > N
–
–
–
–
Strong consistency
Kein Informationsverlust
üblich z.B. (3,2,2)
Ggf. nutzergesteuerte Konfliktbehandlung für abweichende Versionen nötig
2-13
Quorum-Varianten
R
• Optimierung der Lesezugriffe: R=1, W=N
– Konsistenz durch „write to all“ = warten bis alle writes bestätigt (ack)
W
R=1, W=N=3
• Optimierung der Schreibzugriffe: R=N, W=1
– Konsistenz durch „read from all“ = letzte Version ist garantiert dabei
R=N=3, W=1
• Weitere R+W>N
Eventual consistency: R+W≤N
• read kann aktuellen write verpassen
R=3, W=3, N=5
R=2, W=2, N=4
R=4, W=2, N=5
2-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 ([Sx, 1]) für Objekt D, Speicherknoten Sx, Version 1
– Vector Clock : Liste von (node,counter)-Paaren zur Anzeige welche
Objektversionen bekannt sind
• Beispiel zur Entwicklung von Objektversionen
Sx
Sy
Sz
2-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
• Konfliktlösung
– „last-write-wins“
• Problem lost updates: T1: x = x + 5, T2: x = x + 2
– Oder durch Anwendung
• z.B. Mischen verschiedener Warenkorbversionen
2-16
Beispiel Vector Clocks
• Quellen: Vorlesung Prof. Sebastian Michel „Distributed Data
Management“, SoSe 2015, TU Kaiserslautern
+ http://basho.com/why-vector-clocks-are-easy/
2-17
Quellen: Vorlesung „Distributed Data Management“, SoSe 2015, S. Michel
2-18
2-19
2-20
2-21
2-22
2-23
2-24
2-25
Amazon Dynamo: Ausfallsicherheit
• Temporärer Ausfall von Knoten
• Sloppy Quorum (N, R, W) → Folie 14
– Alle Operationen auf den ersten N verfügbaren (“healthy”) Knoten ausführen
– 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
– Szenario
• B ist nicht verfügbar
• Kopie an E weitergeben (handoff) mit
Vermerk (hinted), dass eig. zu B gehört
• B wieder verfügbar
– Hinted Kopie E → B
– Erfolgreich release E (löscht hinted Kopie)
2-26
Amazon Dynamo: Synchronisation v. Replikaten
• Hash-Tree (Merkle Tree) für Key-Range
– Blätter sind Hash-Werte der values von keys
– Eltern-Knoten sind Hash-Werte der Kind-Knoten-Werte
• Vorteile
– Effiziente Überprüfung ob zwei
Replikate synchron sind: WurzelKnoten haben gleichen Wert
– Effiziente Identifikation nichtsynchroner Teile: Rekursive
Analyse der Teilbäume
• Nachteile
– Neuberechnung bei
Re-Partitionierung
(z.B. neue Knoten)
H(...)
H(H(H(k1), H(k2)), H(H(k3), H(k4)))
...
H(H(k1), H(k2)) H(H(k3), H(k4))
H(k1)
H(k2)
H(k3)
H(k4)
K1
V1
K2
V2
K3
V3
K4
V4
2-27
...
...
Amazon Dynamo: Techniken (Übersicht)
Problem
Technologie
Vorteil
Partitionierung
Consistent Hashing
Hochverfügbarkeit
Vector Clocks mit
von Schreibzugriffen Konfliktbehandlung
bei Lesezugriffen
Temporärer Ausfall
Sloppy Quorum und
von Knoten
Hinted Handoff
Recovering
Hash Tree
(Merkle Tree)
• Weitere Techniken u.a.
– Gossip-artiges Protokoll für P2P-Organisation (neue Knoten, Ausfallerkennung, ...)
• (hinted handoff nur für temporären Ausfall)
2-28
Dynamo Services / Implementierungen
• Amazon Dynamo DB
– http://aws.amazon.com/de/dynamodb/
– Vollständig verwalteter NoSQLDatenbankservice von AWS
• Key Value und Document Store
– Basiert auf Dynamo (weist aber Unterschiede auf)
• Synchrone Replikation über mehrere Datacenter
• Replikation über 3 Standorte einer AWS Region für Fehlertoleranz
– Schneller Zugriff, geringe Latenzen: ausschließlich SSDs
• Voldemort
– http://www.project-voldemort.com/voldemort/
– Open-Source Implementierung von Amazons Dynamo Key-Value Store
2-29
Redis
•
•
•
•
REmote DIctionary Server
Aktuelle stabile Version: Redis 3.0.5
In C implementierte In-Memory-Datenbank
Key-Value
– Neben Speicherung von Strings auch komplexere Datentypen
wie Listen, Mengen, Hashes
•
•
•
Persistenz: Snapshotting oder Journal
Replikation: Master / Slave
Performanz
–
–
–
–
•
•
Sehr schnell (in-memory), ohne Persistenz
Keine Sperren
Nicht per se distributed! einzelne Redis Instanz: single process, single-threaded
Redis Cluster für data sharding
Oft als Cache (statt als DB) genutzt
Users: GitHub, Flickr, Twitter, Stack Overflow, …
Quelle: [Redis]
2-30
Redis Datenmodell
• Key
– Printable ASCII
• Value
– Strings set mykey myvalue
– Container: Hashes, Lists, Sets, Sorted Sets
user:1
Value: Hash
field
Value: Set
value
user
Alice
mail
al@ice...
user:1:tweets
user:1:followers
Value: List
23 8 19 5 34
7 14 40
hmset myhash f1 v1 f2 v2
sadd myset v1 v2 v3
user:mostfollowed
0
1
Value: Sorted Set
2
3
Hi Alice How Are Today,
…
… you… …
rpush mylist v1 v2 v3
score
@bob
4233689
@eve
@dave
4438430
4908207
@carol
5197422
zadd mysortset score v1
http://blog.redsmin.com/post/85995135615/slides-introduction-to-redis
2-31
field
Persistenz
• In-Memory: Gefahr des Datenverlusts, z.B. bei Serverabsturz
1. RDB persistence
+ i/o Performanz,
schneller Restart
– Persistenz
•
•
•
•
= Snapshotting / “periodic dump” (.rdb files)
Automatisiertes regelmäßiges Abspeichern der gesamten DB auf Disk
Asynchrone Übertragung der Daten aus dem Hauptspeicher auf Disk  semi-persistent
Wann? save points nach X Sekunden oder Y Änderungen
•
Auch für “Disaster Recovery”: z.b. RDB backup auf Amazon S3
2. AOF persistence
•
•
= Protokolldatei/Log-Datei/Journal (“Append Only”)
ACID konforme Konfiguration möglich
–
•
•
3 Settings: no fsync, fsync every second (default), fsync always
+ Persistenz (in
Balance mit
Performance)
– i/o Performanz bei
fsync always,
langsamerer Restart
Bei jedem write wird Änderung an Journal angehängt
 (fast) vollständige Persistenz: Rekonstruktion nach Systemcrash möglich
“Rewrite” des Journals möglich, um “unendliches Wachstum” des Journals zu verhindern
• oder Kombination RDB + AOF (bei Restart wird AOF genutzt, RDBs für backup)
• oder ohne Persistenz (disable RDB+AOF)
2-32
Redis Replikation
• Ziel: Ausfallsicherheit durch Redundanz
– keine Datenverteilung / partitioning (erst mit Redis Cluster!)
• Asynchrone Master-Slave Replikation
– Slaves: exakte Kopien von Master Server
– Slave senden periodisch ‘acknowledgement’, welche Daten verarbeitet wurden
• Gute Skalierbarkeit für reads (nicht für writes)
• Ein Master kann mehrere Slaves haben
• Slave kann Master oder anderer Slave sein
• Daten von jedem Redis Server können auf beliebige Anzahl Slaves
repliziert werden
• Slaves können sich untereinander verbinden (graph-like structure)
2-33
Single-rooted Replication Tree
•
Topologie:
Slave-1
Sl-1a
Sl-1b
Replikationsrichtung
RedisMaster
Sl-1c
Slave-2
Sl-2a
Slave-3
Sl-2b
Sl-2c
Sl-3a
Sl-3b
Sl-3c
Master:
Slave
– Kein Quorum, nur Master akzeptiert writes
– Asynchrone Propagierung von writes (downstream!)
– Read-only Slaves (default)
– Verantwortlich für Schreiben der Replika auf Festplatte
(für Datenredundanz)
– Bei Sync
• Alle Knoten sind Master ihrer eigenen Slaves
• Warum Tree? einzelner Master kann nicht „schnell
genug“ auf alle Slaves schreiben
• Anfragen werden mit alter Version beantwortet
(alternative config: Slave gibt error an Client zurück)
• Kurze Sperre, wenn alter Datensatz gelöscht & neuer
geladen wird
– Keine Sperren auf Master bei Sync der Slaves
• Kann immer Anfragen beantworten
• Seit Redis 2.8 mögliches Setting:
writes nur erlauben, wenn Master mind. N Slaves hat,
die innerhalb maxTime antworten
2-34
Redis Replikation (2)
•
Verringerte Schreiblast Master: Slave kann das Schreiben auf Festplatte übernehmen
– Auto Restart am Master vermeiden, falls “persistence off”, sonst Restart des Masters mit
leerer DB + Replikation der leeren DB an Slaves → überschreibt backup)
•
Hinzufügen eines Slave
–
–
–
–
•
Sendet SYNC command
Master startet background saving und puffert alle neuen Schreiboperationen/Änderungen
background saving vollständig: Master sendet Datei an Slave
Slave speichert diese auf Disk + lädt sie in den Hauptspeicher
+ empfängt gepufferte Änderungen
Netzwerkausfall/unterbrechung
– Automatische Neuverbindung der Slaves zum Master
– Bei konkurrierenden Anfragen → ein background saving → an alle Slaves
– Auch partielle statt vollständiger Resynchronisation
• Dafür in-Memory Backlog des Replikation-Stream auf Master (agree über replication offset zw.
Master und allen Slaves)
•
„Diskless“ Replikation: keine Zwischenspeicherung auf Festplatte, Master sendet RDB
direkt an Slaves
2-35
Redis Transaktionen
•
•
•
Gruppierung von mehreren Operationen in einer Transaktion möglich
Reduktion der Anzahl der “Network Roundtrips”, auf die Client warten muss
Dabei wird garantiert:
– Isolation: alle Operationen einer Transaktion werden serialisiert und
sequentiell ausgeführt
– Atomarität: alle oder keine der Operationen einer TA werden ausgeführt
• MULTI: Start einer Transaktion, alle folgenden Operationen in eine Queue
• EXEC: führt alle Operationen der Queue in einer TA aus
– Bei AOF wird sichergestellt, dass Redis TA als ein write verarbeitet
– Bei System Crash: möglich dass nur Teil der Änderungen geschrieben wird
• Mit Redis-Check-AOF Tool → Entfernen der partiellen TA möglich
•
Verhindern von Lost Updates durch Optimistic Locking mit WATCH mykey
– Überwachen von Änderungen bzgl. key
– In Bsp.: anderer Client versucht val zwischen WATCH und EXEC
zu ändern → TA schlägt fehl
– Dann wird TA wiederholt (i.d. Hoffnung, dass es nicht wieder fehlschlägt)
2-36
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
Redis Cluster
• Ermöglicht Data Sharding
– Verteilung des Datensatzes über mehrere Knoten
– Alle Befehle der nicht-verteilten Version von Redis werden unterstützt
• Ziele:
1) Hohe Performanz + Skalierbarkeit bis zu 1000 Knoten
2) Akzeptable Konsistenz („small windows where
acknowledged writes can be lost“ [2])
3) Availability bei Netzwerkpartitionierung
• Cluster verfügbar, solange Mehrheit
der Master erreichbar + weitere Bedingungen
• Jeder Knoten hat 2 offene TCP Verbindungen
– Kommunikation mit Clients: z.B. 6379
– Node-to-Node Kommunikation:
Cluster Bus Port = „high port“ (+10000)  16379
Quellen: [1] http://redis.io/topics/cluster-tutorial, [2] http://redis.io/topics/cluster-spec,
Bild: http://redis.io/presentation/Redis_Cluster.pdf
2-37
Kommunikation zwischen Knoten
• Clients können alle Knoten anfragen und werden ggf. an anderen Knoten
umgeleitet (Clients können aber Map zwischen Keys und Knoten cachen)
• Gossip-Protokoll für Austausch von Informationen zwischen Cluster nodes
– Erkennen neuer Knoten; Sicherstellen, ob Knoten erreichbar
Quelle: http://redis.io/presentation/Redis_Cluster.pdf
2-38
Redis Cluster - Sharding
•
Sharding: jeder key ist Teil eines Hash Slot
– Kein konsistentes Hashing
•
•
Es gibt 16384 Hash Slots in Redis Cluster
Hash Slot Zuordnung eines keys
– Berechnung: CRC16 key modulo 16384
•
•
Jeder Knoten in Cluster ist für Teilmenge der Hash Slots verantwortlich
Bsp. 3 Knoten
–
–
–
–
•
Node A Hash Slots 0 - 5500
Node B Hash Slots 5501 - 11000
Node C Hash Slots 11001 – 16384
Hinzufügen neuer Knoten D: Teil der Hashslots von A, B, C muss verschoben werden
(System kann dabei weiterlaufen)
Mit Hash Tags kann erzwungen werden, dass keys im gleichen Slot landen
– Verwende {} in key → nur innerer Teil wird gehasht
– this{foo}key und another{foo}key landen im gleichen Hash Slot
2-39
Sharding und Redundanz
• Alle Knoten stehen in Verbindung und sind funktionell äquivalent
• Zwei Arten: Masters und Slaves (=exakte Kopien von Master Server)
Bild: http://redis.io/presentation/Redis_Cluster.pdf
2-40
Redis Cluster - Availability
• Verfügbarkeit nur für “majority partition“
– Mehrheit der Master muss erreichbar sein
– und mind. ein Slave pro nicht erreichbarem Master
– Cluster wieder verfügbar nach „node timeout“ + Zeit für Wahl eines Slaves zum
neuen Master (1-2 Sek.)
• Ausfälle einzelner Knoten können gehandelt werden, jedoch keine
größeren Netzwerkausfälle
• Szenario: N Master Knoten mit je 1 Slave
– Verfügbarkeit majority partition, wenn max. 1 Knoten wegfällt (2 ∙ 𝑁 − 1 Knoten)
– Ausfallwahrscheinlichkeit für Master ohne Replika:
1
2∙𝑁−1
1
– Bsp. 5 Master, je 1 Slave:
⇒ 11.11% Wahrscheinlichkeit, dass bei Ausfall
5∗2−1
eines weiteren Knoten Netzwerk nicht mehr verfügbar
•
Replica Migration Feature: Master ohne Replika → Migration von Replika auf diese
„orphaned master“ (bessere Verfügbarkeit in „Realworld Szenarien“)
2-41
Redis Cluster - Consistency
• Asynchrone Replikation, „last failover wins“ (kein merge von Änderungen)
– Letzter Master-Datensatz kann ggf. alle Replikas überschreiben
• Keine Strong Consistency
• Unter bestimmten Bedingungen können writes verloren gehen!!
1.) Aufgrund asynchroner Replikation
– Client schreibt an Master B; Master B antwortet OK (=ack)
– Master B propagiert Änderung an Slaves B1, B2, B3 (wartet nicht auf ack!)
– Problem: Crash von B bevor write bei Slave, der als neuer Master gewählt wird
→ write verloren
2.) Aufgrund Netzwerkpartitionierung
– Ein Client wird in „minor partition“ mit ≥1 Master isoliert
– Bsp: 3 Master A, B, C, 3 Slaves A1, B1, C1 + Client Z1
A
A1
• Falls Partitioning lange andauert, wird B1 zum neuen Master
in “major partition” gewählt → writes von Z1 an B in minor partition verloren
• B muss in „node timeout“, damit Z1 keine writes mehr an B schickt
C
B1
C1
B
Z1
• Synchrone Writes können mit WAIT Befehl erzwungen werden (aber sehr
negativer Einfluss auf Performanz)
2-42
Inhaltsverzeichnis
• Key-Value Stores
–
–
–
–
Einführung
Amazon Dynamo
Redis
Object Storage Service: Microsoft Azure Storage
2-43
Object Storage Services
• Dienste 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-44
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
• Mehrere 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-45
Azure Storage
• Ziele
– Hohe Verfügbarkeit mit strenger Konsistenz
• Datenzugang bei Ausfällen und Netzwerkpartitionierung
– Durability
• Replikation innerhalb und über mehrere Datacenter
• Geographische Replikation für Disaster Recovery
– Skalierbarkeit
• > Exabyte Bereich
• Automatische Lastbalancierung für hohe Zugriffsraten auf Daten (Peaks)
• Globaler, partitionierter Namespace:
http(s)://AccountName.<service>.core.windows.net/PartitionName/ObjectName
• Storage für Container (Blobs), Table (Entities), …
Quelle: [Azure]
2-46
Windows Azure Storage Stamps
Location
Service
Data
access
-
Mehrere Locations in den 3
geographischen Regionen
(Nordamerika, Europa, Asien)
Jede Location umfasst
mehrere Storage Stamps
VIP
VIP
Front-Ends
Front-Ends
Partition Layer
Partition Layer
Stream Layer
Inter-stamp
(Geo) replication
Stream Layer
Intra-stamp replication
Intra-stamp replication
Storage Stamp
Storage Stamp
Synchrone Replikation
Asynchrone
Replikation
Quelle: http://www.sigops.org/sosp/sosp11/current/2011-Cascais/11-calder.pptx
2-47
Architektur
Incoming Write Request
Ack
Front End
Layer
FE
FE
FE
FE
FE
Partition
Master
Lock
Service
Partition
Layer
Partition
Server
Stream
Layer
(Distributed
File System)
M
Partition
Server
Partition
Server
M
Paxos
M
Extent Nodes (EN)
2-48
Partition Layer – Index Range Partitioning
•
•
•
•
•
Split index into
RangePartitions
based on load
Split at PartitionKey
boundaries
PartitionMap
tracks Index
RangePartition
assignment to
partition servers
Front-End caches
the PartitionMap to
route user requests
Each part of the
index is assigned to
only one Partition
Server at a time
Blob Index
Account
Account
Name
Name
Container
Container
Name
Name
Blob
Blob
Name
Name
aaaa
aaaa
aaaa
aaaa
aaaaa
aaaaa
……..
………
……..
………
……..
………
……..
………
……..
………
……..
………
……..
……..
Account
Container
harry
pictures
Name
Name
……..
……..
Front-End
harry
pictures
…….. Server
……..
………
………
……..
……..
A-H:
PS1
………
………
……..
……..
PS2
Account H’-R:
Container
richard
videos
Name R’-Z:
Name
PS3
……..
……..
richard
videos
……..
……..
Partition
………
………
…….. Map……..
……..
Blob
sunrise
Name
……..
sunset
……..
………
……..
………
……..
Blob
soccer
Name
……..
tennis
……..
………
……..
………
……..
………
……..
………
……..
zzzz
zzzz
zzzz
zzzz
zzzzz
zzzzz
Storage Stamp
Partition
Server
A-H
Partition
Map
PS 1
Partition
Server
H’-R
PS 2
2-49
A-H: PS1
Partition
H’-R: PS2
Master
R’-Z: PS3
Partition
Server
R’-Z
PS 3
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-51
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-52
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
Zeit
GET
V7
UPD V7
OK V8
UPD V7
ERROR
2-53
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 am 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 Cache; Response
Time-to-Live für Cache-Objekt
• Keine Strong-Consistency mehr
– Updates werden wegen Cache verzögert repliziert
2-54
Azure Storage - Services
LOKAL
ZONENREDUNDANTER REDUNDANTER
SPEICHER (LRS) SPEICHER (ZRS)
Funktion
Kopien gesamt
Empfohlene
Verwendung
GEOGRAFISCH
REDUNDANTER
SPEICHER MIT LESEZUGRIFF (RA-GRS)
Mehrere synchrone Drei Kopien der Daten
Wie LRS, plus mehrere Wie GRS, plus
Kopien der Daten über mehrere Datencenter asynchrone Kopien in Lesezugriff auf das
innerhalb eines
innerhalb von Regionen einem zweiten,
sekundäre Datencenter
Datencenters
oder regionsübergreifend Hunderte Kilometer
(nur für Blockblobs)
entfernten Datencenter
3
3
6
Wirtschaftliche,
Wirtschaftlich, robustere
lokale Speicherung Option für Blockblobvon Daten
speicher
Verfügbarkeits- 99,9 % Lese-/
SLA
Schreibzugriff
Standardspeicher €0,0203 pro GB
Erstes TB/Monat
GEOGRAFISCH
REDUNDANTER
SPEICHER (GRS)
Zum Schutz bei
größeren
Datencenterausfällen
oder Notfällen
6
99,9 % Lese-/
Schreibzugriff
99,9 % Lese-/
Schreibzugriff
Bietet Lesezugriff auf
Daten während Ausfall
 maximale Datenverfügbarkeit und
Robustheit
99,9 % Schreibzugriff
99,99 % Lesezugriff
€0,0253 pro GB
€0,0405 pro GB
€0,0515 pro GB
https://azure.microsoft.com/de-de/pricing/details/storage/
2-55
Azure Redis Cache + Azure Storage
• Azure Redis Cache: Redis Cache hosted and managed by Microsoft
• Suche auf Primärindex sehr schnell
• Für andere Anfragen  secondary index im Cache
Redis Cache
Azure Table Storage
Alice:001:234
001:234:Alice:1st road …
Bob:002:765
…
Ted:001:923
001:923:Ted:3rd avenue …
…
002:765:Bob:2nd street …
Alice
001:234
001:234
Azure Web Site
2-56
https://azure.microsoft.com/de-de/documentation/videos/azure-redis-cache-102-application-patterns/
Vergleich
Amazon Dynamo
Redis (Cluster)
Azure Storage
Hash-Funktion
Hash-Funktion
Objekt-Name
Dynam. erweiterbar +
+
+
Routing
P2P
Hierarchisch
Hierarchisch
Replikation
Asynchron
Asynchron
Synchron
Konsistenz
Eventual Consistency
Partitionierung
Strong Consistency
Behandlung
konkurrierender
Writes
Performanz
(Fokus)
2-57
Literatur
• [Dynamo]: DeCandia et al.: „Dynamo: Amazon’s Highly Available Keyvalue Store“, SOSP’07
• [Redis]: http://redis.io/documentation
• [Azure]: Calder et al.: “Windows Azure Storage: A Highly Available Cloud
Storage Service with Strong Consistency”, SOSP’11
2-58

Key-Value Stores - Abteilung Datenbanken Leipzig

Transcription

Similar documents

DIE KLASSE OBJECT

Akkreditierungsbericht Hochschule Reutlingen „International

Virtuelles Laufwerk Grundsätzliches Zugriff auf Dateiabbilder Mit

Datum der Veröffentlichung: Montag, 25. Juli 2016

Performance mit high-traffic TYPO3 sites

Proceedings Template - WORD - Institut für Verteilte Systeme

5-bay raid station

Dissertation komplett

Dell™ vRanger™ 7.1.1 Releaseinformationen

Search Engines - Abteilung Datenbanken Leipzig

RAID-Optimierungen

8-bay raid station

Inhalt Bedienungsanleitung