it-swarm.com.de

Wann sollten wir MongoDB verwenden?

MongoDB ist eine NoSQL-Datenbank, deren Verwendung ich als recht einfach empfunden habe. Vor kurzem musste ich eine einfache Anwendung entwickeln, die einige Daten mithilfe von HTTP-Anforderungen erfassen und einige Ergebnisse nach der Verarbeitung der Daten speichern musste, und ich habe versucht, MongoDB zu verwenden.

Aufgrund dieser Erfahrung fand ich die Verwendung viel besser als herkömmliche relationale Datenbanken. Da ich Entwickler und kein DBA bin, wurde meine Arbeit erheblich vereinfacht.

Trotzdem bin ich mir manchmal nicht sicher, wann ich MongoDB anstelle einer herkömmlichen relationalen Datenbank wie SQL Server oder MySQL verwenden soll.

Wann können wir in diesem Fall MongoDB anstelle relationaler Datenbanken verwenden? Gibt es eine wirklich große Einschränkung bei MongoDB, die es für einige Situationen unangemessen macht?

17
user1620696

Grundsätzlich:

  • Wenn Sie Ihre Daten in Form einer Reihe von Dokumenten darstellen können, ist MongoDB möglicherweise eine gute Wahl.

  • Wenn Sie sich Ihre Daten lieber als eine Reihe miteinander verbundener Tabellen vorstellen möchten, ist MongoDB möglicherweise keine gute Wahl.

Hier sind zwei Beispiele, die ich veranschaulichend finde:

  • Vor einigen Jahren habe ich eine Blog-Engine erstellt. Der Zweck besteht darin, Blog-Artikel zu hosten und für jeden Artikel die verschiedenen Versionen, einige Metadaten, Besuchsstatistiken usw. zu speichern.

    Dies könnte als eine Reihe von Tabellen gespeichert werden, aber beim Versuch, ein Modell zu erstellen, wächst es sehr schnell auf ein Dutzend Tabellen, wenn nicht sogar mehr. Einige SQL-Abfragen könnten mit vielen joins hässlich werden, und ... nun, Sie bekommen das Bild.

    Das Problem hierbei ist, dass es eine zentrale Sache gibt - einen Blog-Artikel - und all diese Dinge rund um den Artikel, was ihn für eine dokumentbasierte Datenbank gut geeignet macht. Mit MongoDB war das Modellieren der Datenbank extrem einfach: Eine Sammlung enthält die Blog-Artikel, und eine zweite winzige Sammlung enthält die Liste der Benutzer, die Artikel schreiben dürfen. Jedes Dokument in der ersten Sammlung enthält alle Informationen, die ich zum Anzeigen eines Artikels benötige, sei es der Name des Autors oder die Tags.

  • Stellen Sie sich nun ein ganz anderes Projekt vor. Es gibt einige Benutzer, die Inhalte schreiben und die von anderen Benutzern geschriebenen Inhalte freigeben können. Auf einer Seite eines Benutzers würden Sie erwarten, sowohl die Dinge zu finden, die dieser Benutzer geschrieben hat, als auch die, die er geteilt hat. Es gibt eine Einschränkung: Wenn jemand das bearbeitet, was er in der Vergangenheit geschrieben hat, wird die Änderung überall dort angezeigt, wo der ursprüngliche Text geteilt wurde.

    Bei einem dokumentbasierten Ansatz ist es schwierig, das Dokument zu finden. Ein Benutzer vielleicht? Das ist ein guter Anfang. Ein Benutzerdokument würde alle Dinge enthalten, die dieser Benutzer geschrieben hat. Aber was ist mit den Dingen, die sie geteilt hat?

    Eine Möglichkeit besteht darin, diese Dinge in dasselbe Dokument aufzunehmen. Das Problem bei diesem Ansatz besteht darin, dass die Anwendung jedes Benutzerdokument in der Datenbank durchgehen sollte, wenn jemand einen Eintrag bearbeitet, um jedes Vorkommen des alten Eintrags zu bearbeiten. Ohne Datenvervielfältigung.

    Eine Alternative wäre, im Benutzerdokument nur die Liste der Einträge zu speichern, die dieser Benutzer geteilt hat (mit der ID des verwiesenen Benutzers und dem Eintrag). Jetzt würde jedoch ein anderes Problem auftreten: Wenn ein Benutzer Tausende von Einträgen von Tausenden von Benutzern gemeinsam nutzen würde, müsste er Tausende von Dokumenten öffnen, um diese Einträge zu erhalten.

    Oder wir können unsere Sammlung anhand der Einträge selbst modellieren, wobei jeder Eintrag auf seinen Autor verweist und eine Liste der Benutzer enthält, die ihn geteilt haben. Auch hier können Leistungsprobleme auftreten, wenn Sie alle Dokumente durchgehen müssen, um die von einem bestimmten Benutzer veröffentlichten Dokumente anzuzeigen.

    Wie viele Tabellen würden Sie benötigen, wenn Sie eine relationale Datenbank verwenden würden? Richtig, drei. Es wäre einfach zu modellieren und auch einfach zu verwenden.

