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
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