it-swarm.com.de

Wann sollte MongoDB oder ein anderes dokumentenorientiertes Datenbanksystem verwendet werden?

Wir bieten eine Plattform für Video- und Audio-Clips, 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 die Anforderungen besser erfüllt. Zum Beispiel: Fotos können Exif Informationen enthalten, Videos können Audio-Tracks enthalten, in denen auch die Meta-Informationen von gespeichert werden sollen. Videos und Vektorgrafiken haben keine gemeinsamen Metainformationen usw., daher weiß ich, 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. Jetzt wird einer der nächsten Schritte ein Forum für unsere Benutzer sein. Die Frage, die sich jetzt stellt, ist: 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 zu verwenden ist. Was würdest du nehmen, MongoDB oder MySQL, wenn du die Wahl hättest und warum würdest du es nehmen?

504
aurora

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

MongoDB ist kein Schlüssel-/Wertspeicher, sondern 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 (auch bekannt als skalierbar). Ich denke, Mongo ist möglicherweise der nächste RDBMS-Ersatz, den ich bisher gesehen habe. Es funktioniert nicht für alle Datensätze und Zugriffsmuster, ist jedoch für Ihre typischen CRUD-Aufgaben ausgelegt. Die meisten Leute verwenden eine relationale Datenbank, um zu speichern, was im Wesentlichen ein riesiger Hash ist, und in der Lage zu sein, einen dieser Schlüssel auszuwählen. Wenn Ihre DB 3NF ist und Sie keine Verknüpfungen ausfü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), MongoDB würde dir wahrscheinlich in den Arsch treten.

Zum Schluss:

Wenn Sie daran gehindert werden, etwas Superfreundliches zu machen, weil Sie keine Datenbank auswählen können, machen Sie es falsch. Wenn Sie MySQL kennen, benutzen Sie es einfach. Optimieren Sie, wann Sie es tatsächlich brauchen. Verwenden Sie es wie einen k/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 nutzt immer noch viel MySQL. Wikipedia verwendet viel MySQL. FriendFeed verwendet viel 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 baue ich meine nächste App auf? Wahrscheinlich Postgres. Werde ich NoSQL verwenden? Vielleicht. Ich könnte auch Hadoop und Hive verwenden. Ich könnte alles in flachen Akten aufbewahren. Vielleicht fange ich an, auf Maglev zu hacken. Ich werde das verwenden, was für den Job am besten ist. Wenn ich einen Bericht benötige, werde ich keinen verwenden NoSQL. Wenn ich zwischenspeichern muss, verwende ich wahrscheinlich Tokyo Tyrant. Wenn ich ACIDity benötige, verwende ich kein NoSQL. Wenn ich eine Menge Zähler benötige, verwende ich Redis. Wenn ich Transaktionen benötige, benutze ich Postgres. Wenn ich eine Tonne Dokumente eines Typs habe, Ich werde wahrscheinlich Mongo verwenden. Wenn ich täglich 1 Milliarde Objekte schreiben muss, würde ich wahrscheinlich Voldemort verwenden. Wenn ich eine Volltextsuche benötige, verwende ich wahrscheinlich Solr. Wenn ich nach flüchtigen Daten im Volltext suchen möchte, verwende ich wahrscheinlich Sphinx.

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 sich zwischen RDBMS und NoSQL entscheiden. Lohnt sich die Lektüre meiner Meinung nach.

Alternativer Link zum Artikel

644
Pascal Thivent

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

  1. Am Ende schreiben Sie Jobs, um Daten aus verschiedenen Tabellen/Sammlungen zu verknüpfen. Dies würde ein RDBMS automatisch für Sie tun.
  2. Ihre Abfragemöglichkeiten mit NoSQL sind drastisch eingeschränkt. MongoDb ist zwar SQL am nächsten, liegt aber immer noch weit zurück. Vertrau mir. SQL-Abfragen sind sehr intuitiv, flexibel und leistungsstark. MongoDb-Abfragen gibt es 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, Daten zu de-normalisieren - was Hintergrundjobs bedeutet.
  4. Die Tatsache, dass es sich nicht um eine relationale Datenbank handelt, bedeutet, dass Sie keine Fremdschlüsseleinschränkungen haben (von manchen als schlecht empfunden), um sicherzustellen, dass Ihre Daten konsistent sind. Ich versichere Ihnen, dass dies irgendwann zu Dateninkonsistenzen in Ihrer Datenbank führen wird. Sei vorbereitet. Höchstwahrscheinlich werden Sie mit dem Schreiben von Prozessen oder Überprüfungen beginnen, um Ihre Datenbank konsistent zu halten. Dies ist wahrscheinlich nicht besser, als wenn Sie das RDBMS dies für Sie tun lassen.
  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.

