Wann sollte MongoDB oder andere dokumentenorientierte Datenbanksysteme verwendet werden? [geschlossen]

516

Wir bieten eine Plattform für Video- und Audioclips, Fotos und Vektorgrafiken. Wir haben mit MySQL als Datenbank-Backend begonnen und kürzlich MongoDB zum Speichern aller Metainformationen der Dateien hinzugefügt, da MongoDB den Anforderungen besser entspricht. Beispiel: Fotos enthalten möglicherweise Exif- Informationen, Videos enthalten möglicherweise Audiospuren, in denen auch die Metainformationen gespeichert werden sollen. Videos und Vektorgrafiken teilen keine gemeinsamen Metainformationen usw. Ich weiß also, dass MongoDB perfekt ist, um diese unstrukturierten Daten zu speichern und durchsuchbar zu halten.

Wir entwickeln unsere Plattform jedoch weiter und fügen Funktionen hinzu. Einer der nächsten Schritte ist nun die Bereitstellung eines Forums für unsere Benutzer. Die Frage, die sich jetzt stellt, lautet: Verwenden Sie die MySQL-Datenbank, die eine gute Wahl zum Speichern von Foren und Forenbeiträgen usw. ist, oder verwenden Sie MongoDB auch dafür?

Die Frage ist also: wann MongoDB und wann ein RDBMS verwendet werden soll. Was würden Sie nehmen, MongoDB oder MySQL, wenn Sie die Wahl hätten und warum würden Sie es nehmen?

Aurora
quelle
12
Ich bin mir nicht sicher, warum dies als meinungsbasiert markiert ist, wenn dies eindeutig nicht der Fall ist. Hier gibt es eine klare richtige oder falsche Antwort.
Spencer

Antworten:

659

In NoSQL: Wenn es nur so einfach wäre , schreibt der Autor über MongoDB:

MongoDB ist kein Schlüssel- / Wertspeicher, es ist viel mehr. Es ist definitiv auch kein RDBMS. Ich habe MongoDB nicht in der Produktion verwendet, aber ich habe es ein wenig verwendet, um eine Test-App zu erstellen, und es ist ein sehr cooles Teil des Kits. Es scheint sehr performant zu sein und hat oder wird bald Fehlertoleranz und Auto-Sharding haben (auch bekannt als Skalierung). Ich denke, Mongo könnte einem RDBMS-Ersatz, den ich bisher gesehen habe, am nächsten kommen. Es funktioniert nicht für alle Datensätze und Zugriffsmuster, ist jedoch für typische CRUD-Inhalte konzipiert. Das Speichern eines im Wesentlichen riesigen Hashs und das Auswählen eines dieser Schlüssel ist das, wofür die meisten Benutzer eine relationale Datenbank verwenden.Wenn Ihre Datenbank 3NF ist und Sie keine Verknüpfungen durchführen (Sie wählen nur eine Reihe von Tabellen aus und fügen alle Objekte zusammen, AKA, was die meisten Leute in einer Web-App tun), würde MongoDB wahrscheinlich für Sie in den Arsch treten.

Dann zum Schluss:

Die wirkliche Sache, auf die Sie hinweisen sollten, ist, dass Sie etwas falsch machen, wenn Sie davon abgehalten werden, etwas Super-Tolles zu machen, weil Sie keine Datenbank auswählen können. Wenn Sie MySQL kennen, verwenden Sie es einfach. Optimieren Sie, wann Sie es tatsächlich brauchen. Verwenden Sie es wie einen Ak / V-Store, verwenden Sie es wie einen RDBMS, aber um Himmels willen, erstellen Sie Ihre Killer-App! Nichts davon wird für die meisten Apps von Bedeutung sein. Facebook verwendet immer noch viel MySQL. Wikipedia verwendet häufig MySQL. FriendFeed verwendet häufig MySQL. NoSQL ist ein großartiges Tool, aber es wird sicherlich nicht Ihr Wettbewerbsvorteil sein, es wird Ihre App nicht heiß machen, und vor allem werden sich Ihre Benutzer nicht darum kümmern.