18

Jede Technologie hat ihre Vorteile.

Die Vorteile relationaler Datenbanken bestehen darin, dass das RDBMS einige Dinge für Sie erledigt, wie zum Beispiel:

  • Durchsetzen der referenziellen Integrität (das Einfügen eines Rechnungsdetails ist nicht zulässig, wenn die Rechnung, zu der sie gehört, nicht vorhanden ist)
  • Redundanz vermeiden: Dinge werden nur einmal gespeichert.
  • Komplexe Abfragen können mit einer deklarativen Sprache (SQL) durchgeführt werden, die ausgereift, bewährt und weit verbreitet ist.

Das alles läuft darauf hinaus, dass Sie müssen weniger Code schreiben, weil das RDBMS die Dinge für Sie erzwingt.

Darüber hinaus Datenunabhängigkeit: Wenn Sie häufig Standard-SQL-Strukturen und keine herstellerspezifischen verwenden, können Sie Ihre Daten häufig mit minimalem Aufwand von einem RDBMS auf ein anderes migrieren, während NOSQL-Datenbanken überhaupt nicht standardisiert sind.

Andererseits besteht einer der Vorteile von NOSQL-Datenbanken darin, dass sie die Leistung für Millionen von Zeilen besser skalieren. Sie eignen sich besser für die dokumentbasierte Speicherung, d. H. Nicht strukturierte Daten. Die meisten Anwendungen benötigen diese Funktionen jedoch nicht.

9

Für Ihren speziellen Fall klingt MongoDB nach einer guten Wahl, aber es gibt viele Szenarien (wahrscheinlich die meisten davon), in denen es nicht die beste Wahl wäre.

MongoDB eignet sich eher für Szenarien, in denen das Lesen/Schreiben viel von Daten erforderlich ist, ohne viel Wert auf die Transaktionssicherheit zu legen (wenn einige Daten gelegentlich bei einem Serverabsturz verloren gehen, ist dies keine große Sache) groß skalieren und nicht wirklich ein stabiles Schema haben.

MongoDB ist nicht für Szenarien geeignet, die Folgendes erfordern:

  1. Starke ACID-Garantien: MongoDB ermöglicht das Speichern doppelter Daten, inkonsistente Lesevorgänge und sogar Datenverlust. Diese Dinge sind in einigen Anwendungen in Ordnung, in den meisten jedoch nicht.
  2. Transaktionen mit mehreren Objekten: MongoDB unterstützt ACID-Transaktionen, jedoch nur für ein einzelnes Objekt/Dokument. Dies ist für komplexere Vorgänge wie Banküberweisungen, Reservierungen usw. einfach nicht geeignet.
  3. Traditionelles BI: Es gibt viele BI-Tools, die nur mit herkömmlichem SQL gut funktionieren.
  4. SQL: MongoDB hat eine sehr spezifische Abfragesprache, während SQL vielen Leuten sehr gut bekannt ist (dies könnte ein wichtiger Aspekt sein) und viele komplexe Dinge tun kann (während Sie mit MongoDB Probleme haben würden, eine einfache auszuführen join) und ist auf viele Implementierungen übertragbar.