178
Marquez

um diese unstrukturierten Daten zu speichern

Wie Sie sagten, ist MongoDB am besten geeignet, um unstrukturierte Daten zu speichern. Und dies kann Ihre Daten im Dokumentformat organisieren. Diese RDBMS-Alternativen heißen NoSQL Datenspeicher ( MongoDB , CouchDB , Voldemort ) sind sehr nützlich für Anwendungen, die massiv skaliert werden und einen schnelleren Datenzugriff von diesen großen Datenspeichern erfordern.

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

Im Gegensatz dazu erzwingt RDBM ACID und Schemata 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 (allgemeine) Anwendung, die strukturierte Beziehungen zwischen den Daten aufweist.

26
RameshVel

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-Layer ultradünn, da sie nicht alle JS-Objekteigenschaften dekomprimieren und versuchen, sie in eine Struktur (Schema) zu zwingen, in die sie auf natürliche Weise nicht passen.

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

10
Journeyman

Wer braucht verteilte, zerbrochene Foren? Vielleicht Facebook, aber wenn Sie keinen Facebook-Konkurrenten erstellen, verwenden Sie einfach Mysql, Postgres oder was auch immer Sie am besten können. Wenn du MongoDB ausprobieren willst, ok, aber erwarte nicht, dass es Magie für dich bewirkt. Es wird seine Macken und allgemeine Gemeinheit haben, genau wie alles andere, wie ich sicher bin, dass Sie bereits entdeckt haben, ob Sie wirklich schon daran gearbeitet haben.

Sicher, MongoDB mag hochgespielt sein und an der Oberfläche einfach erscheinen, aber Sie werden auf Probleme stoßen, die bereits durch ausgereiftere Produkte überwunden wurden. Lassen Sie sich nicht so leicht locken, sondern warten Sie, bis "nosql" ausgereift ist oder stirbt.

Persönlich denke ich, dass "nosql" durch Fragmentierung verdorren und sterben wird, da es keine festgelegten Standards gibt (fast per Definition). Ich persönlich wette also nicht auf langfristige Projekte.

Das einzige, was "nosql" in meinem Buch retten kann, ist, dass es sich nahtlos in Ruby oder ähnliche Sprachen integrieren lässt und die Sprache "persistent" macht, fast ohne zusätzlichen Aufwand bei 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 Unmengen von 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).

7
Fred

Ich würde sagen, verwenden Sie ein RDBMS, wenn Sie komplexe Transaktionen benötigen. Ansonsten würde ich mit MongoDB arbeiten - flexibler in der Arbeit und Sie wissen, dass es skalierbar ist, wenn Sie es brauchen. (Ich bin jedoch voreingenommen - ich arbeite am MongoDB-Projekt)

7
mdirolf

Die 2 Hauptgründe, warum Sie Mongo bevorzugen könnten, sind

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

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

4
Sushant Gupta

Ich habe gesehen, dass viele Unternehmen MongoDB für Echtzeitanalysen aus Anwendungsprotokollen verwenden. Die Schemafreigabe eignet sich besonders für Anwendungsprotokolle, bei denen sich das Aufzeichnungsschema in der Regel von Zeit zu Zeit ändert. Außerdem ist die Funktion Capped Collection 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.

4
Kazuki Ohta

Wissen Sie, all das Zeug über die Verknüpfungen 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 '- so ist es wieder dasselbe. Was benötigt wird, ist eine blöde, aber unglaublich aufgeräumte und schnelle Datenablage-/Wiederherstellungs-Engine für 99% der Funktionen der Web-Apps.

3
FYA

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

Was ich vorschlage, ist, die beste Kombination zu finden: MySQL + Memcache ist wirklich großartig, wenn Sie ACID benötigen und einige Tabellen verknüpfen möchten

Was ich tue: 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!

1