NoSQL Summer Protokoll 20100804 und naechstes Treffen
Markus Knittig
Das dritte Treffen des NoSQL Summers fand am Mittwoch, den 4. August
statt. Da hadez nicht da war, hab ich diesmal das Protokol �bernommen.
Das n�chste Treffen findet am Mittwoch, den 18. August um 19:30 Uhr im
Shackspace statt. Diesmal wird das CAP Theorem diskutiert:
http://nosqlsummer.org/paper/cap-theorem
Protokoll:
anwesend:
markus
pfleidi
felix
marc
felix: Bester Satz im MapReduce Paper: "The programs were executed on a
weekend afternoon, when the CPUs, disks, and network were mostly idle."
pfleidi: Auch gut: "Commodity hardware" Dual-Core und 2-4GB RAM in 2004?
WTF?
marc: So viele Daten, wie machen wie das eigentlich mit dem Senden �bers
Netzwerk? Frisst das nicht die CPU-Performance wieder auf?
felix: Die haben die Daten schon aus den Rechner vorverteilt
pfleidi: Hadoop macht das ja genauso.
felix: Das macht ja sowieso nur f�r komplexe Daten sind
pfleidi: Punkte f�r MapReduce 1. Distributed Computing vereinfacht ->
Keine Locking, Verteilung -> Leute ohne Ahnung k�nnen das programmieren
marc: Moment, da m�ssen aber auch die Libraries mitspielen.
pfleidi: Ein weiterer Punkt: Man geht davon aus das Maschinen ausfallen
-> Wird von MapReduce behandelt.
felix: Ja, da gibt es aber genug andere Systeme die das k�nnen (Redis, etc.)
pfeidi: Gab es die �berhaupt schon 2004?
marc: Und wie macht implementieriert man das mit einem Rechner?
felix: Man kann auch lokal testen/debuggen
pfeidi: Lohnt sich nur bei gro�er Datenmenge
marc: Machen andere Systeme doch schon nativ (MongoDB, etc.), macht also
nur bei wirklich gro�en Systemen Sinn
pfleidi: Ja, man braucht auch extreme Menge von Server daf�r. Au�erdem
muss man so ein System auch im voraus planen
marc: Macht das Hardware-m�ssig �berhaupt Sinn?
pfleidi: Naja, im Vergleich zu Alternativen wie Mainframe ist das mit
normaler Hardware immernoch billiger
pfleidi: Was ich auch interessant finde das die Daten �ber Pings
transportieren
felix: Warum nicht? Ist ja eine gute Sache, sollte man immer wenn
m�glich machen
pfleidi: Beispiele sind einfach gew�hlt. Die machen sicherlich auch noch
viel komplizierter Sachen damit wie z.B. Sprachverarbeitung
felix: Als Datensystem verwenden sie ja GFS (Google file system)
pfeidi: Das ist sicher besser als HFS (Hadoop file system)
pfleidi: Distriuted Sort ist auch interessant. Das machen die ja �ber
Distributed Rename. Wie war das den nochmal?
marc: Das ist eigentlich Context insensitiv also man kann nur Dinge
machen die von allem anderen unabh�ngig sind
*Alle Suche nach der Stelle im Paper*
felix: Irgendwo stand's jedenfalls.
pfleidi: Partioner Funktion meinte ich (Seite 6 unten links).
pfleidi: Also: Daten werden in Memory gebuffert, dann wird sequentiell
rausgeschrieben, dann wird an Master zur�ckgemeldet und Reduce Server
holt sich per RPC vom Map Server ab
marc: Warum macht man den Reduce nicht auf der gleichen Maschine?
pfleidi: K�nnte man schon machen, ist so aber wohl schneller
felix: Ist das nicht deswegen so, um die Ausfallsicherheit sicherzustellen?
pfleidi: Nein, weil wenn Reduce Ausf�llt wird Map sowieso nochmal gemacht
marc: Warum machen die das den? Das macht keinen Sinn
*Suche nach Stelle im Paper*
marc: Ist glaube ich einfach missverst�ndlich geschrieben. Die meinen
den Fall wo der Map Server abraucht
pfeidi: Also im Prinzip geht's darum das man eben durch das CAP Dreieck
(network partitioning, availablity, consistency) nur zwei von drei
Sachen einhalten kann. Im Falle von "Eventually Consistent" ist
Konsistenz nicht sichergestellt
marc: Das Dreieck gibt's auch bei Frauen (h�bsch, intelligent und
psychisch stabil)
marc: Insgesamt sagt das Paper aber nicht viel aus. Es ist Monotonic
reads gab es noch
pfleidi: Monotonic read sagt das die Wert in richtiger Reihenfolge
gelesen werden
felix: War aber gut zu lesen. Und bunt...
pfleidi: Mehr bunt!
pfleidi: Was gab's noch? Read-on-Write, damit ist sichergestellt das der
Benutzer die Daten sofort sieht
felix: Das Paper will vorallem "awareness raisen"
pfleidi: Das ist eine wichtige Sachen. Ich hab ja meine Idee eine
Datenbak auf XMPP-Basis umzusetzen noch nicht in Angriff genommen
Best regards,
Markus