Zur Zeit existieren viele, verschiedene Key/Value-Datenbanken. Neben dem Urvater “memcached” gibt es kompatible Produkte, wie beispielsweise Redis, oder Neuentwicklungen ala Dynamo oder Riak. Warum sollte man also eine weitere Key/Value-Datenbank bauen? Der Vortrag beschreibt, aus welchen Bausteine eine solche Datenbank besteht, warum HTTP/JSON zur Zeit die Protokolle der Wahl sind, und warum man Dank des Satzes von Brewer (aka CAP Theorem) manchmal nicht alles haben kann.
Der Vortrag erklärt zum einen das CAP Theorem, untersucht wie dies in memcached umgesetzt ist und welche Verbesserungen möglich sind. Zum anderen wird SimpleVOC OPEN beschrieben, eine OpenSource C++-Anwendungen mit den Protokollen des Web (HTTP, JSON). Der SimpleVOC OPEN stellt eine Key/Value-Datenbank zur Verfügung, welche als memcached Ersatz dienen kann. Im Gegensatz zu umfangreicheren Lösungen, wie beispielsweise Redis, versucht der SimpleVOC OPEN sich auf das Wesentliche zu konzentrieren, nämlich der Speicherung von Key/Value-Paaren im Hauptspeicher. Es werden die verschiedenen Komponenten beschrieben, welche benötigt werden, um einen Web 2.0 Server bereitzustellen. Dabei handelt es sich um einen I/O-Scheduler, einen einfachen HTTP-Server, einen JSON-Parser sowie eine InMemory-Datenbank.
SimpleVOC OPEN – Yet another Memcached? (Froscon 2010 talk, german)
1. SimpleVOC - Yet another
Memcached?
Bausteine für eine Key/Value-
Datenbank
2. SimpleVOC – Yet another memcached?
Bausteine für eine Key/Value Datenbank.
Theorie (Martin Schönert)
Praxis (Frank Celler)
SimpleVOC, FrOSCon 2010
3. Eine Weisheit zum Anfang
Simple things should be simple,
complex things should be possible.
Alan Kay, 2001
SimpleVOC, FrOSCon 2010
4. Ich finde folgendes abgeleitetes Bewertungsschema
ziemlich hilfreich:
In System X sind:
einfache Dinge:
mittelschwere Dinge:
schwierige Dinge:
SimpleVOC, FrOSCon 2010
5. Da gibt es dann einige interessante Kandidaten
(Beispiel total subjektiv):
In Hibernate sind:
mittelschwere Dinge: einfach gemacht
einfache Dinge: vergleichsweise mittelschwer
schwierige Dinge: praktisch unmöglich
SimpleVOC, FrOSCon 2010
6. Die Geburt einer noSQL Datenbank
19:42: "Hmm, ich habe hier diese vielen Key/Value Paare. Die
muss ich häufig speichern und ändern und sehr häufig abzufragen."
19:44: "Ok, ich schreibe die einfach in diese Oracle Tabelle mit
einer VARCHAR2 Spalte Key und einer VARCHAR2 Spalte Value."
21:31: "Schade, dass ist nicht performant genug, und 4000
Buchstaben als Limit für Value wird auch nicht immer reichen."
21:32: "Jetzt müsste ich vermutlich die Spaltentypen ändern und
dann einen Index anlegen."
21:33: "Ich glaube es ist schneller ich baue mir eine In-Memory
Datenbank, dazu muss ich ja nur wenig programmieren,
einen Hash-Table, einen Event-gesteuerten TCP/IP Server,
einen HTML Parser, etc. Wie schwer kann das schon sein?"
SimpleVOC, FrOSCon 2010
7. Die Geburt einer noSQL Datenbank
Ein Entwickler hat ein einfaches Problem.
Die Lösung mit einer relationalen Datenbank
wird als zu schwierig empfunden.
Der Entwickler schafft eine einfache Lösung
für das einfache Problem.
Seine Lösung ist erfolgreich und wird folglich
für immer neuer Probleme eingesetzt.
Und jetzt muss sie auch schwierige Dinge
möglich machen.
SimpleVOC, FrOSCon 2010
8. Die Lösung ...
Verteile die Datenbank auf mehrere Rechner
SimpleVOC, FrOSCon 2010
9. für verschiedene Probleme
Verfügbarkeit
wenn ein Server abstürzt soll die DB verfügbar bleiben
Zuverlässigkeit
wenn ein Server abstürzt sollen keine Daten verloren gehen
Performance (genauer Durchsatz)
die Anzahl der Requests ist zu gross für einen Server
Volumen
die Datenmenge ist zu gross für einen Server
die ersten drei führen in manchen Fällen nicht nur zu einer
Verteilung über Server, sondern zu einer Verteilung über
Standorte.
SimpleVOC, FrOSCon 2010
10. Die beste Lösung ...
Die Datenbank
zusammen mit einer API
liefern für einen Clienten die
Abstraktion einer Datenbank die
immer verfügbar ist
und immer die richtigen Daten liefert.
SimpleVOC, FrOSCon 2010
11. ist unmöglich: Eric Brewer's CAP Theorem
Von den drei Eigenschaften
Consistency (ständige Konsistens der Daten für alle Clienten)
Availibility (ständige Verfügbarkeit der DB für alle Clienten)
Partitionability (tolerant in einer Split-Brain Situation)
sind alle Paare (CA, CP, AP) zu realisieren;
jedoch nie alle drei Eigenschaften zusammen.
bewiesen von Gilbert & Lynch, 2002
SimpleVOC, FrOSCon 2010 0
12. Das ist für noSQL Datenbanken eine Chance
Denn die perfekte Lösung ist zwar nicht möglich,
aber es gibt viele theoretisch mögliche Lösungen
die der perfekten auf verschiedene Arten nahekommen
von denen einige die Kooperation der Applikation
einsetzen (welche immer mehr Wissen darüber hat
wie die Daten aussehen können)
und in der relationalen Welt werden nur wenige
mögliche Lösungen angeboten (und dabei keine
die Kooperation benötigen)
SimpleVOC, FrOSCon 2010
16. Doppeltes Schreiben und Lesen
(passt besonders gut zu kooperierenden Apps)
API
Library
eventually
consistent
SimpleVOC, FrOSCon 2010
17. Vielfaches Schreiben und Lesen bietet eine Art Tuning
zwischen AP und CP (siehe W. Vogels, Dynamo)
API
Library
N Server R Reads
R+W>N W Writes
SimpleVOC, FrOSCon 2010
18. Consistent Hashing kann gut mit Veränderungen des
Serverpools umgehen
API
Library
berechne Hash
verteile entsprechend
SimpleVOC, FrOSCon 2010
19. Fazit
Es gibt viele Möglichkeiten eine
noSQL Datenbank auf mehrere
Rechner zu verteilen, die in
verschiedenen Situationen jeweil
optimal sind.
SimpleVOC, FrOSCon 2010
20. Anwendungsbeispiel
• Research Dokumente aus vier Abteilungen
• Voting aller Benutzer
Dokument CP
Master / Slave Master / Slave
Master / Slave Master / Slave Voting AP
21. Datenspeicher
• memcached: LRU Cache, weit verbreitet
• Amazon Dynamo: CAP Theorem
– Cassandra
– Voldemort
– Riak
• Berkeley DB: In-Process Datenbank
• Tokyo Cabinet & Tyrant: In-Process & Server
• Redis: Key/Value Datenbank
