NoSQL Summer Protokoll 20100716 und naechstes Treffen
Markus Knittig
Das zweite Treffen des NoSQL Summers ist seit ein paar Tagen vor�ber.
Zeit das Protokoll zu posten und auf's n�chste Treffen hinzuweisen.
Das n�chstes Treffen ist auf Grund der Tatsache das in den n�chsten
Wochen einige weg sind erst in knapp 3 Wochen am Freitag, den 8. August
um 19:30 Uhr im Shack. Diskutiert werden daf�r diesmal aber gleich zwei
Papers. Einmal "Google�s MapReduce":
http://nosqlsummer.org/paper/google-mapreduce
Sowie "Eventually Consistent":
http://nosqlsummer.org/paper/eventually-consistent
Protokoll von hadez (Wieder vielen Dank daf�r!):
20100716 nosqlsummer
anwesend:
pi
markus
pfleidi
felix
hadez
marc
pi: basierend auf dem paper das prinzip implementieren waere jetzt nicht
gegangen
marc: doch, das prinzip besteht ja nur aus dem hashing und der
ringstruktur (wird auch bei anderen systemen so umgesetzt)
felix: gibt uebersicht ueber N-dimensionale nachbarschaftsbeziehungen
speziell des CAN (content addressable network)
pi: was passiert wenn neuer node ins netz kommt?
felix: bestehender knoten teilt seinen zustaendigkeitsbereich auf und
uebergibt haelfte an neuen knoten (involviert datentransfer)
pi: ist datentransfer vermeidbar?
felix: prinzipiell nicht
problemfall node ausfall und replizierung
marc: cassandra ist sehr performant beim schreiben
pfleidi: 'eventually consistent': schreiben in in-memory-structure,
persistierenn erst spaeter, potentieller datenverlust bei node ausfall.
dazu noch ein append-only transaction log (sehr schnell)
marc: append in couchdb extrem langsam da alles in einer datei gehalten;
cassandra hat ~2GB chunk dateien
marc: cassandra schreibt nur wenn load niedrig, couchdb muss man das
anschubsen, und dann laeuft es 10h...
bei seiner db geht's mittlerweile nicht mehr da compacting ewig laeuft,
danach schaut was neu dazu kam, und dass dann wieder compacted, ad infinitum
hintergrund datengroesse und rechnerzahl:
pfleidi:
http://highscalability.com/blog/2010/7/11/so-why-is-twitter-really-not-using-cassandra-to-store-tweets.html
marc: was gut gemacht ist is das upscaling auf mehr hardware
pi: aber man muss es noch manuell anstossen
marc: ja, allerdings zur runtime. bei monogodb faehrt man dafue das
komplette cluster runter und muss die config anfassen
FRAGE: wie nimmt man nodes gezielt und geplant offline unter der annahme
dass sie _nicht_ wiederkommen
felix: downscaling ist moeglicherweise bei facebook kein use-case
kurze diskussion ueber HDFS/HBLOCK / hadoop auf cassandra
FRAGE: marc: wie macht man ein zentrales backup von so einem 100 node
netz (zur runtime)
marc: elastic search kann dass wohl ueber gateway node
pi: problem hat man auch bei file systems,wie bekommt man ein
konsistentes backup?
pfleidi: ohne snapshot support nicht moeglich
marc: fuer einzelnodes ueber filesystem snapshot
pfleidi: wie macht man zentrale konsistentes backup von einem verteilten FS?
marc: uebereinstimmung mehrere nodes: 'gib mir datei X wenn mind. 3
nodes sagen dass der eintrag gueltig ist'
abhaengigkeiten zwischen dateien (links) sind nicht vorgesehen.
alle daten die zum dokument gehoeren mussen _im_ dokument gehalten
werden (objektorientierter ansatz).
das dokument ist immer in sich konsistent
pfleidi: mongodb unterstuetzt referenzen, diese verweisen allerdings
immer nur auf _id felder, aber nicht auf unterfelder.
marc: es bestehen keine abhaengigkeiten zwischen feldern verschiedener
datensaetze, nur verweise auf komplette saetze
FRAGE: wie geht cassandra tatsaechlich mit partitionierung um?
marc: in cassandra ist alles getimestamped
hadez: inbox (mails) hat keine edits, nur deletes / inserts, damit ist
synchronisation relativ einfach moeglich
korrektur marc: insert sind row mutations, erlauben also teilweises
updaten des datensatzes
was haben wir gelernt?
marc: es skaliert linear?
hadez: die abgelegten daten sind trivialst
marc: voldemort und riak sind aehnlich wie cassandra in bezug auf
scalability, cassandra hat noch das datenschema dazu.
es bietet etwas mehr struktur als einfache key-value stores
marc: nomenklatur bei cassandra ist aetzend
es herrscht grobe verwirrung darueber was columns, supercolumns,
families, groups wirklich sind
marc zeichnet diagramm
es scheint einfach ein weiteres level der indirektion zu bieten.
felix: bemaengelt die unwissenschaftlichkeit des papers, markus stimmt
mit ein.
marc: findet das auch, findet's aber garnicht so schlecht.
naechste papers:
http://nosqlsummer.org/paper/eventually-consistent
http://nosqlsummer.org/paper/google-mapreduce
naechster termin:
20100806 freitag 19:30
MfG Markus