Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
NoSQL Summer Protokoll 20100708 und naechstes Treffen
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  1 message - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Markus Knittig  
View profile   Translate to Translated (View Original)
 More options Jul 11 2010, 6:26 pm
From: Markus Knittig <mar...@myd0.de>
Date: Mon, 12 Jul 2010 00:26:48 +0200
Local: Sun, Jul 11 2010 6:26 pm
Subject: NoSQL Summer Protokoll 20100708 und naechstes Treffen
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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »