MongoDB oder CouchDB - fit für die Produktion? [geschlossen]

Ich habe mich gefragt, ob mir jemand sagen kann, ob MongoDB oder CouchDB für eine Produktionsumgebung bereit sind.

Ich schaue mir jetzt diese Speicherlösungen an (ich bevorzuge derzeit MongoDB), aber diese Projekte sind noch recht jung und ich gehe davon aus, 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:

1. Wer verwendet MongoDB oder CouchDB heute in einer Produktionsumgebung?

2. Wie benutzt man MongoDB / CouchDB?

3. Auf welche Probleme (falls vorhanden) sind Sie bei der Einführung dieses neuen Speichermechanismus gestoßen (und wie haben Sie diese überwunden)?

4. Wie sind Sie mit Migrationsproblemen umgegangen, mit denen Sie sich befassen mussten?

5. 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 etwas voreingenommen, aber ich verwalte auch einige Websites, 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 einer Caching-Ebene. Sie schreiben über 1000 Mal pro Sekunde in eine ziemlich große Datenbank.

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, schreiben Sie diese in unsere Benutzerliste. Wir helfen Ihnen gerne weiter.

Die BBC und meebo.com verwenden CouchDB in der Produktion, ebenso einer meiner Kunden. Hier ist eine Liste anderer Benutzer von Couch: CouchDB in freier Wildbahn

Die größte Herausforderung besteht darin, zu wissen, wie Sie Ihre Dokumente organisieren und nicht mehr an relationale Daten denken.

SourceForge verwendet MongoDB. Sehen Sie diese Präsentation oder lesen Sie hier .

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:

1. Einfache Replikation von einer Master-Datenbank auf mehrere Clients mit unterschiedlichen Dokumenten.

2. Schnelle vorberechnete Daten wie "Wie viele Teile habe ich mit diesem Attribut und diesem Filter, passend zu diesen Bedingungen?"

Fakten:

