Von Jochen Schnelle am Mo, 12. Juli 2010 um 21:32 #
Na ja... eher nicht. eXist ist eine XML-Datenbank, welche auf XML-Dokumente optimiert ist. Das ist was ganz anderes als CouchDB, welche von Hause aus gar kein XML kennt, sondern alles als JSON-Objekt sieht.
Wer nur mit XML Dokumenten hantiert fährt mit einer XML-DB (wie eXist oder BaseX) sicherlich besser.
Das ist alles sehr interessant, mir aber etwas zu abstrakt
Wie würde denn eine Abfrage aussehen die mir alle Betriebssystem liefert die mit "L" anfangen?
Und warum muss ich den Wert für den Schlüssel wie im Beispiel "MacOS" direkt in das JavaScript schreiben, ich will ja vielleicht auch mal nach "Linux" oder "Windows" suchen, kann man den Wert nicht als Parameter für die Suche übergeben?
In der Praxis will ich doch z.B. nach Vor- und Nachnamen suchen, wie würd ich dass den machen?
Suchen kannst du dann, indem du alle Dokumente des Views mit den Schlüsseln zwischen ["Mü", ""] und ["N",""] abfragst. Es gibt nicht wie bei SQL Funktionen um zB bei Abfragen bestimmte Infos zu filtern. Du must solche Anforderungen vorher fest in die Views verdrahten, da diese vorgeneriert werden.
Von Jochen Schnelle am Sa, 10. Juli 2010 um 21:12 #
Dann musst du nur "MacOS" gegen "Linux" ersetzen...
Grundsätzlich ist es so, dass CouchDB (genau so wie Key-Value-Stores) erstmal nur nach Schlüsseln suchen kann und dann deren Wert ausgibt.
Eine Abfrage wie "zeig' mir alle Schlüssel in allen Dokumenten, die den Wert 'foo' haben" musst du i.d.R. softwareseitig umsetzen, also nicht als View in der DB.
Tipp: CouchDB installieren und spielen. Es ist nämlich eigentlich ziemlich simpel.
bei so nem großen Artikel fehlt mir ein bei Datenspeichern doch äußerst wichtiges Thema: Performance!
- Wie lange braucht die CouchDB z.B. für den Import von 100.000 "Dokumenten" (das Wort Datensatz ist ihnen wohl zu schnöde?) mit sagen wir mal 20 Feldern, wovon die Hälfte Varchar sind? Ein "herkömmliches" DBMS schafft das auf billiger Hardware so in ca. 5 Sekunden. - Wie lange dauern komplexere Abfragen? - Wie wirkt sich das für nicht gerade optimierte HTTP-Protokoll auf die Übertragung aus? Usw. ...
Von Jochen Schnelle am So, 11. Juli 2010 um 22:50 #
Da musst du wohl mal nach Benchmarkergebnissen suchen...
> Wie lange dauern komplexere Abfragen? Die Frage kann man pauschal natürlich (für keine DB) beantworten - kommt auf die Last auf dem Server an, die Geschwindigkeit der Hardware etc. Jedenfalls ist es so, dass CouchDB das Ergebnis von permanenten Views cached, d.h. es sollte relativ schnell sein.
> Wie wirkt sich das für nicht gerade optimierte HTTP-Protokoll auf die Übertragung aus? Du bekommst ein JSON-Objekt zurück... d.h. die Übertragungszeit richtet sich nach der Größe des JSON-Objekts und nach der Bandbreite deiner Anbindung...
na das sind ja auch nur Allgemeinplätze ohne jeden Aussagewert...
Worum es mir ging, war, dass der Autor des Artikels halt auch ein Auge auf die Performance hätte werfen sollen. In diversen Foreneinträgen liest man halt oft was von wahrhaft _grottenschlechter_ Performance von CouchDB.
und wenn der Autor das Programm schon für einen ellenlangen Artikel testet, dann muss er IMHO halt auch ein paar wie auch immer geartete Performance-Tests machen sollen - gerade bei einer Datenbank wohl einer der _Hauptmerkmale_! ... Oder wenigstens auf ein paar _brauchbare_ Benchmarkergebnisse verlinken sollen.
Von Jochen Schnelle am Mo, 12. Juli 2010 um 16:53 #
Grundsätzlich richtig. Wobei der Artikel auch (bewusst) auf die grundsätzliche Anwendung (und Möglichkeiten) einer dokument-orientierten DB fokussiert als auf Performance.
Da meine CouchDBs vergleichsweise klein sind hatte ich noch nie Performance-Probleme. Wie es sich bei einer DB mit X-zehntausend Dokumenten verhält weiß ich in der Tat nicht.
BTW - habe gerade mal schnell gegoogle. Die Benchmarks, die ich so gesehen habe sind alle eher alt, also CouchDB V 0.9 oder älter. Wer also einen aktuellen Benchmark hat...
Vorab: Sorry, auch ich hab keine richtige Benchmark zahlen...
Ich habe mich letzter Zeit etwas mit CouchDB befasst.
> Wie lange braucht die CouchDB z.B. für den Import von 100.000 > "Dokumenten" (das Wort Datensatz ist ihnen wohl zu schnöde?) mit sagen > wir mal 20 Feldern, wovon die Hälfte Varchar sind? > Ein "herkömmliches" DBMS schafft das auf billiger Hardware so in ca. 5 > Sekunden. Ich hab von 3000 docs/s gehört. Allerdings lässts sich scheinbar ziemlich linear skalieren (da docs unabhängig voneinander sind). Sind dan wohl über 30 Sekunden... Allerdings macht der vergleich auch recht wenig Sinn. Den wenn du mit CouchDB eine Applikation machst, musst du denormalisieren. Das führt dazu das du viel weniger Dokumente anlegst als Zeilen in einem herkömlichen relationalen DBMS. Beispiel Rechnung: "Rechnungsposition" "Rechnungskopfbeziehung", durchschnittlich 10 Positionen. Der Overhead zum Erstellen ist bei CouchDB pro Rechnung, daher ist die Geschwindigkeit zum Anlegen von Dokumenten nicht ganz so entscheidend.
> - Wie lange dauern komplexere Abfragen? Das ist das coole am Map/Reduce. Map wird beim Insert ausgeführt und über das Ergebnis ein Index auf den Output von Map gelegt (B-Tree). Reduce erst bei der Abfrage. Daher ist die halbe Abfrage bei der effektiven Abfrage bereits erledigt (natürlich auf kosten des Inserts, aber dort machst du es halt einmal). Also sollte CouchDB (mit richtiger Anwendung von Map/Reduce) insbesondere bei Abfragen hochperformant sein. Google verwendet diesen Algorythmus in seinen Datencentern...
> - Wie wirkt sich das für nicht gerade optimierte HTTP-Protokoll auf die Übertragung aus? Negativ, wie den sonst? Aber wenn du nach MySQL noch ein PHP hast, das dein Resultset etas bearbeitet und über HTTP zum Client sendest, hast du den HTTP-Overhead auch... Zudem noch ein Prozesswechsel und Daten werden wahrscheinlich einmal mehr kopiert. Bei CouchDB kannst du direkt vom Client mittels AJAX die Datenbank abfragen. CouchDB ist eine Datenbank für Webapplikationen.
Von Jochen Schnelle am Mo, 12. Juli 2010 um 21:28 #
Macht nix mit den Typos
Und thx für deinen Kommentar.
Es ist völlig richtig, dass man bei einem Benchmark Relational (SQL) vs. CouchDB Äpfel mit Birnen vergleicht (siehe auch hier: http://stackoverflow.com/questions/1296741/performance-benchmark-couchdb-x-relational-databases , erster Kommentar)
Natürlich ist die Performance wichtig, aber der Grund, auf CouchDB zu wechseln ist eben nicht, um schneller zu werden, sondern um die Vorteile einer dokumenten-orientieren Datenbank zu nutzen. Wenn sie denn Vorteile für die eigenen Applikation bietet. Das muss jeder selber rausfinden.
Warum sollte es richtig sein "dass man bei einem Benchmark Relational (SQL) vs. CouchDB Äpfel mit Birnen vergleicht"?
Bitte entweder begründen oder sein lassen.
Der Junge, der da bei Stackoverflow diesen Blödsinn ebenfalls ohne Begründung hingerotzt hat und Widerspruch oder Ignoranz dafür geerntet hat, ist sicher keine Referenz.
Ja, danke für den Kommentar, da steht doch wenigstens schon mal ein wenig was drin
>> Ich hab von 3000 docs/s gehört Das ist das dumme: Ich hab was von 25 docs/s (http://jacobian.org/writing/couchdb/) oder 4,5 - 258 docs/s (http://books.couchdb.org/relax/reference/high-performance - mit bulk load "sagenhafte" 4000 d/s) gelesen - und das ist schon ein gewaltiger Unterschied.
Map-Reduce ist natürlich eine schöne Sache - wenn man ein Dutzend Rechner (aufwärts) parallel für eine Anwendung betreiben kann. Dann genau dafür ist es gemacht: Extreme horizontale Skalierung durch Nutzung von vielen Festplatten (mal ganz einfach gesagt). Ob das das richtige für kleine PHP-Webanwendungen ist, wofür du CouchDB ja prädestiniert siehst, bezweifel ich mal .
Und wenn jede (!) Spalte (automatisch?) indiziert wird, wie groß wird dann wohl der Index? Das würde allerdings in der Tat den extremen Insert erklären. Spaltenorientierte Datenbanken gibts übrigens auch für "normales" SQL - z.B. die Calpont-Engine für MySQL.
HTTP: Klar, wenn man mit PHP arbeitet, kommts auf den HTTP-Overhead auch nicht mehr an. Andererseits hätte es ja sein können, dass CouchDB die Inhalte z.B. zippt, was bei JSON-Dokumenten schon mal 90 % Netzlast reduziert?
Wie auch immer, einen schönen Tag noch und harren wir da der Dinge die da kommen!
P.S.: Einen schweren "Rückfall" musste die NoSQL-Bewegung hinnehmen, als Twitter erklären musste, dass sie halt doch eine normale Datenbank für die Tweets nehmen mussten: http://highscalability.com/blog/2010/7/11/so-why-is-twitter-really-not-using-cassandra-to-store-tweets.html
Erinnert mich so ein bisschen an eXist, nur dass eXist diese Funktionen schon seit Jahren hat ...
http://exist.sourceforge.net/
Nur dessen Existenz scheint nicht allen immer und allgegenwärtig bewusst zu sein.
Na ja... eher nicht. eXist ist eine XML-Datenbank, welche auf XML-Dokumente optimiert ist. Das ist was ganz anderes als CouchDB, welche von Hause aus gar kein XML kennt, sondern alles als JSON-Objekt sieht.
Wer nur mit XML Dokumenten hantiert fährt mit einer XML-DB (wie eXist oder BaseX) sicherlich besser.
Gruß, Jochen
function(doc) {
"Es wird zuerst eine Funktion definiert, hier mit dem Namen doc."
Es sieht eher wie eine anonyme Funktion aus, die einen Parameter namens "doc" entgegen nimmt. Oder vertue ich mich (was ich nicht ausschließen will).
So gesehen hast du recht. Die Funktion an sich wird "nur" innerhalb des Views genutzt. Zumindest hier.
Ob man eine Funktionen innerhalb einer Funktione nutzen kann habe ich noch nie probiert...
Die meisten Views sollten sich aber mit einem linearen Programmablauf lösen lassen
Gruß, Jochen
Das ist alles sehr interessant, mir aber etwas zu abstrakt
Wie würde denn eine Abfrage aussehen die mir alle Betriebssystem liefert die mit "L" anfangen?
Und warum muss ich den Wert für den Schlüssel wie im Beispiel "MacOS" direkt in das JavaScript schreiben, ich will ja vielleicht auch mal nach "Linux" oder "Windows" suchen, kann man den Wert nicht als Parameter für die Suche übergeben?
In der Praxis will ich doch z.B. nach Vor- und Nachnamen suchen, wie würd ich dass den machen?
In der Praxis sieht das so aus, das du einen Index (Hier: View) aufbaust der die von dir zu durchsuchenden Informationen enthält:
function(doc) {
emit([doc.firstname, doc.lastname], doc);
}
Suchen kannst du dann, indem du alle Dokumente des Views mit den Schlüsseln zwischen ["Mü", ""] und ["N",""] abfragst. Es gibt nicht wie bei SQL Funktionen um zB bei Abfragen bestimmte Infos zu filtern. Du must solche Anforderungen vorher fest in die Views verdrahten, da diese vorgeneriert werden.
Dann musst du nur "MacOS" gegen "Linux" ersetzen...
Grundsätzlich ist es so, dass CouchDB (genau so wie Key-Value-Stores) erstmal nur nach Schlüsseln suchen kann und dann deren Wert ausgibt.
Eine Abfrage wie "zeig' mir alle Schlüssel in allen Dokumenten, die den Wert 'foo' haben" musst du i.d.R. softwareseitig umsetzen, also nicht als View in der DB.
Tipp: CouchDB installieren und spielen. Es ist nämlich eigentlich ziemlich simpel.
Gruß, Jochen
Du kannst nach dem Key mittels Parameter bei der HTTP Abfrage filter:
...view....?startkey="a"&endkey="b"
Hallo,
bei so nem großen Artikel fehlt mir ein bei Datenspeichern doch äußerst wichtiges Thema: Performance!
- Wie lange braucht die CouchDB z.B. für den Import von 100.000 "Dokumenten" (das Wort Datensatz ist ihnen wohl zu schnöde?) mit sagen wir mal 20 Feldern, wovon die Hälfte Varchar sind?
Ein "herkömmliches" DBMS schafft das auf billiger Hardware so in ca. 5 Sekunden.
- Wie lange dauern komplexere Abfragen?
- Wie wirkt sich das für nicht gerade optimierte HTTP-Protokoll auf die Übertragung aus?
Usw. ...
Viele Grüße!
Da musst du wohl mal nach Benchmarkergebnissen suchen...
> Wie lange dauern komplexere Abfragen?
Die Frage kann man pauschal natürlich (für keine DB) beantworten - kommt auf die Last auf dem Server an, die Geschwindigkeit der Hardware etc. Jedenfalls ist es so, dass CouchDB das Ergebnis von permanenten Views cached, d.h. es sollte relativ schnell sein.
> Wie wirkt sich das für nicht gerade optimierte HTTP-Protokoll auf die Übertragung aus?
Du bekommst ein JSON-Objekt zurück... d.h. die Übertragungszeit richtet sich nach der Größe des JSON-Objekts und nach der Bandbreite deiner Anbindung...
Gruß, Jochen
Hallo Jochen,
na das sind ja auch nur Allgemeinplätze ohne jeden Aussagewert...
Worum es mir ging, war, dass der Autor des Artikels halt auch ein Auge auf die Performance hätte werfen sollen.
In diversen Foreneinträgen liest man halt oft was von wahrhaft _grottenschlechter_ Performance von CouchDB.
und wenn der Autor das Programm schon für einen ellenlangen Artikel testet, dann muss er IMHO halt auch ein paar wie auch immer geartete Performance-Tests machen sollen - gerade bei einer Datenbank wohl einer der _Hauptmerkmale_!
... Oder wenigstens auf ein paar _brauchbare_ Benchmarkergebnisse verlinken sollen.
Grundsätzlich richtig. Wobei der Artikel auch (bewusst) auf die grundsätzliche Anwendung (und Möglichkeiten) einer dokument-orientierten DB fokussiert als auf Performance.
Da meine CouchDBs vergleichsweise klein sind hatte ich noch nie Performance-Probleme. Wie es sich bei einer DB mit X-zehntausend Dokumenten verhält weiß ich in der Tat nicht.
BTW - habe gerade mal schnell gegoogle. Die Benchmarks, die ich so gesehen habe sind alle eher alt, also CouchDB V 0.9 oder älter.
Wer also einen aktuellen Benchmark hat...
Gruß, Jochen
Vorab: Sorry, auch ich hab keine richtige Benchmark zahlen...
Ich habe mich letzter Zeit etwas mit CouchDB befasst.
> Wie lange braucht die CouchDB z.B. für den Import von 100.000
> "Dokumenten" (das Wort Datensatz ist ihnen wohl zu schnöde?) mit sagen
> wir mal 20 Feldern, wovon die Hälfte Varchar sind?
> Ein "herkömmliches" DBMS schafft das auf billiger Hardware so in ca. 5
> Sekunden.
Ich hab von 3000 docs/s gehört. Allerdings lässts sich scheinbar ziemlich linear skalieren (da docs unabhängig voneinander sind). Sind dan wohl über 30 Sekunden...
Allerdings macht der vergleich auch recht wenig Sinn. Den wenn du mit CouchDB eine Applikation machst, musst du denormalisieren. Das führt dazu das du viel weniger Dokumente anlegst als Zeilen in einem herkömlichen relationalen DBMS. Beispiel Rechnung: "Rechnungsposition" "Rechnungskopfbeziehung", durchschnittlich 10 Positionen. Der Overhead zum Erstellen ist bei CouchDB pro Rechnung, daher ist die Geschwindigkeit zum Anlegen von Dokumenten nicht ganz so entscheidend.
> - Wie lange dauern komplexere Abfragen?
Das ist das coole am Map/Reduce. Map wird beim Insert ausgeführt und über das Ergebnis ein Index auf den Output von Map gelegt (B-Tree). Reduce erst bei der Abfrage. Daher ist die halbe Abfrage bei der effektiven Abfrage bereits erledigt (natürlich auf kosten des Inserts, aber dort machst du es halt einmal).
Also sollte CouchDB (mit richtiger Anwendung von Map/Reduce) insbesondere bei Abfragen hochperformant sein. Google verwendet diesen Algorythmus in seinen Datencentern...
> - Wie wirkt sich das für nicht gerade optimierte HTTP-Protokoll auf die Übertragung aus?
Negativ, wie den sonst? Aber wenn du nach MySQL noch ein PHP hast, das dein Resultset etas bearbeitet und über HTTP zum Client sendest, hast du den HTTP-Overhead auch... Zudem noch ein Prozesswechsel und Daten werden wahrscheinlich einmal mehr kopiert. Bei CouchDB kannst du direkt vom Client mittels AJAX die Datenbank abfragen. CouchDB ist eine Datenbank für Webapplikationen.
Gruss
falstaff
Ich entschuldige mich für die Rechtschreibfehler, irgendwie hab ich das redigieren vergessen
Macht nix mit den Typos
Und thx für deinen Kommentar.
Es ist völlig richtig, dass man bei einem Benchmark Relational (SQL) vs. CouchDB Äpfel mit Birnen vergleicht (siehe auch hier: http://stackoverflow.com/questions/1296741/performance-benchmark-couchdb-x-relational-databases , erster Kommentar)
Natürlich ist die Performance wichtig, aber der Grund, auf CouchDB zu wechseln ist eben nicht, um schneller zu werden, sondern um die Vorteile einer dokumenten-orientieren Datenbank zu nutzen. Wenn sie denn Vorteile für die eigenen Applikation bietet. Das muss jeder selber rausfinden.
Gruß, Jochen
Warum sollte es richtig sein "dass man bei einem Benchmark Relational (SQL) vs. CouchDB Äpfel mit Birnen vergleicht"?
Bitte entweder begründen oder sein lassen.
Der Junge, der da bei Stackoverflow diesen Blödsinn ebenfalls ohne Begründung hingerotzt hat und Widerspruch oder Ignoranz dafür geerntet hat, ist sicher keine Referenz.
Ja, danke für den Kommentar, da steht doch wenigstens schon mal ein wenig was drin
>> Ich hab von 3000 docs/s gehört
Das ist das dumme: Ich hab was von 25 docs/s (http://jacobian.org/writing/couchdb/) oder 4,5 - 258 docs/s (http://books.couchdb.org/relax/reference/high-performance - mit bulk load "sagenhafte" 4000 d/s) gelesen - und das ist schon ein gewaltiger Unterschied.
Map-Reduce ist natürlich eine schöne Sache - wenn man ein Dutzend Rechner (aufwärts) parallel für eine Anwendung betreiben kann. Dann genau dafür ist es gemacht: Extreme horizontale Skalierung durch Nutzung von vielen Festplatten (mal ganz einfach gesagt). Ob das das richtige für kleine PHP-Webanwendungen ist, wofür du CouchDB ja prädestiniert siehst, bezweifel ich mal .
Und wenn jede (!) Spalte (automatisch?) indiziert wird, wie groß wird dann wohl der Index? Das würde allerdings in der Tat den extremen Insert erklären. Spaltenorientierte Datenbanken gibts übrigens auch für "normales" SQL - z.B. die Calpont-Engine für MySQL.
HTTP: Klar, wenn man mit PHP arbeitet, kommts auf den HTTP-Overhead auch nicht mehr an. Andererseits hätte es ja sein können, dass CouchDB die Inhalte z.B. zippt, was bei JSON-Dokumenten schon mal 90 % Netzlast reduziert?
Wie auch immer, einen schönen Tag noch und harren wir da der Dinge die da kommen!
P.S.: Einen schweren "Rückfall" musste die NoSQL-Bewegung hinnehmen, als Twitter erklären musste, dass sie halt doch eine normale Datenbank für die Tweets nehmen mussten: http://highscalability.com/blog/2010/7/11/so-why-is-twitter-really-not-using-cassandra-to-store-tweets.html