Wann ist CouchDB besser als MongoDB und wann ist es umgekehrt?

Question

Ich stecke zwischen diesen beiden NoSQL-Datenbanken fest.

In meinem Projekt werde ich eine Datenbank innerhalb einer Datenbank erstellen. Ich brauche zum Beispiel eine Lösung, um dynamische Tabellen zu erstellen.

So können Benutzer Tabellen mit Spalten und Zeilen erstellen. Ich denke, dass entweder MongoDB oder CouchDB dafür gut geeignet sind, aber ich bin mir nicht sicher, welches davon. Ich brauche auch ein effizientes Paging.

Answer 1

Welche 2 von C, A und P (Konsistenz, Verfügbarkeit und Partitionstoleranz) sind für Sie wichtiger? Schnellreferenz, die Visueller Leitfaden für NoSQL-Systeme

• MongodB : Konsistenz und Teilungstoleranz
• CouchDB : Verfügbarkeit und Partitionstoleranz

Ein Blogbeitrag, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j Vergleich hat ' Beste Verwendung ' Szenarien für jede verglichene NoSQL-Datenbank. Ich zitiere den Link,

• MongoDB: Wenn Sie dynamische Abfragen benötigen. Wenn Sie es vorziehen, Indizes und keine Map/Rece-Funktionen zu definieren. Wenn Sie eine gute Performance auf einer großen DB benötigen. Wenn Sie CouchDB wollten, aber Ihre Daten ändern sich zu oft und füllen die Festplatten.
• CouchDB : Zum Sammeln von sich gelegentlich ändernden Daten, auf denen vordefinierte Abfragen ausgeführt werden sollen. Orte, an denen die Versionierung wichtig ist.

Eine aktuelle (Februar 2012) und mehr umfassender Vergleich von Riyad Kalla,

• MongoDB : NUR Master-Slave-Replikation
• CouchDB : Master-Master Replikation

Ein Blogbeitrag (Oktober 2011) von jemandem, der beides ausprobiert hat, Ein MongoDB-Typ lernt CouchDB kommentiert, dass das Paging von CouchDB nicht so nützlich ist.

A datiert (Jun 2009) Benchmark von Kristina Chodorow ( Teil des Teams hinter MongoDB ),

Ich würde mich für MongoDB entscheiden.

Answer 2

Die obigen Antworten machen die Sache zu kompliziert.

1. Wenn Sie planen, eine mobile Komponente zu haben, oder wenn Desktop-Benutzer offline arbeiten und ihre Arbeit mit einem Server synchronisieren sollen, brauchen Sie CouchDB.
2. Wenn Ihr Code nur auf dem Server ausgeführt werden soll, sollten Sie MongoDB verwenden.

Das war's. Wenn Sie nicht die (großartige) Fähigkeit von CouchDB benötigen, auf mobile und Desktop-Geräte zu replizieren, hat MongoDB derzeit den Vorteil der Leistung, der Community und der Werkzeuge.

Answer 3

Eine sehr alte Frage, aber sie steht bei Google ganz oben, und die Antworten, die ich sehe, gefallen mir nicht ganz, also hier ist meine eigene.

Couchdb bietet viel mehr als nur die Möglichkeit, CouchApps zu entwickeln. Die meisten Leute benutzen CouchDb in einer klassischen 3-Tiers Web Architektur.

In der Praxis wird der entscheidende Faktor für die meisten Leute die Tatsache sein, dass MongoDb Ad-hoc-Abfragen mit einer SQL-ähnlichen Syntax erlaubt, während CouchDb dies nicht tut (man muss Map/Rece Views erstellen, was einige Leute abschreckt, obwohl das Erstellen dieser Views Rapid Application Development freundlich ist - sie haben nichts mit Stored Procedures zu tun).

Um auf die in der akzeptierten Antwort angesprochenen Punkte einzugehen: CouchDb hat ein großartiges Versionierungssystem, aber das bedeutet nicht, dass es nur für Bereiche geeignet ist, in denen Versionierung wichtig ist (oder besser geeignet ist). Außerdem ist CouchDb dank seiner Append-Only-Natur sehr schreibfreundlich (Schreiboperationen kehren in kürzester Zeit zurück und garantieren, dass keine Daten verloren gehen).