Worauf werde ich meine nächste App aufbauen? Wahrscheinlich Postgres. Werde ich NoSQL verwenden? Könnte sein. Ich könnte auch Hadoop und Hive verwenden. Ich könnte alles in flachen Dateien aufbewahren. Vielleicht fange ich an, Maglev zu hacken. Ich werde alles verwenden, was für den Job am besten ist. Wenn ich Bericht erstatten muss, verwende ich kein NoSQL. Wenn ich Caching brauche, werde ich wahrscheinlich Tokyo Tyrant verwenden. Wenn ich ACIDity benötige, verwende ich NoSQL nicht. Wenn ich eine Menge Zähler brauche, benutze ich Redis. Wenn ich Transaktionen benötige, verwende ich Postgres. Wenn ich eine Tonne eines einzigen Dokumententyps habe, werde ich wahrscheinlich Mongo verwenden. Wenn ich 1 Milliarde Objekte pro Tag schreiben muss, würde ich wahrscheinlich Voldemort verwenden. Wenn ich eine Volltextsuche benötige, würde ich wahrscheinlich Solr verwenden. Wenn ich eine Volltextsuche nach flüchtigen Daten benötige, würde ich wahrscheinlich Sphinx verwenden.

Ich mag diesen Artikel, ich finde ihn sehr informativ, er gibt einen guten Überblick über die NoSQL-Landschaft und den Hype. Aber, und das ist der wichtigste Teil, es ist wirklich hilfreich, sich die richtigen Fragen zu stellen, wenn Sie zwischen RDBMS und NoSQL wählen. Lohnt sich meiner Meinung nach zu lesen.

Alternativer Link zum Artikel

Pascal Thivent
quelle
4
Danke, es ist in der Tat ein sehr interessanter Artikel.
Aurora
48
@iddqd ROFL! Mann, das war komisch. "Wenn Sie dumm genug sind, die Zuverlässigkeit völlig zu ignorieren, nur um Benchmarks zu erhalten, schlage ich vor, dass Sie Ihre Daten an/dev/null
weiterleiten
3
Danke für die hype-bewusste Antwort.
Deamon
2
Hoffentlich wird BJ Clark nicht alle diese Technologien im selben Projekt verwenden. Das wäre eine Art Lernkurve.
Adam Monsen
186

Nach zwei Jahren mit MongoDb für eine soziale App habe ich gesehen, was es wirklich bedeutet, ohne SQL RDBMS zu leben.

  1. Am Ende schreiben Sie Jobs, um beispielsweise Daten aus verschiedenen Tabellen / Sammlungen zusammenzufügen, was ein RDBMS automatisch für Sie tun würde.
  2. Ihre Abfragefunktionen mit NoSQL sind drastisch beeinträchtigt. MongoDb ist vielleicht das, was SQL am nächsten kommt, aber es liegt immer noch extrem weit zurück. Vertrau mir. SQL-Abfragen sind sehr intuitiv, flexibel und leistungsstark. MongoDb-Abfragen sind nicht.
  3. MongoDb-Abfragen können Daten aus nur einer Sammlung abrufen und nur einen Index nutzen. Und MongoDb ist wahrscheinlich eine der flexibelsten NoSQL-Datenbanken. In vielen Szenarien bedeutet dies mehr Roundtrips zum Server, um verwandte Datensätze zu finden. Und dann beginnen Sie mit der De-Normalisierung von Daten - was Hintergrundjobs bedeutet.
  4. Die Tatsache, dass es sich nicht um eine relationale Datenbank handelt, bedeutet, dass Sie keine Fremdschlüsseleinschränkungen haben (von einigen als schlecht angesehen), um sicherzustellen, dass Ihre Daten konsistent sind. Ich versichere Ihnen, dass dies letztendlich zu Dateninkonsistenzen in Ihrer Datenbank führen wird. Sei vorbereitet. Höchstwahrscheinlich beginnen Sie mit dem Schreiben von Prozessen oder Überprüfungen, um Ihre Datenbank konsistent zu halten. Dies ist wahrscheinlich nicht besser, als wenn das RDBMS dies für Sie erledigt.
  5. Vergessen Sie ausgereifte Frameworks wie den Ruhezustand.

Ich glaube, dass 98% aller Projekte mit einem typischen SQL-RDBMS wahrscheinlich viel besser sind als mit NoSQL.

