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

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?

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

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.

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.

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.

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)

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).

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.

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.

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.

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!