Eine sehr wichtige Sache, die von niemandem erwähnt wird, ist die Tatsache, dass CouchDb auf B-Tree Indizes basiert. Das bedeutet, dass die Abfragezeit immer unter 10ms bleibt, egal ob man 1 "Zeile" oder 20 Milliarden hat. Das ist ein entscheidender Faktor, der CouchDb zu einer latenzarmen und lesefreundlichen Datenbank macht, und das sollte wirklich nicht übersehen werden.

Fairerweise muss man sagen, dass der Vorteil von MongoDb gegenüber CouchDb im Tooling und Marketing liegt. MongoDb verfügt über erstklassige Tools für alle wichtigen Sprachen und Plattformen, die den Einstieg erleichtern und zusammen mit den Adhoc-Abfragen den Übergang von SQL noch einfacher machen.

CouchDb verfügt nicht über dieses Niveau an Werkzeugen - auch wenn es heute viele Bibliotheken gibt - aber CouchDb ist als HTTP API offengelegt und es ist daher recht einfach, einen Wrapper in der eigenen Sprache zu erstellen, um damit zu kommunizieren. Ich persönlich mag diesen Ansatz, da er eine Aufblähung vermeidet und es erlaubt, nur das zu nehmen, was man will (Prinzip der Schnittstellentrennung).

Ich würde also sagen, dass die Verwendung des einen oder des anderen weitgehend eine Frage der Bequemlichkeit und der Vorliebe für die jeweiligen Paradigmen ist. Der CouchDb-Ansatz "passt" einfach für bestimmte Leute, aber wenn man sich mit den Datenbankfunktionen vertraut gemacht hat (in der ausführlichen offizieller Führer ) Sie nicht Ihren "hell yeah"-Moment haben, sollten Sie wahrscheinlich weiterziehen.

Ich würde davon abraten, CouchDb zu benutzen, wenn man einfach nur "das richtige Werkzeug für den richtigen Job" benutzen will, denn man wird herausfinden, dass man es nicht einfach so benutzen kann und man wird am Ende sauer sein und Blogbeiträge schreiben wie "Wo sind Joins in CouchDb?" und "Wo ist das Transaktionsmanagement?". In der Tat ist CouchDb - paradoxerweise - sehr transparent, aber gleichzeitig erfordert es einen Paradigmenwechsel und eine Änderung der Art und Weise, wie man Probleme angeht, um wirklich zu glänzen (und wirklich zu funktionieren).

Aber wenn man das getan hat, zahlt es sich wirklich aus. Ich persönlich bräuchte sehr triftige Gründe oder einen wichtigen Grund für ein Projekt, um eine andere Datenbank zu wählen, aber bisher habe ich noch keine gefunden.

Aktualisierung im Dezember 2022: Da dieser Beitrag immer noch häufig aufgerufen wird, war es mir wichtig, den Leuten mitzuteilen, dass ich kürzlich dazu übergegangen bin, MongoDB als meinen täglichen Treiber zu verwenden, während ich CouchDB für spezielle Fälle, in denen diese Datenbank mehr Sinn macht (nämlich für Fälle, in denen Views nicht benötigt werden), im Werkzeuggürtel behalte. Es gab mehrere Gründe für diese Entscheidung, die wichtigsten waren:

