MongoDB oder CouchDB - produktionsfähig?
Ich habe mich gefragt, ob mir jemand sagen kann, ob MongoDB oder CouchDB bereit sind für eine - Produktion Umwelt.
Ich schaue mir jetzt diese Speicherlösungen an (ich bevorzuge momentan MongoDB), aber diese Projekte sind noch recht jung, und deshalb sehe ich voraus, dass ich ziemlich hart arbeiten muss, um meinen Manager davon zu überzeugen, dass wir dies übernehmen sollten neue Technologie.
Was ich gerne wissen würde, ist:
Wer nutzt MongoDB oder CouchDB heute in einer Produktionsumgebung?
Wie benutzt du MongoDB/CouchDB?
Auf welche Probleme (wenn überhaupt) sind Sie gestoßen, als Sie diesen neuen Speichermechanismus eingeführt haben (und wie haben Sie sie überwunden)?
Wie sind Sie mit Migrationsproblemen umgegangen?
Haben Sie gute/schlechte Erfahrungen mit einer dieser Lösungen, die Sie teilen möchten?
Ich bin der CTO von 10gen (Entwickler von MongoDB), daher bin ich ein bisschen voreingenommen, aber ich verwalte auch einige Sites, die MongoDB in der Produktion verwenden.
businessinsider setzt Mongo seit über einem Jahr in der Produktion ein. Sie verwenden es für alles, von Benutzern und Blog-Posts bis zu jedem Bild auf der Website.
shopwiki verwendet es für einige Dinge, einschließlich Echtzeitanalysen und eine Caching-Ebene. Sie führen über 1000 Schreibvorgänge pro Sekunde in einer relativ großen Datenbank aus.
Wenn Sie zur Seite mongodb Production Deployments gehen, sehen Sie einige Leute, die mongo in der Produktion verwenden.
Wenn Sie Fragen zum Umfang oder Umfang von Produktionsbereitstellungen haben, veröffentlichen Sie diese in unserer Benutzerliste. Wir helfen Ihnen gerne weiter.
Die BBC und meebo.com verwenden CouchDB in der Produktion und einer meiner Kunden auch. Hier ist eine Liste anderer Personen, die Couch verwenden: CouchDB in the wild
Die größte Herausforderung besteht darin, Ihre Dokumente zu organisieren und nicht mehr an relationale Daten zu denken.
SourceForge benutzt MongoDB. Siehe diese Präsentation oder hier lesen .
Wir führen CouchDB als Ersatz für MySQL für unsere Shops aus (70.0000 Artikel/Shop, insgesamt 4 Millionen Attribute aller Artikel, Querverbindungen zwischen Artikeln).
Unsere Ziele waren:
Einfache Replikation von einer Master-Datenbank auf mehrere Clients mit unterschiedlichen Dokumenten.
Schnelle vorberechnete Daten wie "Wie viele Teile habe ich mit diesem Attribut und diesem Filter, passend zu diesen Bedingungen"
fakten:
- Unsere Shops laufen jetzt viel schneller als mit MySQL (und die mysql-Datenbank benötigte zusätzlich 1-3 Tage Vorberechnung (die Aktualisierung war also zweimal im Monat), sodass die Daten für die Produktzählung und -filterung bereit sind. CouchDB benötigt also 5 Stunden wir könnten Produktdaten jede Nacht aktualisieren)
- Das Einrichten (gefilterter) Datenverteilung und Backups auf den Shopknoten ist schnell und einfach
aber auch:
- Das Verstehen von Map/Reduce und der Grenzen, keine Joins zu haben, ist ziemlich schwierig
- Keine Operation auf Daten wie "Löschen wo" oder "Aktualisieren wo" ohne externe Programme
- Die Replikation funktioniert einwandfrei, es sei denn, es liegt ein Problem vor. dann ist es wirklich schwer herauszufinden, was der Grund war (für Anfänger)
- Die Installation von CouchDB ohne Binärdateien (ja, es gibt einige in freier Wildbahn, aber nicht für jedes Betriebssystem/jede Version) könnte schwierig sein, wenn Sie kein Linux-Freak sind. Aber die CouchDB-Community ist hilfreich (#couchdb), und zum Glück gibt es Unternehmen (cloudant, iriscouch), die Dienste vom kostenlosen bis zum Big Business anbieten.
- CouchDB schreitet voran, daher gibt es eine Reihe von Änderungen (Verbesserungen), die sich auf Ihre Arbeitsweise auswirken können. Aber grundlegende Dinge bleiben stabil.
Als Ergebnis: MySQL als Datenbank für die Erstellung und Pflege von Daten ist zuverlässig und einfach zu verstehen und zu handhaben. Ich denke, wir werden das nicht ändern. Aber ich möchte auch nicht auf die Leistungsfähigkeit von CouchDB-Ansichten und die einfache Einrichtung der Replikation verzichten.
Produktions-Sofas verursachten nach monatelanger Arbeit manchmal Probleme aufgrund von Fehlkonfigurationen und vergessenen Logrotaten (das Erstellen von Ansichten dauert zu lange oder hängt, die Replikation stoppt), aber es gingen nie Daten verloren und sie konnten immer leicht zurückgesetzt werden.
Ich benutze CouchDB in der Produktion. Derzeit werden alle 'optionalen' Felder gespeichert, die nicht im ursprünglichen DB-Schema enthalten waren. Und im Moment denke ich darüber nach, alle Daten in CouchDB zu verschieben.
Das ist ein ziemlich riskanter Schritt, gebe ich zu. Erstens, weil es noch nicht v1.0 ist. Und zweitens, weil es laufplatzhungrig ist. Nach meinen Berechnungen ist die CouchDB-Datei (mit Indizes) etwa 30-mal so groß wie die MySQL-Datenbank mit denselben Zeilen. Aber ich bin mir ziemlich sicher, dass es gut gehen wird.
CouchDB 0.11 (veröffentlicht Ende März) ist ein Feature-Freeze-Release für 1.0. Dies bedeutet, dass die Kompatibilität mit der aktuellen API für 1.0 erhalten bleibt. Daher ist jetzt ein guter Zeitpunkt, sich CouchDB noch einmal anzuschauen, wenn Sie dies nicht schon länger getan haben.
Die CouchDB 0.11-Quellcode-Version ist hier verfügbar. Es gibt Binär-Installer und andere hier verlinkte Goodies.
Ich weiß nichts über MongoDB, aber aus dem CouchDB FAQ :
Ist CouchDB produktionsbereit?
Ja, siehe InTheWild für eine unvollständige Liste von Projekten, die CouchDB verwenden. Ein weiterer guter Überblick ist CouchDB Case Studies
Auch einige Links:
Wir setzen couchdb in der Produktion ein und sind seit kurz vor dem Projekt unter dem Dach von Apache gefahren.
Wir verwenden es, um alles zu speichern, was wir sonst für ein DBMS verwenden könnten, sowie alle Arten von unstrukturierten Daten. Persönlich gefällt mir sehr, wie Sie einfach alle Arten von Daten hineinwerfen und die Ansichten verwenden können, um das zu ermitteln, was Sie je nach Situation nicht benötigen.
Das Schwierigste war, sich von der Denkweise von dbms zu entfernen. Wir haben unsere eigenen Migrations-Tools geschrieben, als das Speicherformat aus Sicherheitsgründen geändert wurde, sodass dies kein wirkliches Problem darstellte.
Wir haben noch keine negativen Erfahrungen gemacht, aber andererseits hatten wir das Setup noch nicht unter irgendeiner großen Last. Ich denke Dinge würden ziemlich gut funktionieren, da wir zwei Slave-Server haben, die von einem einzigen Master-Server replizieren, der alle Schreibvorgänge erhält. Ich bin mir ziemlich sicher, dass wir das nicht so machen müssen, damit die Replikation richtig funktioniert, aber so haben wir es am Anfang eingerichtet und es ist hängen geblieben.
Wir verwenden CouchDB, um eingehende und ausgehende Mobilfunknachrichten zu speichern und über einige benutzerdefinierte Ansichten, die ich geschrieben habe, über diesen Datenverkehr zu berichten. Das Frontend ist in Python geschrieben. Wir hatten keine wirklichen technischen Probleme und es läuft seit Ende Dezember. Die einzige Hürde, auf die ich stieß, war das anfängliche Denken in Bezug auf MapReduce, aber sobald ich gelernt hatte, wie man das macht, lief alles glatt.
Derzeit verwenden wir MongoDB in der Produktion als Caching-Schicht sowie als Speicher-Engine für den Produktimport und die Bearbeitung von Produktdaten. Wir sind ein E-Commerce-Unternehmen, das mehr als zwei Millionen Produkte (über 100 Millionen Attribute) verwaltet und 10 oder mehr Distributoren umfasst. Ohne MongoDB wäre diese Aufgabe nahezu unmöglich.
Wir verwenden derzeit Mongodb als Dateispeicherdienst für unsere Zusammenarbeit über LAN. Projekte wie trello verwenden außerdem mongodb als Backend-Datenspeicher. Ich habe Couchdb früher verwendet, aber nicht in Produktionskapazität.
Diese Frage hat die Antwort bereits akzeptiert, aber jetzt, in wenigen Tagen, ist NoSQL DB für viele seiner großartigen Funktionen im Trend. Es ist Couchbase; das läuft als CouchbaseLite auf der mobilen Plattform und Couchbase Server auf Ihrer Serverseite.
Hier sind einige der Hauptfunktionen von Couchbase Lite.
Couchbase Lite ist eine leichte, dokumentenorientierte (NoSQL), synchronisierbare Datenbank-Engine, die zum Einbetten in mobile Apps geeignet ist.
Leicht bedeutet:
Eingebettet: Das Datenbankmodul ist eine in die App eingebundene Bibliothek und kein separater Serverprozess. Geringe Codegröße - wichtig für mobile Apps, die häufig über Mobilfunknetze heruntergeladen werden. Schnelle Startzeit - wichtig, da mobile Geräte relativ langsame CPUs haben. Geringer Speicherverbrauch: Typische mobile Datensätze sind relativ klein, aber einige Dokumente enthalten möglicherweise große Multimedia-Anhänge. Gute Leistung - genaue Zahlen hängen natürlich von Ihren Daten und Ihrer Anwendung ab.
Dokumentorientiert heißt:
Speichert Datensätze im flexiblen JSON-Format, anstatt vordefinierte Schemas oder Normalisierung zu erfordern. Dokumente können binäre Anhänge beliebiger Größe enthalten, z. B. Multimedia-Inhalte. Das Anwendungsdatenformat kann sich im Laufe der Zeit entwickeln, ohne dass explizite Migrationen erforderlich sind. Die MapReduce-Indizierung ermöglicht eine schnelle Suche, ohne dass spezielle Abfragesprachen verwendet werden müssen.
Syncable bedeutet:
Zwei beliebige Kopien einer Datenbank können über einen effizienten, zuverlässigen und bewährten Replikationsalgorithmus synchronisiert werden. Die Synchronisierung kann bei Bedarf oder kontinuierlich erfolgen (mit einer Wartezeit von wenigen Sekunden). Geräte können mit einer Teilmenge einer großen Datenbank auf einem Remote-Server synchronisiert werden. Die Synchronisierungsengine unterstützt zeitweise und unzuverlässige Netzwerkverbindungen. Konflikte können erkannt und gelöst werden, wobei die Anwendungslogik die Zusammenführung kontrolliert. Revisionsbäume ermöglichen komplexe Replikationstopologien, einschließlich Server-zu-Server (für mehrere Rechenzentren) und Peer-zu-Peer, ohne Datenverlust oder falsche Konflikte. Couchbase Lite bietet native APIs für die nahtlose iOS Objective-C) und Android (Java) -Entwicklung. Außerdem enthält es das Couchbase Lite-Plug-in für PhoneGap, mit dem Sie iOS- und Android Apps, die Sie mit bekannten Programmiertechniken für Webanwendungen und dem Mobile Development Framework von PhoneGap entwickeln.
Weitere Informationen finden Sie unter --- (Couchbase Lite
und Couchbase Server
Das geht zur nächsten großen Sache.
Wir verwenden Mongodb in der Produktion für
www.beachfront.io - Fast 5.000 Schreibanfragen pro Sekunde. www.beachfrontbuilder.com - 500 Schreib-/Leseanfragen pro Sekunde.
Die einzige Herausforderung bei der Archivierung von Daten besteht in der Implementierung unserer benutzerdefinierten Komponente.
Adobe verwendet MongoDB für die bevorstehende Veröffentlichung von Adobe Experience Manager (früher Day CQ) als Core-DB-Engine.
Mehrere Kunden in der Agentur, bei der ich arbeite, verwenden CouchDB für Projekte für große Kunden.
Beide sind meiner Meinung nach großartige und tragfähige DBs. :)
Ich benutze CouchDB seit fast 2 Jahren in der Produktion. Es gibt keine Migrationsarbeiten, da das Projekt direkt mit der Implementierung von CouchDB gestartet wurde. Es dient als Datenbank, in der die Daten eines einzelnen elektronischen Produkts vom Anfang bis zur Verpackung gespeichert werden.
Da wir Sensoren verkaufen, die hohe Genauigkeit erfordern, führen wir viele Tests in verschiedenen Phasen durch, und all diese werden in einem Dokument auf CouchDB gespeichert.
Es gibt eine Lernkurve, die ich aus meiner Erfahrung gelernt habe, nämlich die Ansichten voll auszunutzen (oder auch als permanente Ansichten bekannt). Ansichten sollten "kleine Filter" eines Teils der Datenbank sein, die häufig aufgerufen werden.
Meine CouchDB-Datenbank ist nicht so verrückt wie andere gigantische Unternehmen. Aber bis jetzt geht es mir immer noch gut. Derzeit habe ich 24000 Dokumente bei 700 MB.
Die Funktion von CouchDB, die mir gefällt, ist "Replikation", "Überarbeitungen eines Dokuments speichern".
Ich habe viele gute Reviews auf MongoDB gelesen und ich werde es versuchen wollen, wenn es eine Chance gibt.
Wir verwenden MongoDB in der Produktion in unserem mobilen Backend-Service, nämlich Netmera. Wir verwenden es, um alle Benutzer- und Inhaltsdaten zu speichern.
Apropos Produktion, nahtloses Failover/Recovery erfordern einen Babysitter
1- Couchbase, es gibt kein nahtloses Failover/Recovery. Manuelle Eingriffe sind erforderlich.
Der Neuausgleich nimmt zu viel Zeit in Anspruch und ist zu riskant, wenn mehr als ein Knoten verloren geht.
2- Mongo mit Shards, Datenwiederherstellung nach dem Verlust eines Konfigurationsservers, ist keine leichte Aufgabe