1. Unsere Shops laufen jetzt viel schneller als mit MySQL (und die MySQL-Datenbank benötigte zusätzlich 1-3 Tage Vorberechnung (die Aktualisierung erfolgte 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 die Produktdaten jede Nacht aktualisieren)
2. Das Einrichten (gefilterter) Datenverteilung und Sicherungen auf den Shop-Knoten ist schnell und einfach

aber auch:

1. Das Verständnis von Map / Reduce und den Grenzen, keine Joins zu haben, ist ziemlich schwierig
2. Keine Operation für Daten wie "Löschen wo" oder "Aktualisieren wo" ohne externe Programme
3. Die Replikation funktioniert gut, es sei denn, es liegt ein Problem vor. dann ist es wirklich schwer herauszufinden, was der Grund war (für Anfänger)
4. 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-Geek sind. Aber die CouchDB-Community ist hilfreich (#couchdb), und zum Glück gibt es Unternehmen (Cloudant, Iriscouch), die Dienstleistungen von kostenlos bis groß anbieten.
5. CouchDB ist auf dem Vormarsch, daher gibt es viele Änderungen (Verbesserungen), die Ihre Arbeitsweise ändern könnten. 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. Ich möchte aber auch nicht auf die Leistungsfähigkeit von CouchDB-Ansichten und die einfache Einrichtung der Replikation verzichten.

Produktions-Couches verursachten nach monatelanger Arbeit manchmal Probleme aufgrund von Fehlkonfigurationen und vergessenen Protokollierungen (das Erstellen von Ansichten dauert zu lange oder hängt, Replikationsstopps), verloren jedoch nie Daten und 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 nach CouchDB zu verschieben.

Ich gebe zu, es ist ein ziemlich riskanter Schritt. Erstens, weil es noch nicht v1.0 ist. Und zweitens, weil es Drive-Space-hungrig ist. Nach meinen Berechnungen ist die CouchDB-Datei (mit Indizes) etwa 30-mal größer als 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 eine Feature-Freeze-Version für 1.0. Dies bedeutet, dass wir die Kompatibilität mit der aktuellen API für 1.0 beibehalten. Daher ist jetzt ein guter Zeitpunkt, um CouchDB erneut zu betrachten, wenn Sie dies schon länger nicht mehr getan haben.

Die Version des CouchDB 0.11-Quellcodes finden Sie hier. Es gibt binäre Installer und andere Extras, die hier verlinkt sind.

Ich weiß nichts über MongoDB, aber aus den CouchDB-FAQ :

Ist CouchDB produktionsbereit?

Ja, unter InTheWild finden Sie eine unvollständige Liste der Projekte, die CouchDB verwenden. Ein weiterer guter Überblick sind CouchDB-Fallstudien

Auch einige Links:

• Betreff: Aktueller CouchDB-Status?
• SimpleDB, CouchDB und andere "NEUE" Datenspeicher - Feedback

Wir verwenden Couchdb in der Produktion und haben seitdem kurz bevor das Projekt unter dem Dach von Apache stand.

Wir verwenden es, um alles zu speichern, was wir sonst für eine Datenbank 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 dbms-Denkweise zu entfernen. Wir haben unsere eigenen Migrations-Utils geschrieben, als sich das Speicherformat aus Sicherheitsgründen geändert hat. Das war also kein wirkliches Problem.

Wir haben noch keine negativen Erfahrungen gemacht, aber andererseits hatten wir das Setup unter keiner großen Last. Ich denke, die 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 es nicht so machen müssen, damit die Replikation richtig funktioniert, aber so haben wir es am Anfang eingerichtet und es ist geblieben.

Wir verwenden CouchDB, um eingehende und ausgehende mobile Nachrichten zu speichern und diesen Datenverkehr über einige von mir geschriebene benutzerdefinierte Ansichten zu melden. 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 zunächst das Denken in MapReduce, aber als ich das gelernt hatte, verlief alles reibungslos.

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 über zwei Millionen Produkte (über 100 Millionen Attribute) verwaltet und über 10 Distributoren umfasst. Ohne MongoDB wäre diese Aufgabe nahezu unmöglich.

Wir verwenden derzeit Mongodb als Dateispeicherdienst für unsere Zusammenarbeit über LAN. Außerdem verwenden Projekte wie trello mongodb als Backend-Datenspeicher. Ich habe Couchdb früher verwendet, aber nicht in der Produktionskapazität.

Wir verwenden MongoDB in der Produktion in unserem mobilen Backend-Service, nämlich Netmera. Wir verwenden es, um alle Benutzer- und Inhaltsdaten zu speichern.

Ich benutze CouchDB seit fast 2 Jahren in der Produktion. Es gibt keine Migrationsarbeit, da das Projekt direkt mit der CouchDB-Implementierung gestartet wurde. Es dient als Datenbank, in der die Daten eines einzelnen elektronischen Produkts von Anfang bis zur Verpackung gespeichert werden.

Da wir Sensoren mit der Forderung nach hoher Genauigkeit verkaufen, führen wir viele Tests in verschiedenen Phasen durch und alle 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 bezeichnet). Ansichten sollten "kleine Filter" eines Bruchteils der Datenbank sein, der häufig aufgerufen wird.

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 mit 700 MB.

Das Feature von CouchDB, das mir gefällt, ist "Replikation", "Revisionen eines Dokuments speichern".

Ich habe viele gute Rezensionen zu MongoDB gelesen und werde es versuchen wollen, wenn es eine Chance gibt.

Wir verwenden Mongodb in der Produktion für

www.beachfront.io - Nahezu 5.000 Schreibanforderungen pro Sekunde www.beachfrontbuilder.com - 500 Lese- / Schreibanforderungen pro Sekunde, 10 Millionen Benutzerdaten und Olap verwalten.

Die einzige Herausforderung bei der Archivierung von Daten besteht darin, dass wir unsere benutzerdefinierte Komponente implementieren.

Diese Frage wurde bereits beantwortet, aber jetzt ist ein Tag später eine weitere NoSQL- Datenbank für viele ihrer großartigen Funktionen im Trend. Es ist Couchbase; Das läuft wie CouchbaseLiteauf der mobilen Plattform und Couchbase Serverauf 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 mit der App verknüpfte Bibliothek und kein separater Serverprozess. Kleine 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. Geringe Speichernutzung - Typische mobile Datensätze sind relativ klein, aber einige Dokumente verfügen möglicherweise über große Multimedia-Anhänge. Gute Leistung - genaue Zahlen hängen natürlich von Ihren Daten und Ihrer Anwendung ab.

Dokumentorientiert bedeutet:

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 ändern, ohne dass explizite Migrationen erforderlich sind. Die MapReduce-Indizierung bietet schnelle Suchvorgänge, ohne dass spezielle Abfragesprachen verwendet werden müssen.

Synchronisierbar 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 Latenz von einigen Sekunden). Geräte können mit einer Teilmenge einer großen Datenbank auf einem Remote-Server synchronisiert werden. Die Sync-Engine unterstützt intermittierende und unzuverlässige Netzwerkverbindungen. Konflikte können erkannt und gelöst werden, wobei die App-Logik die vollständige Kontrolle über das Zusammenführen hat. Revisionsbäume ermöglichen komplexe Replikationstopologien, einschließlich Server-zu-Server (für mehrere Rechenzentren) und Peer-to-Peer, ohne Datenverlust oder falsche Konflikte. Couchbase Lite bietet native APIs für die nahtlose Entwicklung von iOS (Objective-C) und Android (Java). Darüber hinaus enthält es das Couchbase Lite-Plug-In für PhoneGap,