• Leistung : Während vorberechnete Indizes ein mächtiger Vorteil sind, liegt die größte Einschränkung von CouchDB in der QueryServer Architektur. Jedes Mal, wenn ein Dokument aktualisiert wird, muss es serialisiert und von jedem View verarbeitet werden (auch wenn dies zeitversetzt geschieht, nämlich wenn auf den View zugegriffen wird). Noch wichtiger ist jedoch, dass jedes Mal, wenn eine Ansicht aktualisiert wird (z. B. um eine Filterlogik für ein neues Feld hinzuzufügen, das als Teil der Implementierung einer neuen Funktion hinzugefügt wurde), ALLE Dokumente der Datenbank an die Ansicht gesendet werden müssen. Dies wird zu einem großen Problem, wenn Sie Millionen von Dokumenten in der Datenbank haben. Sie machen sich Gedanken über die Auswirkungen von Aktualisierungen Ihrer Ansichten und das lenkt Sie ab. Wenn Sie sich dafür entscheiden, eine Datenbank pro Datentyp zu erstellen, um diese Einschränkung zu umgehen, verlieren Sie die Möglichkeit, alle Dokumente zu mappen/reduzieren, da Views pro Datenbank skaliert sind. MongoDB vermeidet dies, indem es die Dokumente in Sammlungen (d. h. Datentypen) unterteilt, so dass bei der Aktualisierung eines Index nur eine Teilmenge der Daten der Datenbank betroffen ist. Außerdem verwendet MongoDB ein binäres Format, was diese Operationen viel performanter macht (während CouchDB JSON verwendet, das im Klartext an den View Server gesendet wird). Dieser Punkt ist vielleicht nicht wichtig, wenn Sie keine Produkte entwickeln, die in großem Maßstab betrieben werden müssen (Hunderttausende von täglichen Nutzern oder mehr).
• den Werkzeugen Die mit MongoDB verfügbare Software ist umfassend und ausgereift, ob es sich nun um die offiziell unterstützten Treiber für verschiedene Programmiersprachen oder die Integration in IDEs handelt.
• Erweiterte Abfragen : Eine breite Palette von Datentypen und fortgeschrittenen Abfragemöglichkeiten sind sofort verfügbar (Geo-Typen, GridFS, das es erlaubt, Dateien beliebiger Größe direkt in der DB zu speichern, usw...). Der einfache Zugang zu mächtigen Abfrageaggregationsfunktionen machte mir klar, wie sehr CouchDB meine Produktivität behindert hatte.
• Nahtlose Unterstützung für Resharding Bei MongoDB ist Resharding einfach, während es bei CouchDB eine gefährliche Operation ist, bei der Dateien von Hand verschoben werden müssen.
• Viele andere kleine Dinge, die die Lebensqualität verbessern und sich wirklich summieren.

Ich war ein großer CouchDB-Fan, aber ich muss zugeben, dass sich der Umstieg auf MongoDB als täglicher Treiber in Bezug auf Produktivität und Lebensqualität wie eine Rückkehr in die Zivilisation anfühlt. Jetzt ziehe ich CouchDB nur noch für Key-Value-Store-Szenarien in Betracht (in denen keine Map-Reduce-Ansichten benötigt werden und alles, was benötigt wird, ist, ein Dokument nach Schlüssel abzurufen - hier glänzt CouchDB) und für fortgeschrittene Situationen, in denen Datenbanken für jeden Benutzer benötigt werden (z.B. zur Unterstützung einer fortgeschrittenen Synchronisation zwischen Geräten).

Der einzige Nachteil, den ich bei MongoDB sehe, ist, dass es so viel Speicher verbraucht, dass ich es nicht auf Entwicklungsrechnern mit niedrigen Spezifikationen installieren kann (während im Vergleich dazu couchdb beim Start gestartet wird, ohne dass ich es bemerke, und fast keine Ressourcen verbraucht). Ich denke jedoch, dass sich dies angesichts der Zeitersparnis und der angebotenen Funktionen lohnt.

Als langjähriger CouchDB-Nutzer sehe ich in MongoDB einen ganz anderen Wert als in den anderen Antworten, die für MongoDB werben. Deshalb war es mir wichtig, dieses Update zu geben (und auch aus intellektueller Ehrlichkeit, als ich mich an diesen Beitrag erinnerte). CouchDB gab mir damals einen ziemlichen Produktivitätsschub im Vergleich zu den SQL-Produkten und ORMs, die ich bis dahin verwendet hatte, und zu dieser Zeit kursierten eine Menge Horrorgeschichten über die Zuverlässigkeit von MongoDB.

Die wenigen Bedenken, die ich haben könnte (und denen die Internetnutzer wahrscheinlich unverhältnismäßig viel Bedeutung beigemessen haben - sie liefen im Wesentlichen auf Standardeinstellungen hinaus, deren Kompromisse bei der Zuverlässigkeit neue Nutzer in einigen Szenarien überraschen könnten), sind jetzt jedoch nicht mehr vorhanden.

