Hi!
Erstmal Danke an alle die trotz der Hitze da waren. Hat Spa gemacht.
N chstes Treffen ist am Freitag um 19:30 Uhr im Shack. Diskutiert wird
"Cassandra A Decentralized Structured Storage System":
http://nosqlsummer.org/paper/cassandra
Hier das Protokoll von hadez (Vielen Dank daf r!):
20100708 nosqlsummer
anwesend:
pi
markus
pfleidi
sima
jasp0r
patrick
mck
hadez
uli
norbert
ACTION/pi: stonebraker's implementation rauskramen und antesten (voltdb.org)
es werden vorab einige stimmen laut bzgl der generellen bewertung des papers
- zuwenig technische details und spez beweis der 82fachen
performancesteigerung
- generell klingen die thesen nachvollziehbar und sinnvoll
- impliziert nosql gleichzeitig nodba?
laut paper werden optimierungsmassnahmen zukuenftig automatisch erledigt.
manuelle optimierung durch einen dba sollen nicht mehr noetig sein.
stattdessen wird die benutzung von automatischen mechanismen und
'clicki-bunti' frontend tools zur DB-erzeugung/maintanance propagiert.
- sql ist ueberladen / komplex
pi's these: reimplementation von verschiedenen usecases in ein produkt
und keinen anreiz auf etwas einfacheres zurueckzugehen.
markus sieht die zukunft, wie im paper, in spezialisierten
inselloesungen fuer bestimmte datenbank usecases.
pi: sobald wieder N verschiedene systeme am start sind, wird es wieder
leutue geben die ein unified interface wollen (back to SQL)
pfleidi: sieht den spezialisierungstrend auch bei programmiersprachen;
allerdings auch das problem mit umdenken wenn verschiedene sprachen
nebeneinander benutzt werden.
pi: durch die integration von spezialisierten db systemen verlagert sich
aufwand auf die programmierebene
pi: reale systeme bestehen aus riesigen datenmengen, und sind ueber
lange jahre im einsatz. aufgestellte thesen koennen nicht bestaetigt
oder widerlegt werden wenn man sich kleinprojekte anschaut.
pi: "wir haben keine kultur uns ueber datenbank schema zu unterhalten",
darum nosql
markus: in seiner firma gibt es keinen der queries optimieren kann,
darum autogeneratoren / mapper verwenden / ORMs
pi: kennt jemanden der gerade so ein problem zu loesen versucht.
12-seitige queries die nicht mehr funktionieren und irgendwann mal aus
irgendeinem generator rausgefalen sind.
pfleidi erklaert kurz wie ORM funktioniert. bottom line: automatische
serialisiserung von objekten auf datenbankkompatible strukturen.
zeitersparnis fuer den programmierer.
pfleidi: migration des db modells bei geaendertem objektmodell faellt
idealerweise automatisch aus dem ORM. bei manchen systmeen mehr bei
anderen weniger gut.
pi: ist es garantiert dass generieren und migration vollautomatisch
funktionieren
markus: ueber annotations und/oder xmlconfig kann/muss ORM teilweise
beeinflusst werden.
pfleidi: ists persoenlich wieder von ORM weggekommen, weil zuviel voodoo
magic
markus: protestiert ueber die strikte verbindung nosql mit 'grosser
datenbank'
pi's frage nach erfahrung mit grossen datenbanken unter den anwesenden
wird bis auf randbemerkungen verneint.
pfleidi: erfahrung mit nosql bei kleinen datenbanken:
hat vor einiger zeit beim google chome wettbewerb mitgemacht und ein
plugin gecoded was basierend auf userverhalten versucht rauszufinden
welche tabs automtaisch geschlossen werden koennen.
benutzt wurde der key/value store von sql5
pi: was ist der unterschied zwischen nosql und sql?
pi: fand die einfache erklaerung von TPC-C sehr interessant und auch
dass wenn bei diesem einfachen benchmark probleme auftreten es klar ist,
dass man von sql weg geht.
hadez: nomenklaturproblem? geht es hier um die 'simple query language',
das interface; oder eine spezielle implementation der datenbank selbst?
pi: es geht um datenbanken welche von sich aus kein sql interface haben.
man kann da natuerlich wieder SQL drauf setzen
pfleidi: dann hat man aber nichts gewonnen.
pi: eben doch, das ist gerade das versprechen von stonebraker
markus: wir sollten auch mal was mit hands-on machen
hadez: hat jemand nen grossen datensatz?
pi: kann eine ip accounting DB anbieten.
interessante anwendung: was fuer queries muss man fahren um gewisse art
von portscans zu erkennen?
http://nosqlsummer.org/paper/cassandra
naechstes treffen: freitag 2010-07-16 19:30
MfG Markus