Kommentare zu: …und das Leben nach SQL geht weiter … jetzt wird reduziert!

Von: Wer braucht Variablen? Die funktionale Welt… | PHP hates me - Der PHP Blog

Wed, 10 Mar 2010 06:02:04 +0000

[...] …und das Leben nach SQL geht weiter … jetzt wird reduziert! [...]

Von: Wolfgang Gassler

Wolfgang Gassler — Thu, 29 Oct 2009 22:11:47 +0000

Ich glaube Andre hat das ganz gut getroffen. Ich habe auch gerade zufällig vor zwei Tagen einen Artikel von Michael Stonebraker im ACM Communications gelesen. Er sieht auf lange Sicht auch keine Zukunft für die großen monolitischen DBMS, da sie zwar alles können, jedoch mit auf den Anwendungsfall angepasste DBs nicht mithalten können. Er erklärt, dass es bei den meisten Anwendungsfällen eine 50x schnellere/bessere Lösung gibt. Sei es eine XMl DB, Verteilte DB (mit z.B. MapReduce), Column orientierte DB, Analyse-optimierte DB usw…

Hier der Link (leider kostenpflichtig bzw. über viele Uninetze kostenlos)
http://portal.acm.org/citation.cfm?id=1562164.1562169&coll=portal&dl=ACM&idx=J79&part=magazine&WantType=Magazines&title=Communications%20of%20the%20ACM&CFID=58533910&CFTOKEN=89719981

Von: Andre Moelle

Andre Moelle — Tue, 27 Oct 2009 07:35:10 +0000

Was bringt ein Standard, wenn alle Implementierungen ihre Eigenheiten haben? Bei CouchDB ist CouchDB die Referenzimplementierung.
Außerdem würde ich nicht sagen, dass CouchDB weniger mächtig als SQL ist, sie sind nur für verschiedene Zwecke konzipiert. Davon abgesehen schreibt man die CouchDB-Views in einer turingvollständigen Sprache – wie kann das also weniger mächtig sein als SQL? Zwar ist CouchDB langsamer als ein SQL-Server, aber dafür lässt sich CouchDB besser skalieren.

Ich glaube, dass man erstmal erkunden muss, wofür CouchDB und wofür relationale Datenbanksysteme geeignet sind. Bei den meisten Webapplikationen tippe ich zwar auf CouchDB, aber da relationale Datenbanken in diesem Umfeld de facto Standard sind, hat man für fast jedes Szenario bereits annehmbare Wege gefunden, das relationale Modell zu verwenden. Bei CouchDB fehlen diese Erfahrungen natürlich.
In dem Sinne: Seht ihr einen Nagel, nutzt den Hammer. Seht ihr eine Schraube, nutzt den Schraubenzieher.

Von: KingCrunch

KingCrunch — Tue, 27 Oct 2009 00:23:54 +0000

Ich hab mich mal schlau gemacht. Grundsätzlich ist das Konzept interessant, aber wieso genau sollte man zu einem System wechseln, dass a) weniger mächtig, b) zwischen Faktor 3 bis 5 langsamer, als herkömmliche Methoden (CouchDB), und c) nicht mal ansatzweise irgendwie standardisiert (Schnittstelle) ist?

Von: Wolfgang Gassler

Wolfgang Gassler — Thu, 22 Oct 2009 17:20:10 +0000

@Bastian: wie im artikel erwähnt, ist das ganze ja kein fix fertiges produkt, sondern ein konzept, das es in verschiedenen ausführungen gibt. einen schnellen zugriff per key (hash) bieten alle key/value datenbanken an. will man jedoch komplexe aufgaben erledigen, kann man z.b. mapreduce verwenden. wikipedia hat ein ausführlicheres beispiel mit den ganzen zwischenschritten http://de.wikipedia.org/wiki/MapReduce

Von: Bastian

Bastian — Thu, 22 Oct 2009 16:15:52 +0000

@Wolfgang: genau das mit dem Codefragment hab ich halt nicht so recht verstanden. Mit SQL verbinde ich primär JOINS und komplexe Selektionen mit vielen Bedingungen.

Mit MapReduce verbinde ich (nach deinen Ausführungen und ein klein bisschen Recherche im Netz) primär die sehr schnelle Abfrage von komplexen Daten aufgrund eines Keys.

Vielleicht könntest map/reduce funktionen für einen nicht “count(*)” Anwendungsfall zeigen?

Werden die Ergebnisse des MapReduce-Laufes dann irgendwie gespeichert?

Du siehst, ich finde das Thema sehr interessant

Von: Wolfgang Gassler

Wolfgang Gassler — Thu, 22 Oct 2009 15:13:06 +0000

@Bastian: ein count(*) könnte man über den index noch abbilden, aber wenn man eine where clause mit ‘%phphatesme%’ hat, geht das eigentlich nicht mehr. eventuell über einen fulltext index, aber wenn man nach ‘%php%’ sucht geht auch das nicht mehr. es ist aber allgemein schwer das ganze mit klassischen relationalen dbms zu vergleichen, da es sich hierbei doch um verschiedene welten handelt. der vergleich mit sql war eher dazu gedacht, das code fragment schneller zu verstehen…