Als langjähriger CouchDB-Nutzer, der beide Produkte vergleichen kann, würde ich MongoDB allen empfehlen, die eine produktive und skalierbare Software-Entwicklung für ihre Web-Applikationen benötigen und raten, CouchDB nur für spezielle Anforderungen zu wählen.

CouchDB hatte damals viel Schwung, was wahrscheinlich meine Wahrnehmung beeinflusst hat, aber die Entwicklung ist ins Stocken geraten, es wurden seit langem keine sinnvollen Features mehr eingeführt, sonst hätte es wahrscheinlich mit MongoDB in Sachen Lebensqualität gleichgezogen. Ich sehe zwei mögliche Gründe dafür: die Art und Weise, wie eine jetzt abgebrochene Überarbeitung von CouchDB lange Zeit Ressourcen abgezogen hat, und vielleicht frühe architektonische Entscheidungen (wie die Query Server Architektur), die seine Zukunft von Anfang an eingeschränkt haben könnten. Keiner dieser Aspekte scheint die Priorität des Kernteams zu sein.

Ich bereue nicht, dass ich mich für CouchDB entschieden habe, denn es war sehr hilfreich und die Denkweise, die ich dadurch gelernt habe, ist extrem hilfreich, um performanten Code in MongoDB zu schreiben (performanten Code in MongoDB zu schreiben ist ein Kinderspiel im Vergleich zu der Disziplin, die man aufbringen muss, um Geschäftsprobleme mit CouchDB zu lösen). Wenn ich heute noch einmal die Wahl hätte, wäre ich schon viel früher auf MongoDB umgestiegen, um täglich damit zu arbeiten. Normalerweise bin ich ziemlich gut darin, auf das siegreiche Pferd zu setzen, wenn Technologien auftauchen, aber dieses Mal scheint es, dass ich das Spiel nicht so gut gespielt habe. Ich hoffe, das hilft.

Answer 4

Stellen Sie sich diese Fragen selbst? Und Sie werden Ihre DB-Auswahl entscheiden.

1. Benötigen Sie Master-Master ? Dann CouchDB. CouchDB unterstÃ?tzt hauptsÃ?chlich die Master-Master-Replikation, die voraussetzt, dass die Knoten fÃ?r lÃ?ngere Zeit nicht verbunden sind. MongoDB würde in dieser Umgebung nicht gut funktionieren.
2. Benötigen Sie MAXIMALer R/W-Durchsatz ? Dann MongoDB
3. Benötigen Sie ultimative Haltbarkeit eines einzelnen Servers weil Sie nur einen einzigen DB-Server haben werden? Dann CouchDB.
4. Speichern Sie eine MASSIVE Daten Menge, die gesplittet werden muss und gleichzeitig einen wahnsinnigen Durchsatz hat? Dann ist MongoDB genau das Richtige.
5. Benötigen Sie starke Konsistenz von Daten? Dann MongoDB.
6. Benötigen Sie hohe Verfügbarkeit der Datenbank? Dann CouchDB.
7. Hoffen Sie mehrere Datenbanken und mehrere Tabellen/Sammlungen? Dann MongoDB
8. Sie haben eine mobile app offline benutzer und ihre Aktivitätsdaten mit einem Server synchronisieren möchten? Dann brauchen Sie CouchDB.
9. Benötigen Sie eine große Vielfalt an abfragen. Motor? Dann ist MongoDB
10. Benötigen Sie große Gemeinschaft DB zu verwenden? Dann MongoDB

Answer 5

Ich fasse die in diesem Artikel gefundenen Antworten zusammen:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB: Bessere Abfragen, Datenspeicherung in BSON (schnellerer Zugriff), bessere Datenkonsistenz, mehrere Sammlungen

CouchDB: Bessere Replikation, mit Master-to-Master-Replikation und Konfliktlösung, Datenspeicherung in JSON (menschenlesbar, besserer Zugriff durch REST-Services), Abfragen durch Map-Reduce.

Fazit: MongoDB ist schneller, CouchDB ist sicherer.

Auch: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb