Wenn Sie aus der MySQL-Welt kommen, wird sich MongoDB aufgrund seiner abfrageähnlichen Sprachunterstützung für Sie viel natürlicher "anfühlen".
Ich denke, das macht es für viele Menschen so freundlich.
CouchDB ist fantastisch, wenn Sie die wirklich großartige Master-Master-Replikationsunterstützung mit einem Multi-Node-Setup nutzen möchten, möglicherweise in verschiedenen Rechenzentren oder ähnlichem.
Die Replikation von MongoDB (Replikatsätze) ist ein Master-Slave-Slave-Slave- * Setup. Sie können nur in einem Replikatsatz auf den Master schreiben und von einem dieser Sätze lesen.
Für eine Standard-Site-Konfiguration ist das in Ordnung. Es ist sehr gut auf die MySQL-Nutzung abgestimmt.
Wenn Sie jedoch versuchen, einen globalen Dienst wie ein CDN zu erstellen, der alle globalen Knoten synchronisieren muss, obwohl sie alle lesen / schreiben, ist die Replikation in CouchDB ein großer Segen für Sie.
Während MongoDB eine abfrageartige Sprache hat, die Sie verwenden können und die sich sehr intuitiv anfühlt, verfolgt CouchDB einen "Kartenreduzierungs" -Ansatz und diese Konzepte von Ansichten. Es fühlt sich anfangs seltsam an, aber wenn man den Dreh raus hat, fühlt es sich wirklich intuitiv an.
Hier ist eine kurze Übersicht, damit es Sinn macht:
- CouchDB speichert alle Ihre Daten in einem B-Baum
- Sie können es nicht dynamisch mit etwas wie "SELECT * FROM user WHERE ..." "abfragen".
- Stattdessen definieren Sie diskrete "Ansichten" Ihrer Daten ... "hier ist eine Ansicht aller meiner Benutzer", "hier ist eine Ansicht aller Benutzer älter als 10" "hier ist eine Ansicht aller Benutzer älter als 30" und demnächst.
- Diese Ansichten werden mithilfe des Map-Reduce-Ansatzes definiert und als JavaScript-Funktionen definiert.
- Wenn Sie eine Ansicht definieren, beginnt die Datenbank, alle Dokumente der Datenbank, der Sie die Ansicht zugewiesen haben, durch sie zu führen und die Ergebnisse Ihrer Funktionen als "Index" für diese Daten aufzuzeichnen.
- Es gibt einige grundlegende Abfragen, die Sie in den Ansichten ausführen können, z. B. das Abfragen eines bestimmten Schlüssels (ID) oder eines ID-Bereichs, unabhängig davon, was Ihre Map / Reduce-Funktion tut.
- Lesen Sie diese Folien durch , es ist die beste Klarstellung der Karte / Verkleinerung in Couch, die ich gesehen habe.
Beide Quellen verwenden also JSON-Dokumente, aber CouchDB folgt diesem Ansatz: "Jeder Server ist ein Master und kann mit der Welt synchronisieren". Dieser Ansatz ist fantastisch, wenn Sie ihn benötigen, während MongoDB wirklich das MySQL der NoSQL-Welt ist.
Also, wenn das eher nach dem klingt, was Sie brauchen / wollen, dann machen Sie das.
Kleine Unterschiede wie das Binärprotokoll von Mongo gegenüber der RESTful-Schnittstelle von CouchDB sind nur geringfügige Details.
Wenn Sie rohe Geschwindigkeit und Hölle mit Datensicherheit wollen, können Sie Mongo schneller als CouchDB laufen lassen , da Sie ihm sagen können, dass er nicht über genügend Arbeitsspeicher verfügt und keine Daten auf die Festplatte überträgt, außer in spärlichen Intervallen.
Sie können dasselbe mit Couch tun, aber das HTTP-basierte Kommunikationsprotokoll wird in dieser "Geschwindigkeit über alles" 2-4x langsamer sein als die rohe binäre Kommunikation mit Mongo! Szenario.
Denken Sie daran, dass verrückte verrückte Geschwindigkeit nutzlos ist, wenn ein Serverabsturz oder ein Festplattenfehler Ihre Datenbank beschädigt und in Vergessenheit gerät, sodass der Datenpunkt nicht so erstaunlich ist, wie es scheint (es sei denn, Sie betreiben Echtzeit-Handelssysteme an der Wand) Straße, in diesem Fall schauen Sie sich Redis an).
Hoffe das alles hilft!