Marquez
quelle
10
interessante Gedanken ...
luigi7up
3
Auf der anderen Seite sollten Abfragefunktionen und die von Ihnen beschriebenen Verknüpfungen kein Problem darstellen: Wenn Sie MongoDB verwenden, müssen Sie noch einige Aufgaben erledigen, um Ihre Sammlungen und die darin enthaltenen Daten zu entwerfen, damit Sie keine komplexen Daten benötigen JOINs und so weiter. Auf jeden Fall sind DBs kein Engpass und es gibt Problemumgehungen wie Memcache für einige Anwendungsfälle. Wenn Sie jedoch bei Null anfangen, werden Sie feststellen, dass das Entwerfen und Verwenden von MongoDB einfacher und schneller ist (als Entwickler, der mit Objektcode arbeitet, benötige ich kein ORM). Sicher müssen Sie ein paar Skripte schreiben, aber eigentlich ist es nicht so schwer und Sie verwenden Code wieder
Aki
1
Die meisten Leute werden NoSQL-Datenbanken nicht für den spezifischen Anwendungsfall verwenden, für den sie erstellt wurden, und danach so viele Räder neu erfinden. Die Debatte zwischen NoSQL und SQL zeigt, dass viele Menschen die Erfahrung mit NoSQL so machen, als würden sie 20 bis 30 Jahre zurückgehen, zu Zeiten vor dem Codieren, vor dem Relationalismus und vor dem SQL . Oder, wie Michael Stonebraker es ausdrückt: "Was herumgeht, kommt herum"
Lukas Eder
1
Ist Punkt 3 "und nutzen Sie nur einen Index" heute noch gültig? Ich steige gerade in MongoDB ein und es scheint, dass das, was ich bisher gelesen / angesehen habe, mehrere Indizes unterstützen kann?
Jeach
1
@Jeach: Nein, # 3 ist nicht mehr wahr. MongoDB 2.6 führte die Indexkreuzung ein .
Rob Garrison
26

um diese unstrukturierten Daten zu speichern

Wie Sie sagten, eignet sich MongoDB am besten zum Speichern unstrukturierter Daten. Und dies kann Ihre Daten im Dokumentformat organisieren. Diese als NoSQL- Datenspeicher bezeichneten RDBMS-Alternativen ( MongoDB , CouchDB , Voldemort ) sind sehr nützlich für Anwendungen, die massiv skaliert werden und einen schnelleren Datenzugriff aus diesen großen Datenspeichern erfordern.

Die Implementierung dieser Datenbanken ist einfacher als das reguläre RDBMS. Da es sich um einfache binäre Objekte mit Schlüsselwerten oder Dokumentenstil handelt, die direkt auf die Festplatte serialisiert werden. Diese Datenspeicher erzwingen weder die ACID-Eigenschaften noch Schemata . Dies bietet keine Transaktionsfähigkeiten . Dies kann also groß skaliert werden und wir können einen schnelleren Zugriff (sowohl Lesen als auch Schreiben) erzielen.

Im Gegensatz dazu erzwingt RDBM ACID und Schemas für Daten. Wenn Sie mit strukturierten Daten arbeiten möchten, können Sie mit RDBM fortfahren.

Ich würde MySQL wählen, um Foren für diese Art von Sachen zu erstellen . Weil dies nicht groß skalieren wird. Und dies ist eine sehr einfache (übliche) Anwendung, die strukturierte Beziehungen zwischen den Daten aufweist.

RameshVel
quelle
10
"Ich würde MySQL wählen, um Foren zu erstellen." "Ja wirklich?" Ich denke, Dinge wie Foren wären mit einer dokumentenorientierten Datenbank viel einfacher zu schreiben als mit einer relationalen (wenn Sie sie von Grund auf neu schreiben würden). Wenn Sie die Funktionen eines RDBMS nicht speziell benötigen, empfehlen wir MongoDB oder eine ähnliche Datenbank, um die Verwendung und Skalierung zu vereinfachen.
Sasha Chedygov
2
CouchDB unterstützt ACID. couchdb.apache.org/docs/overview.html
Sonia
2018: MongoDB hat auch ACID-Unterstützung
Nepoxx
10

Beachten Sie, dass Mongo im Wesentlichen JSON speichert. Wenn Ihre App mit vielen JS-Objekten (mit Verschachtelung) zu tun hat und Sie diese Objekte beibehalten möchten, gibt es ein sehr starkes Argument für die Verwendung von Mongo. Dadurch werden Ihre DAL- und MVC-Ebenen ultradünn, da sie nicht alle JS-Objekteigenschaften entpacken und versuchen, sie zwangsweise in eine Struktur (Schema) einzupassen, in die sie natürlich nicht passen.

Wir haben ein System, das mehrere komplexe JS-Objekte im Herzen hat, und wir lieben Mongo, weil wir alles wirklich, wirklich einfach beibehalten können. Unsere Objekte sind auch ziemlich amorph und unstrukturiert, und Mongo nimmt diese Komplikation auf, ohne zu blinken. Wir haben eine benutzerdefinierte Berichtsschicht, die die amorphen Daten für den menschlichen Verzehr entschlüsselt, und die nicht so schwer zu entwickeln war.

