SimpleVOC - Yet another     Memcached? Bausteine für eine Key/Value-          Datenbank
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.             ...
Ich finde folgendes abgeleitetes Bewertungsschemaziemlich hilfreich:                     In System X sind:                ...
Da gibt es dann einige interessante Kandidaten(Beispiel total subjektiv):       In Hibernate sind:      mittelschwere Din...
Die Geburt einer noSQL Datenbank 19:42: "Hmm, ich habe hier diese vielen Key/Value Paare. Die  muss ich häufig speichern ...
Die Geburt einer noSQL Datenbank         Ein Entwickler hat ein einfaches Problem.         Die Lösung mit einer relation...
Die Lösung ...          Verteile die Datenbank auf mehrere Rechner                 SimpleVOC, FrOSCon 2010
für verschiedene Probleme  Verfügbarkeit     wenn ein Server abstürzt soll die DB verfügbar bleiben  Zuverlässigkeit   ...
Die beste Lösung ...             Die Datenbank              zusammen mit einer API             liefern für einen Cliente...
ist unmöglich: Eric Brewers CAP Theorem   Von den drei Eigenschaften   Consistency (ständige Konsistens der Daten für al...
Das ist für noSQL Datenbanken eine Chance     Denn die perfekte Lösung ist zwar nicht möglich,     aber es gibt viele th...
Datenbankreplikation / Log-Shipping / ...                Read                Write                               Sync     ...
Datenbankreplikation / Log-Shipping / ...                Read                        Read                Write            ...
Datenbankreplikation / Log-Shipping / ...                Read                        Read                Write            ...
Doppeltes Schreiben und Lesen(passt besonders gut zu kooperierenden Apps)                      API                      Li...
Vielfaches Schreiben und Lesen bietet eine Art Tuningzwischen AP und CP (siehe W. Vogels, Dynamo)                      API...
Consistent Hashing kann gut mit Veränderungen desServerpools umgehen                      API                      Library...
Fazit         Es gibt viele Möglichkeiten eine          noSQL Datenbank auf mehrere          Rechner zu verteilen, die in...
Anwendungsbeispiel• Research Dokumente aus vier Abteilungen• Voting aller Benutzer   Dokument CP                   Master ...
Datenspeicher• memcached: LRU Cache, weit verbreitet• Amazon Dynamo: CAP Theorem  – Cassandra  – Voldemort  – Riak• Berkel...
Warum SimpleVOC?• einfach• HTTP Interface• Zuverlässigkeit  – Snapshots  – Transaktionslogs  – CAP Theorem
Komponenten• I / O Library   – libev• JSON.org• HTTP Interface   – Apache   – Lighttpd• Key / Value Store   – STL   – Memo...
Vielen Dank und eine FrageMan/frau sieht sich auf              www.simplevoc.orgWelche Plattform?• sourceforge.net• berlio...
Vielen Dank                   triAGENS GmbH                    Brüsseler Strasse 89-93                    50672 Köln     ...
Nächste SlideShare
Wird geladen in …5
×

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

1.196 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

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

  1. 1. SimpleVOC - Yet another Memcached? Bausteine für eine Key/Value- Datenbank
  2. 2. SimpleVOC – Yet another memcached?Bausteine für eine Key/Value Datenbank. Theorie (Martin Schönert) Praxis (Frank Celler) SimpleVOC, FrOSCon 2010
  3. 3. Eine Weisheit zum Anfang Simple things should be simple, complex things should be possible. Alan Kay, 2001 SimpleVOC, FrOSCon 2010
  4. 4. Ich finde folgendes abgeleitetes Bewertungsschemaziemlich hilfreich: In System X sind:  einfache Dinge:  mittelschwere Dinge:  schwierige Dinge: SimpleVOC, FrOSCon 2010
  5. 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. 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. 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. 8. Die Lösung ...  Verteile die Datenbank auf mehrere Rechner SimpleVOC, FrOSCon 2010
  9. 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. 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. 11. ist unmöglich: Eric Brewers 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. 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
  13. 13. Datenbankreplikation / Log-Shipping / ... Read Write Sync Async SimpleVOC, FrOSCon 2010
  14. 14. Datenbankreplikation / Log-Shipping / ... Read Read Write Sync Async SimpleVOC, FrOSCon 2010
  15. 15. Datenbankreplikation / Log-Shipping / ... Read Read Write Write Sync SimpleVOC, FrOSCon 2010
  16. 16. Doppeltes Schreiben und Lesen(passt besonders gut zu kooperierenden Apps) API Library eventually consistent SimpleVOC, FrOSCon 2010
  17. 17. Vielfaches Schreiben und Lesen bietet eine Art Tuningzwischen AP und CP (siehe W. Vogels, Dynamo) API LibraryN Server R ReadsR+W>N W Writes SimpleVOC, FrOSCon 2010
  18. 18. Consistent Hashing kann gut mit Veränderungen desServerpools umgehen API Library berechne Hash verteile entsprechend SimpleVOC, FrOSCon 2010
  19. 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. 20. Anwendungsbeispiel• Research Dokumente aus vier Abteilungen• Voting aller Benutzer Dokument CP Master / Slave Master / Slave Master / Slave Master / Slave Voting AP
  21. 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. 22. Warum SimpleVOC?• einfach• HTTP Interface• Zuverlässigkeit – Snapshots – Transaktionslogs – CAP Theorem
  23. 23. Komponenten• I / O Library – libev• JSON.org• HTTP Interface – Apache – Lighttpd• Key / Value Store – STL – Memory Blocks
  24. 24. Vielen Dank und eine FrageMan/frau sieht sich auf www.simplevoc.orgWelche Plattform?• sourceforge.net• berlios.de• Savannah.gnu.org• …
  25. 25. Vielen Dank  triAGENS GmbH Brüsseler Strasse 89-93 50672 Köln SimpleVOC, FrOSCon 2010

×