SimpleVOC OPEN – Yet another Memcached? (Froscon 2010 talk, german)

SimpleVOC - Yet another

Memcached?Memcached?

Bausteine für eine Key/Value-

Datenbank

SimpleVOC, FrOSCon 2010

SimpleVOC – Yet another memcached?Bausteine für eine Key/Value Datenbank.

Theorie (Martin Schönert)Praxis (Frank Celler)


Eine Weisheit zum Anfang

Simple things should be simple,complex things should be possible.

Alan Kay, 2001


Ich finde folgendes abgeleitetes Bewertungsschema ziemlich hilfreich:

In System X sind:einfache Dinge:mittelschwere Dinge:schwierige Dinge:


Da gibt es dann einige interessante Kandidaten (Beispiel total subjektiv):

In Hibernate sind:mittelschwere Dinge: einfach gemachteinfache Dinge: vergleichsweise mittelschwerschwierige Dinge: praktisch unmöglich


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?"


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.


Die Lösung ...

Verteile die Datenbank auf mehrere Rechner


für verschiedene Probleme

Verfügbarkeitwenn ein Server abstürzt soll die DB verfügbar bleiben

Zuverlässigkeitwenn ein Server abstürzt sollen keine Daten verloren gehen

Performance (genauer Durchsatz)die Anzahl der Requests ist zu gross für einen Server

Volumendie 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.


Die beste Lösung ...

Die Datenbankzusammen mit einer API

liefern für einen Clienten dieAbstraktion einer Datenbank die

immer verfügbar istund immer die richtigen Daten liefert.

SimpleVOC, FrOSCon 2010 0

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


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ösungendie der perfekten auf verschiedene Arten nahekommen

von denen einige die Kooperation der Applikationeinsetzen (welche immer mehr Wissen darüber hatwie die Daten aussehen können)

und in der relationalen Welt werden nur wenigemögliche Lösungen angeboten (und dabei keinedie Kooperation benötigen)


Datenbankreplikation / Log-Shipping / ...

ReadWrite

SyncAsync



ReadWrite

SyncAsync

Read



ReadWrite

Sync

ReadWrite


Doppeltes Schreiben und Lesen(passt besonders gut zu kooperierenden Apps)

APILibrary

eventuallyconsistent


Vielfaches Schreiben und Lesen bietet eine Art Tuning zwischen AP und CP (siehe W. Vogels, Dynamo)

APILibrary

R ReadsW Writes

N ServerR + W > N


Consistent Hashing kann gut mit Veränderungen des Serverpools umgehen

APILibrary

berechne Hashverteile entsprechend


Fazit

Es gibt viele Möglichkeiten einenoSQL Datenbank auf mehrereRechner zu verteilen, die inverschiedenen Situationen jeweiloptimal sind.

Anwendungsbeispiel

• Research Dokumente aus vier Abteilungen

• Voting aller Benutzer

Master / Slave Master / Slave

Master / Slave Master / Slave

Dokument CP

Voting AP

Datenspeicher

• memcached: LRU Cache, weit verbreitet

• Amazon Dynamo: CAP Theorem

– Cassandra

– Voldemort– Voldemort

– Riak

• Berkeley DB: In-Process Datenbank

• Tokyo Cabinet & Tyrant: In-Process & Server

• Redis: Key/Value Datenbank

Warum SimpleVOC?

• einfach

• HTTP Interface

• Zuverlässigkeit

– Snapshots– Snapshots

– Transaktionslogs

– CAP Theorem

Komponenten

• I / O Library

– libev

• JSON.org

• HTTP Interface• HTTP Interface

– Apache

– Lighttpd

• Key / Value Store

– STL

– Memory Blocks

Vielen Dank und eine Frage

Man/frau sieht sich auf

www.simplevoc.org

Welche Plattform?Welche Plattform?

• sourceforge.net

• berlios.de

• Savannah.gnu.org

• …


Vielen Dank

triAGENS GmbHBrüsseler Strasse 89-9350672 Köln

SimpleVOC OPEN – Yet another Memcached? (Froscon 2010 talk, german)

Technology

Transcript of SimpleVOC OPEN – Yet another Memcached? (Froscon 2010 talk, german)