Hallo allerseits,
ich beschäftige mich seit "längerer" Zeit mit dokumentenbasierten Datenbanken (hauptsächlich MongoDB) und finde den Ansatz an kein Schema gebunden zu sein, sowie die einfache Administration und Skalierbarkeit (von MongoDB) mehr als toll. Bei einigen (teils Test-)Webapplikationen habe ich mit MongoDB nur gute Erfahrungen gesammelt. Was mich bis jetzt aber von einem generellen Einsatz von MongoDB abgehalten hat, sind die Tatsachen das die Unterstützung unter den Python-Frameworks noch nicht so perfekt bzw. noch nicht so wirklich vorhanden ist, ebenso das MongoDB Datensicherheit nur bei Verwendung eines Clusters aus mehreren Instanzen garantiert, "Single-Server-Durability" ist aber für Version 1.8 geplant. Besonders der letzte Grund hat mich dazu veranlasst mir CouchDB anzusehen, welches nach einem ersten Überblick, im Punkto Datensicherheit besser sein könnte. Der Ansatz über HTTP-REST mit CouchDB zu "sprechen" ist im Vergleich zu MongoDB etwas ungewohnt, hat aber sicher auch seine Vorteile. Ebenso der Ansatz das ein Query (immer) als map/reduce formuliert werden muss, fühlt sich, wenn man MongoDB mit seinem Abfrage-Syntax gewohnt ist, etwas fremd an. CouchDB lässt sich natürlich ebenso wie MongoDB auch als Datenbank für eine Webapplikation verwenden, aber rein gefühlsmäßig ist MongoDB für dieses Umfeld besser geeignet. Durch die Versionierung die CouchDB bietet, sehe ich CouchDB eher als Speicherlösung z.B. für Dokumente im Geschäftsumfeld (wie Rechnungen, Lieferscheine etc.), die man nachträglich auswerten möchte oder als Speicherlösung für Adressen usw.
Ich lasse mich natürlich gern von anderen Einsatzszenarien überzeugen.
Wo verwendet ihr CouchDB, bzw. wo würdet ihr es noch verwenden?
Wie sind eure Erfahrungen in Bezug auf Datensicherheit und Stabilität?
Habt ihr Webanwendungen darauf laufen?
Grüße
metty
Wann CouchDB, wann MongoDB?
Wenn du viele Daten hast und sowieso mehr als einen Server brauchst, ist MongoDB eine gute Wahl. Und Version 1.8 wird auch nicht mehr so lange hin sein. CouchDB würde ich nur in Erwägung ziehen, wenn ich relativ wenig Daten habe, also der Komfort der schemalosen strukturierten Dokumente wichtiger ist als Performance usw. CouchDB ist gut, wenn du zwischen eigenständigen Servern synchronisieren willst (etwa einer CouchDB-Instanz auf einem Handy mit einer zweiten Instanz auf dem Desktop statt das man sich mit SyncML die Kugel gibt). CouchDB scheint mir auch sehr interessant, wenn es um in der DB direkt laufende Webapps geht. Habe ich aber leider keine praktischen Erfahrungen mit.
MongoDB hat meiner Einschätzung nach die größere Community. Die DB ist quasi das MySQL der NOSQL-Welt. Ich denke, es ist auch einfacher, ad hoc queries direkt in JavaScript zu formulieren, als map/reduce zu programmieren. Ach ja: Die Unterstützung von MongoDB bei Ruby und Rails ist übrigens ausgezeichnet
Übrigens, statt CouchDB ist vielleicht auch Riak noch interessant. Deren Alleinstellungsmerkmal scheint die integrierte Volltextsuche zu sein. Das könnte gerade wenn man strukturierte Text-Dokumente (sprich CMS) speichern will, sehr interessant sein. Die anderen Hersteller murmeln dann etwas wie Lucene, Solr, usw., aber es ist immer eine externe Lösung. Und eigentlich gibt es da eine große Überlappung. Ein verteiltes Solr etwa braucht eigentlich die selbe Infrastruktur, wie sie auch die DBs haben. Unnötig, dass das da alles noch mal (basierend auf Indices, die in einfachen Dateien abgespeichert werden) implementiert wurde.
Stefan
MongoDB hat meiner Einschätzung nach die größere Community. Die DB ist quasi das MySQL der NOSQL-Welt. Ich denke, es ist auch einfacher, ad hoc queries direkt in JavaScript zu formulieren, als map/reduce zu programmieren. Ach ja: Die Unterstützung von MongoDB bei Ruby und Rails ist übrigens ausgezeichnet
Übrigens, statt CouchDB ist vielleicht auch Riak noch interessant. Deren Alleinstellungsmerkmal scheint die integrierte Volltextsuche zu sein. Das könnte gerade wenn man strukturierte Text-Dokumente (sprich CMS) speichern will, sehr interessant sein. Die anderen Hersteller murmeln dann etwas wie Lucene, Solr, usw., aber es ist immer eine externe Lösung. Und eigentlich gibt es da eine große Überlappung. Ein verteiltes Solr etwa braucht eigentlich die selbe Infrastruktur, wie sie auch die DBs haben. Unnötig, dass das da alles noch mal (basierend auf Indices, die in einfachen Dateien abgespeichert werden) implementiert wurde.
Stefan
Weiß...sma hat geschrieben:Ach ja: Die Unterstützung von MongoDB bei Ruby und Rails ist übrigens ausgezeichnet
Mit Mongoid steht ein super ODM zur Verfügung und Devise funktioniert ebenfalls mit Mongoid. Wie du schon vor einiger Zeit in meinem Beitrag Warum immer Ruby on Rails? festgestellt hast, ist die Ruby-Community gefühlt aktiver und implementiert neue Features schneller. Dem kann bzw. muss ich mittlerweile zustimmen. Ich spiele seit geraumer Zeit mit Ruby, lese Code von Rails-Plugins und bin wirklich angetan. Deshalb werde ich mich endgültig übers spielen hinaus mit Ruby und Ruby on Rails beschäftigen und (wenn ich es gut genug beherrsche) ein kommendes Web-Projekt mit Rails umsetzen. Mittlerweile leuchtet mir sogar ein was Rails da macht.
Riak hab ich schon kurz angetestet, es aber wieder sein lassen, weil es für meinen Geschmack nicht sonderlich stabil ausgesehen hat. Außerdem finde ich MongoDB angenehmer zu bedienen...