Geselle
quelle
7

Ich würde sagen, verwenden Sie ein RDBMS, wenn Sie komplexe Transaktionen benötigen. Ansonsten würde ich mich für MongoDB entscheiden - flexibler zu arbeiten und Sie wissen, dass es skaliert werden kann, wenn Sie es brauchen. (Ich bin allerdings voreingenommen - ich arbeite am MongoDB-Projekt)

mdirolf
quelle
7
Komplexe Transaktionen funktionieren in MongoDB nicht, aber in anderen NoSQL-Datenbanken wie MarkLogic (ich bin auch voreingenommen, da ich die Entwickler-Community für MarkLogic betreibe).
Eric Bloch
Vielen Dank für den Hinweis an MarkLogic - ich wusste es nicht.
Aurora
Ich würde gerne von mdirolf darüber hören. Warum hat MongoDB beschlossen, keine Transaktionen zu implementieren?
Aki
7

Wer braucht verteilte, gespaltene Foren? Vielleicht Facebook, aber wenn Sie keinen Facebook-Konkurrenten erstellen, verwenden Sie einfach MySQL, Postgres oder was auch immer Sie am besten mögen. Wenn Sie MongoDB ausprobieren möchten, ok, aber erwarten Sie nicht, dass es für Sie zaubert. Es wird seine Macken und seine allgemeine Gemeinheit haben, genau wie alles andere, wie Sie sicher bereits entdeckt haben, wenn Sie wirklich schon daran gearbeitet haben.

Sicher, MongoDB mag hochgespielt sein und auf den ersten Blick einfach erscheinen, aber Sie werden auf Probleme stoßen, die ausgereiftere Produkte bereits überwunden haben. Lassen Sie sich nicht so leicht anlocken, sondern warten Sie, bis "nosql" reift oder stirbt.

Persönlich denke ich, dass "nosql" verdorren und an der Fragmentierung sterben wird, da es keine festgelegten Standards gibt (fast per Definition). Ich werde also bei langfristigen Projekten nicht persönlich darauf wetten.

Das einzige, was "nosql" in meinem Buch speichern kann, ist, wenn es sich nahtlos in Ruby oder ähnliche Sprachen integrieren lässt und die Sprache "persistent" macht, fast ohne zusätzlichen Aufwand für Codierung und Design. Das mag passieren, aber ich werde bis dahin warten, nicht jetzt, UND es muss natürlich reifer sein.

Übrigens, warum erstellen Sie ein Forum von Grund auf neu? Es gibt unzählige Open-Source-Foren, die an die meisten Anforderungen angepasst werden können, es sei denn, Sie erstellen wirklich The Next Generation of Forums (was ich bezweifle).

Fred
quelle
5
Danke für deine Antwort. Die Integration eines Forums ist ein Chaos - wir haben dies bereits getan und beschlossen, diesen Weg nicht noch einmal zu gehen: Wir benötigen nicht Tausende von Funktionen, sondern eine vollständige Integration in unsere Software.
Aurora
4

Ich habe gesehen, dass viele Unternehmen MongoDB für Echtzeitanalysen aus Anwendungsprotokollen verwenden. Die Schemafreiheit passt wirklich zu Anwendungsprotokollen, bei denen sich das Datensatzschema von Zeit zu Zeit ändert. Auch seine Capped Collection ist außerdem nützlich, da alte Daten automatisch gelöscht werden, damit die Daten in den Speicher passen.

Das ist ein Bereich, für den MongoDB meiner Meinung nach wirklich geeignet ist, aber MySQL / PostgreSQL wird im Allgemeinen eher empfohlen. Es gibt viele Dokumentationen und Entwicklerressourcen im Web sowie deren Funktionalität und Robustheit.

Kazuki Ohta
quelle
4

Die 2 Hauptgründe, warum Sie Mongo bevorzugen möchten, sind

  • Flexibilität beim Schemaentwurf (Dokumentenspeicher vom Typ JSON).
  • Skalierbarkeit - Addieren Sie einfach Knoten und die horizontale Skalierung ist recht gut.

Es ist für Big-Data-Anwendungen geeignet. RDBMS ist nicht gut für Big Data.

Sushant Gupta
quelle
3