MongoDB ist schneller und ermöglicht es Ihnen, mehr Leistung aus dem System herauszuholen, indem Sie viele Dinge eliminieren, die RDBMS standardmäßig erzwingt, wie z. B. Integritätsprüfungen (beachten Sie, dass Sie RDBMS ohnehin auch für solche Zwecke optimieren können), aber die Wahrheit ist: In den meisten Szenarien wird es einfach nicht benötigt. Der Kompromiss ist außerdem Zuverlässigkeit und Flexibilität (Sie haben Probleme, wenn Sie später entscheiden, dass Sie komplexere Vorgänge mit vorhandenen Daten ausführen müssen).

Es hängt alles von den Anforderungen der Anwendung ab, die Sie erstellen. Ist es Geschwindigkeit und Verfügbarkeit oder Sicherheit, Zuverlässigkeit und Flexibilität. Sie müssen wissen, wo in Ihren Daten (und in den Verbindungen Ihrer Daten) mehr Wert liegt. Wenn Sie es noch nicht wissen, ist es wahrscheinlich am besten, wenn Sie etwas auswählen, das Sie in Zukunft nicht mehr in eine Ecke streichen wird, und es Ihnen ermöglicht, die Funktionen hinzuzufügen und die Vorgänge auszuführen, die Ihre Anwendung benötigt.

5
snickro

MongoDB ist großartig, wenn Sie Ihre Daten als unabhängige "Informationspakete" darstellen können. Sie haben Google Maps Postleitzahlen, eingebettet in die Postleitzahl sind Unternehmen und innerhalb der Unternehmen sind Mitarbeiter. Alle Postleitzahlen sind unabhängig voneinander und Sie können die gesamten Informationen auf einfache, hübsche und schnelle Weise abrufen. Das ist ein gutes Szenario für eine NonSQL-Lösung.

Einmal gesagt, stimme ich dem aktuellen Trend, den ich sehe, überhaupt nicht zu, der impliziert, dass MongoDB eine Art Post- und überlegene Lösung für RDBMS ist und noSQL standardmäßig Ihre Lösung sein muss. Das alles ist absurd. MongoDB ist eine Nischendatenbank, und 90% der Projekte sind relational und benötigen eine RDBMS-Option, da Sie eine leistungsstarke Abfragelösung wie SQL benötigen, um Ihre Berichte zu generieren und nach verteilten Daten zu suchen: "Joins" sind ein Vorteil, kein Nachteil. Außerdem unterstützen moderne RDBMS BSON-Sammlungen und die räumliche Integration, sodass die Nische für noSQL jetzt vielleicht noch enger ist.

3
aarkerio

MongoDB ist nützlich, um die gesamten strukturierten Daten zu speichern, die zum Erstellen einer bestimmten Instanz einer Webseite erforderlich sind. Sie können die Daten für eine bestimmte Seite abrufen und an Ihre Clientanwendung übergeben, die sie dann rendern kann.

In einem solchen Kontext ist MongoDB sehr schnell und zuverlässig. Vergessen Sie jedoch niemals, dass Ihre Datenbank keine relationalen Informationen enthält. Wenn Sie also etwas an der Struktur Ihrer Webseite ändern, können Sie möglicherweise die Lücken in Ihren bereits gespeicherten Seiten nicht füllen, da Sie nicht über die dafür erforderlichen Daten verfügen. Mehr dazu hier: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

2
Alexis Dufrenoy