Weitere Informationen finden Sie auf Couchbase Lite

und Couchbase Server

Dies geht zur nächsten großen Sache.

Apropos Produktion, nahtloses Failover / Wiederherstellung erfordern beide einen Babysitter
1- Couchbase, es gibt kein nahtloses Failover / Wiederherstellung, manuelle Eingriffe sind erforderlich.
Das Neuausgleichen kostet zu viel Zeit und zu viel Risiko, wenn mehr als ein Knoten verloren geht.

2- Mongo mit Shards, Datenwiederherstellung nach dem Verlust eines Konfigurationsservers, ist keine leichte Aufgabe

Adobe verwendet MongoDB für die bevorstehende Veröffentlichung von Adobe Experience Manager (ehemals Day CQ ) als Kern-DB-Engine.

Mehrere Kunden der Agentur, bei der ich arbeite, verwenden CouchDB für Projekte für Großkunden.

Beide sind meiner Meinung nach großartige und tragfähige DBs. :) :)

Hier ist eine Liste der mit mongoDB bereitgestellten Produktionsstandorte

• The New Yorks Times : Verwendung in einer Formularerstellungsanwendung für die Einreichung von Fotos. Das fehlende Schema von Mongo gibt Produzenten die Möglichkeit, eine beliebige Kombination von benutzerdefinierten Formularfeldern zu definieren.
• SourceForge : Wird für den Back-End-Speicher auf den SourceForge-Startseiten, Projektseiten und Downloadseiten für alle Projekte verwendet.
• Bit.ly
• Etsy
• IGN : Unterstützt die Echtzeit-Verkehrsanalyse und die RESTful Content-APIs von IGN.
• Justin.tv : Unterstützt die internen Analysetools von Justin.tv für Viralität, Benutzerbindung und allgemeine Nutzungsstatistiken, die Out-of-the-Box-Lösungen nicht bieten können.
• Posterous
• Intuit
• Foursquare : Sharded Mongo-Datenbanken werden für die meisten Daten auf foursquare verwendet.
• Business Insider : Verwendung seit Anfang 2008. Alle Daten der Website, einschließlich Posts, Kommentare und sogar Bilder, werden in MongoDB gespeichert.
• Github : wird für eine interne Berichtsanwendung verwendet.
• Prüfer : Die Site wurde von Cold Fusion und SQL Server auf Drupal 7 und MongoDB migriert.
• Grooveshark : Verwendet derzeit Mongo, um über eine Million eindeutige Benutzersitzungen pro Tag zu verwalten.
• Buzzfeed
• Diskus
• Evite : Wird für Analysen und schnelle Berichte verwendet.
• Platz
• Shutterfly : Wird für verschiedene dauerhafte Datenspeicheranforderungen in Shutterfly verwendet. MongoDB hilft Shutterfly dabei, einen konkurrenzlosen Service aufzubauen, der tiefere, persönlichere Beziehungen zwischen Kunden und denen ermöglicht, die in ihrem Leben am wichtigsten sind.
• Auf den Kopf gestellt
• Teile das
• Mongohq : bietet eine Hosting-Plattform für MongoDB und verwendet MongoDB auch als Back-End für seinen Service. Auf unserer Seite für Hosting-Center finden Sie weitere Informationen zu MongoHQ und anderen Hosting-Optionen für MongoDB.

und mehr...

Auszug aus: http://lineofthought.com/tools/mongodb

Dort können Sie auch andere Datenbanken oder Tools überprüfen.

MongoDB hat einige Probleme mit der Lizenzierung an Unternehmen. Ich bin mir der Details nicht sicher, aber unsere Rechtsabteilung hat uns ohne bestimmte Bedingungen mitgeteilt, dass wir MongoDB in keinem unserer Produkte verwenden dürfen.