it-swarm.com.de

Wann ist CouchDB über MongoDB zu verwenden und umgekehrt?

Ich stecke zwischen diesen beiden NoSQL-Datenbanken fest.

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

So können Benutzer Tabellen mit Spalten und Zeilen erstellen. Ich denke, entweder MongoDB oder CouchDB werden dafür gut sein, aber ich bin mir nicht sicher, welches. Ich werde auch effizientes Paging brauchen.

608
Luke101

Von C, A & P (Konsistenz, Verfügbarkeit & Partitionstoleranz), welche 2 sind für Sie wichtiger? Kurzreferenz, der Visual Guide To NoSQL Systems

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

Ein Blogeintrag, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j Vergleich hat ' Am besten verwendete Szenarien für jede NoSQL-Datenbank im Vergleich. Zitiert den Link,

  • MongoDB: Wenn Sie dynamische Abfragen benötigen. Wenn Sie lieber Indizes definieren, werden Funktionen nicht zugeordnet/reduziert. Wenn Sie eine gute Leistung auf einer großen Datenbank benötigen. Wenn Sie CouchDB wollen, aber Ihre Daten sich zu sehr ändern, füllen Sie die Festplatten.
  • CouchDB: Zum Sammeln und gelegentlichen Ändern von Daten, für die vordefinierte Abfragen ausgeführt werden sollen. Orte, an denen die Versionierung wichtig ist.

Eine aktuelle (Feb 2012) und mehr mfassender Vergleich von Riyad Kalla,

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

Ein Blogeintrag (Oktober 2011) von jemandem, der beide ausprobiert hat, Ein MongoDB-Typ lernt CouchDB kommentierte, dass das Paging der CouchDB nicht funktioniert als nützlich.

Ein datierter (Jun 2009) Benchmark von Kristina Chodorow ( Teil des Teams hinter MongoDB ),

Ich würde mich für MongoDB entscheiden.

Ich hoffe es hilft.

506
user799188

Die Antworten erschweren vor allem die Geschichte.

  1. Wenn Sie eine mobile Komponente haben möchten oder Desktop-Benutzer offline arbeiten und ihre Arbeit dann mit einem Server synchronisieren müssen, benötigen Sie CouchDB.
  2. Wenn Ihr Code nur auf dem Server ausgeführt wird, wählen Sie MongoDB

Das ist es. Sofern Sie nicht die (großartige) Fähigkeit von CouchDB benötigen, sich auf mobile und Desktop-Geräte zu replizieren, bietet MongoDB derzeit den Vorteil von Leistung, Community und Tools.

202
Ewan Makepeace

Sehr alte Frage, aber sie steht ganz oben auf Google und ich mag die Antworten, die ich sehe, nicht so recht. Hier ist meine eigene.

Couchdb bietet viel mehr als die Möglichkeit, CouchApps zu entwickeln. Die meisten Leute verwenden CouchDb in einer klassischen 3-Ebenen-Webarchitektur.

In der Praxis wird der entscheidende Faktor für die meisten Menschen die Tatsache sein, dass MongoDb Ad-hoc-Abfragen mit einer SQL-ähnlichen Syntax ermöglicht, während CouchDb dies nicht tut (Sie müssen Karten-/Reduzierungsansichten erstellen, was manche Menschen ausschaltet, obwohl sie diese Ansichten erstellen) ist Rapid Application Development-freundlich - sie haben nichts mit gespeicherten Prozeduren zu tun).