Wissen Sie, all diese Dinge über die Joins und die "komplexen Transaktionen" - aber es war Monty selbst, der vor vielen Jahren die "Notwendigkeit" für COMMIT / ROLLBACK erklärte und sagte, dass "alles, was in den Logikklassen gemacht wird" (und nicht die Datenbank) sowieso '- also ist es wieder dasselbe. Was benötigt wird, ist eine dumme, aber unglaublich aufgeräumte und schnelle Datenspeicher- / Abruf-Engine, die 99% der Leistung der Web-Apps erbringt.

FYA
quelle
Vielen Dank, Sie sprechen hier einen interessanten Punkt an. Ich würde mich wirklich für Montys Erklärung interessieren, da ich nicht sicher bin, wie komplex Rollbacks von Updates über mehrere Tabellen in der reinen Anwendungslogik werden - ich bin mir nicht sicher, ob dies wirklich möglich ist?
Aurora
Ich bin mir auch nicht sicher, wie ich es am besten kann. Wir haben immer nur alles verfolgt, was mit der Datenbank gemacht wurde, und es dann entweder auf Anwendungsebene im Code zugelassen oder rückgängig gemacht. Wir haben uns nie auf Transaktionen verlassen, nirgendwo und nie. Mongo-Dokumente schlagen vor, Metadaten zu verwenden, um zu verfolgen, welche Teile der rollbackbaren Transaktion aufgetreten sind, in welchem ​​Status sich die Transaktion befindet, falls sie unterbrochen wird und zurückgesetzt werden muss. Das Komische ist, dass wir das schon zusammen mit MySQL und anderen gemacht haben. Es ist nicht viel mehr Arbeit und es konzentriert sich darauf, was wann, wo und warum los ist, anstatt es schwarz zu boxen.
FYA
Irgendwo auf der 10gen-Website gibt es einen Hinweis darauf, wie 'Interlock'-Felder oder' Ratschen 'manuell verwendet werden, um den Status eines mehrstufigen Prozesses anzuzeigen. Mir scheint, wenn Sie in die MySQL-Engine selbst hineinzoomen, wird die "Blocktransaktion" immer noch auf eine Reihe von Schritten ausgeweitet, egal was passiert. Es ist nur so, dass die Verriegelungen oder Ratschen viel kleiner und schneller ausgeführt werden als die manuelle Verfolgung in Datenbankfeldern.
FYA
Wir haben noch keinen guten Weg gefunden, um den MongoDB-Daemon einzuschränken - er verschlingt fast den gesamten verfügbaren RAM für seinen Index und die Datenspeicherung im Speicher, liefert jedoch schnell Speicher, wenn andere Prozesse ihn benötigen. Trotzdem wäre es schön, ein 'use_max_memory' oder andere leicht definierbare Limits zu haben, um sicherzustellen, dass MongoDB nicht wegläuft und den Server in Swap-Thrashing versetzt (wir haben dies mehrmals gesehen, sogar in der neuesten Version). Zumindest MySQL akzeptiert alle Arten von definierbaren Grenzwerten und Betriebshinweisen.
FYA
Nicht direkt verwandt, aber irgendwie: Wir haben memcached verwendet, haben es aber aufgrund des noch ungelösten Fiaskos des Memcache / Memcached PHP-Treibers aufgegeben. Wir haben MongoDB als schnellen, temporären Schlüssel verwendet: val store (für den es großartig funktioniert hat!), Bis wir herausgefunden haben, wie schnell und einfach apc_store () ist. Wenn wir feststellen, dass sich APC mit temporärem Rohöl (im Vergleich zu gespeichertem vorkompiliertem PHP) füllt, das wir zum Speichern in memcached verwendet haben, kehren wir zu MongoDB zurück, um den Schlüssel zu speichern: val.
FYA
1

Wie bereits erwähnt, können Sie zwischen vielen Optionen wählen. Sehen Sie sich all diese Optionen an: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Ich schlage vor, die beste Kombination zu finden: MySQL + Memcache ist wirklich großartig, wenn Sie ACID benötigen und einige Tabellen verbinden möchten. MongoDB + Redis ist perfekt für den Dokumentenspeicher. Neo4J ist perfekt für die Grafikdatenbank

Was ich mache: Ich beginne mit MySQl + Memcache, weil ich es gewohnt bin, und beginne dann mit der Verwendung eines anderen Datenbank-Frameworks. In einem einzigen Projekt können Sie beispielsweise MySQL und MongoDB kombinieren!

Adrien Hadj-Salah
quelle
MySQL + memcached gibt Ihnen eventuelle Konsistenz. Was ich in einem RDMB-Kontext nicht als ACID betrachte.
R. van Twisk