SimpleVOC-Yetanother. Bausteine für eine Key/Value- Datenbank

Transkript

1 SimpleVOC-Yetanother 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)

3 Eine Weisheit zum Anfang Simple things should be simple, complex things should be possible. Alan Kay, 2001

4 Ich finde folgendes abgeleitetes Bewertungsschema ziemlich hilfreich: In System X sind: einfache Dinge: mittelschwere Dinge: schwierige Dinge:

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

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

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.

8 Die Lösung... Verteile die Datenbank auf mehrere Rechner

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.

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.

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,

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)

13 Datenbankreplikation / Log-Shipping /... Read Write Sync Async

14 Datenbankreplikation / Log-Shipping /... Read Write Read Sync Async

15 Datenbankreplikation / Log-Shipping /... Read Write Read Write Sync

16 Doppeltes Schreiben und Lesen (passt besonders gut zu kooperierenden Apps) API Library eventually consistent

17 Vielfaches Schreiben und Lesen bietet eine Art Tuning zwischen AP und CP (siehe W. Vogels, Dynamo) N Server R + W > N API Library R Reads W Writes

18 Consistent Hashing kann gut mit Veränderungen des Serverpools umgehen API Library berechne Hash verteile entsprechend

19 Fazit Es gibt viele Möglichkeiten eine nosql Datenbank auf mehrere Rechner zu verteilen, die in verschiedenen Situationen jeweil optimal sind.

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

22 Warum SimpleVOC? einfach HTTP Interface Zuverlässigkeit Snapshots Transaktionslogs CAP Theorem

23 I / O Library libev JSON.org HTTP Interface Apache Lighttpd Key / Value Store STL Memory Blocks Komponenten

24 Vielen Dank und eine Frage Man/frau sieht sich auf Welche Plattform? sourceforge.net berlios.de Savannah.gnu.org

25 Vielen Dank triagens GmbH Brüsseler Strasse Köln