Um Punkte zu adressieren, die in der akzeptierten Antwort angesprochen wurden: CouchDb hat ein großartiges Versionssystem, das jedoch nicht bedeutet, dass es nur für Stellen geeignet ist (oder besser), an denen Versionsverwaltung wichtig ist. Außerdem ist couchdb dank seiner Nur-Anhängen-Funktion schreibgeschützt (Schreibvorgänge 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 sich auf B-Tree-Indizes stützt. Dies bedeutet, dass unabhängig davon, ob Sie 1 "Zeile" oder 20 Milliarden haben, die Abfragezeit immer unter 10 ms bleibt. Dies ist ein Game Changer, der CouchDb zu einer Datenbank mit geringer Latenz und Lesefreundlichkeit macht, und dies sollte wirklich nicht übersehen werden.

Um fair und vollständig zu sein, ist der Vorteil, den MongoDb gegenüber CouchDb hat, Tooling und Marketing. Sie verfügen über erstklassige Citizen-Tools für alle wichtigen Sprachen und Plattformen, die das On-Boarding vereinfachen, und diese zusätzlichen Ad-hoc-Abfragen machen den Übergang von SQL noch einfacher.

CouchDb verfügt nicht über dieses Tool-Level - obwohl es heutzutage viele Bibliotheken gibt -, aber CouchDb ist als HTTP-API verfügbar und es ist daher ziemlich einfach, einen Wrapper in Ihrer Lieblingssprache zu erstellen, um mit ihm zu kommunizieren. Ich persönlich mag diesen Ansatz, da er das Aufblähen vermeidet und es Ihnen erlaubt, nur das zu nehmen, was Sie wollen (Prinzip der Schnittstellentrennung).

Daher würde ich sagen, dass die Verwendung des einen oder anderen Modells im Wesentlichen eine Frage des Komforts und der Präferenz für das jeweilige Modell ist. CouchDb-Ansatz "passt" für bestimmte Leute, aber wenn Sie nach dem Erlernen der Datenbankfunktionen (in der vollständigen offiziellen Anleitung ) nicht Ihren "Höllen-Ja" -Moment haben, sollten Sie wahrscheinlich weitermachen .

Ich würde davon abraten, CouchDb zu verwenden, wenn Sie nur "das richtige Werkzeug für den richtigen Job" verwenden möchten. weil du herausfindest, dass du es nicht einfach so verwenden kannst und sauer wirst und Blog-Posts wie "Wo sind Joins in CouchDb?" und "Wo ist Transaktionsmanagement?". Couchdb ist zwar - paradoxerweise - sehr transparent, erfordert aber gleichzeitig einen Paradigmenwechsel und eine Änderung der Art und Weise, wie Sie Probleme angehen, um wirklich zu glänzen (und wirklich zu arbeiten).

Aber sobald Sie das getan haben, zahlt es sich wirklich aus. Ich persönlich brauche starke Gründe oder einen großen Deal Breaker für ein Projekt, um eine andere Datenbank auszuwählen, aber bisher habe ich noch keine getroffen.

53
tobiak777

Stellen Sie diese Fragen selbst? Und Sie bestimmen Ihre DB-Auswahl.

  1. Benötigen Sie Master-Master? Dann CouchDB. Hauptsächlich unterstützt CouchDB die Master-Master-Replikation, bei der Knoten für längere Zeit getrennt werden. MongoDB würde in dieser Umgebung nicht gut abschneiden.
  2. Benötigen Sie MAXIMALER R/W-Durchsatz? Dann MongoDB
  3. Benötigen Sie ultimative Single-Server-Beständigkeit, weil Sie nur einen einzigen DB-Server haben werden? Dann CouchDB.
  4. Speichern Sie ein MASSIVE data - Set, das gesplittet werden muss, während der irrsinnige Durchsatz erhalten bleibt? Dann MongoDB.
  5. Benötigen Sie starke Konsistenz von Daten? Dann MongoDB.
  6. Benötigen Sie eine 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 möchten ihre Aktivitätsdaten mit einem Server synchronisieren? Dann brauchen Sie CouchDB.
  9. Benötigen Sie eine Vielzahl von abfragenden Motoren? Dann MongoDB
  10. Benötigen Sie großes Gemeinschaft, um DB zu verwenden? Dann MongoDB
33
Somnath Muluk

Ich fasse die Antworten in diesem Artikel zusammen:

http://www.quora.com/Wie-geht-MongoDB-?

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

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

Zusammenfassend ist MongoDB schneller und CouchDB sicherer.

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

25
Alexis Dufrenoy

Seien Sie sich eines Problems mit wenigen eindeutigen Indizes in MongoDB bewusst. Ich habe es getroffen und es ist extrem umständlich, es zu umgehen.

Das Problem ist: Sie haben ein Feld, das eindeutig ist, wenn es vorhanden ist, und Sie möchten alle Objekte finden, bei denen das Feld fehlt. Die Art und Weise, wie spärliche eindeutige Indizes in Mongo implementiert werden, besteht darin, dass Objekte, in denen dieses Feld fehlt, überhaupt nicht im Index enthalten sind - sie können von einer Abfrage für dieses Feld nicht abgerufen werden - {$exists: false} funktioniert einfach nicht.

Die einzige Problemumgehung, die ich gefunden habe, ist eine spezielle Null-Wertefamilie, bei der ein leerer Wert in ein spezielles Präfix (wie null:) übersetzt wird, das mit einer UUID verknüpft ist. Dies ist ein echtes Kopfzerbrechen, da man beim Schreiben/Fragen/Lesen darauf achten muss, in/aus den leeren Werten zu transformieren. Ein großes Ärgernis.

Ich habe noch nie serverseitige Javascript-Ausführung in MongoDB verwendet (es wird sowieso nicht empfohlen) und deren Zuordnung/Reduzierung hat eine schreckliche Leistung, wenn es nur einen Mongo-Knoten gibt. Aus all diesen Gründen überlege ich mir jetzt, CouchDB zu testen. Vielleicht passt es mehr zu meinem speziellen Szenario.

Übrigens, wenn jemand den Link zur jeweiligen Mongo-Ausgabe kennt, in der das Problem des spärlichen Index beschrieben wird, teilen Sie ihn bitte mit.

20
mark

Ich bin sicher, Sie können mit Mongo (besser vertraut), und ziemlich sicher, Sie können auch mit Couch.

Beide sind dokumentenorientiert (JSON-basiert), sodass es in Dokumenten keine "Spalten", sondern Felder geben würde - sie können jedoch vollständig dynamisch sein.

Beide tun es, wenn Sie sich andere Faktoren ansehen möchten, auf die Sie sich beziehen können: andere Funktionen, die Sie interessieren, Popularität usw. Google Insights, in der Tat.

Sie könnten es einfach versuchen, ich denke, Sie sollten in der Lage sein, Mongo in 5 Minuten laufen zu lassen.

4
dm.