it-swarm.dev

Wann würde jemand MongoDB (oder ähnliches) über ein relationales DBMS verwenden?

Ich bin ein bisschen verwirrt über die ganze NoSQL-Sache und so. Wann würden Sie sich dafür entscheiden, etwas wie MongoDB gegenüber etwas wie Oracle oder MySQL zu verwenden? Ich verstehe den "Unterschied" nicht wirklich, was die Verwendung zwischen ihnen betrifft.

Nach meinem Verständnis sollen NoSQL-Datenbanken RDBMS nicht ersetzen, aber was genau sollen sie tun?

138
user6791

Ich habe CouchDB schon einmal für drei Haustierprojekte verwendet.

  • Ein Mikroblogging-System.
  • Zum Speichern von Informationen für eine kleine Notiz-App habe ich gemacht.
  • Eine universelle Brainstorming-Anwendung.

Der Hauptgrund, warum ich mich für etwas wie MSSQL oder MySQL entschieden habe, ist die Flexibilität, die Sie bei der Verwendung erhalten. Kein starres Schema. Wenn Sie drei Monate später eine bestimmte Tabelle benötigen, um ein zusätzliches Feld zu haben, und dies und das, ändern Sie es einfach und es kräuselt sich von da an heraus.

Ich habe Beginning CouchDB von Apress verwendet, um zu lernen, wie man es benutzt.

Beispielsweise verwendet CouchDB json, um mit/von der Datenbank zu kommunizieren. Wenn Ihre Sprache POST Daten) kann, können Sie damit mit der Datenbank kommunizieren.

Lesen Sie auch: Warum sollte ich eine dokumentbasierte Datenbank anstelle einer relationalen Datenbank verwenden? on StackOverflow

34
Sergio

Es tut uns leid, eine weitere Antwort hinzuzufügen, aber keine der Antworten hier ist sehr zufriedenstellend. Diese Antwort ist spezifisch für MongoDB (im Gegensatz zu den zahlreichen anderen Datenspeicheroptionen, bei denen es sich nicht um relationale Datenbanken handelt).

Vorteile :

  • MongoDB hat eine geringere Latenz pro Abfrage und verbringt weniger CPU-Zeit pro Abfrage, da es viel weniger Arbeit erledigt (z. B. keine Joins, Transaktionen). Infolgedessen ist es kann eine höhere Last in Bezug auf Abfragen pro Sekunde verarbeiten und wird daher häufig verwendet, wenn Sie eine große Anzahl von Benutzern haben.
  • MongoDB ist einfacher zu sharden (Verwendung in einem Cluster), da es sich nicht um Transaktionen und Konsistenz kümmern muss.
  • MongoDB hat eine schnellere Schreibgeschwindigkeit, da es sich nicht um Transaktionen oder Rollbacks kümmern muss (und sich daher nicht um das Sperren kümmern muss).
  • MongoDB hat kein Schema falls Sie einen speziellen Anwendungsfall haben, der dies nutzen kann.

Nachteile :

  • MongoDB nterstützt keine Transaktionen. Auf diese Weise erhält es die meisten seiner Vorteile.
  • Im Allgemeinen ist MongoDB erzeugt mehr Arbeit (z. B. mehr CPU-Kosten) für den Client-Server. Um Daten zu verbinden, müssen Sie beispielsweise mehrere Abfragen ausführen und den Join auf dem Client ausführen.
  • Selbst hier im Jahr 2017 gibt es weniger Tooling-Unterstützung für MongoDB als für relationale Datenbanken, einfach weil es neuer ist. Es gibt auch weniger MongoDB-Experten als ihre relationalen Kollegen.

Punkte oft missverstanden :

  • Sowohl MongoDB- als auch relationale Datenbanken unterstützen die Indizierung. Ihre Abfrageleistung ist in Bezug auf die Ausführung großer Abfragen ähnlich.
  • MongoDB macht Migrationen nicht überflüssig oder genauer gesagt, aktualisieren Sie Ihre vorhandenen Daten, wenn sich Ihr Schema weiterentwickelt. Beispiel: Wenn Sie eine Anwendung haben, die auf einer Benutzertabelle basiert, um bestimmte Daten zu enthalten, und diese Tabelle so ändern, dass sie andere Daten enthält (sagen wir, Sie fügen ein Profilbildfeld hinzu), müssen Sie entweder:
    • Schreiben Sie Ihre Anwendung, um Objekte zu behandeln, für die diese Eigenschaft undefiniert ist ODER
    • Schreiben Sie eine einmalige Migration, um einen Standardwert für diese Eigenschaft ODER einzugeben
    • Schreiben Sie Code, um zur Abfragezeit einen Standardwert bereitzustellen, wenn dieses Feld nicht vorhanden ist ODER
    • Behandeln Sie das fehlende Feld auf andere Weise
26
Pace

Um schamlos von Renesis zu stehlen (eigentlich mache ich diese Antwort CW):


Verwenden von RDBMS anstelle anderer Typen:

13
Matthew Read

Wenn Ihre Daten nicht relational sind, kann die Verwendung von NoSQL-Datenbanken wie Leistung und Skalierbarkeit (natürlich abhängig von den Umständen) erhebliche Vorteile bringen. Einige Entwurfsmuster wie CQRS erleichtern die Nutzung nicht relationaler Daten in Bereichen, in denen herkömmlicherweise ausschließlich eine SQL-Datenbank verwendet werden muss, erheblich.

Es ist üblich, Datenbanken wie Mongo für zwischengespeicherte Daten zu verwenden. Wenn Sie beispielsweise einen Bericht erstellen müssen, können Sie eine komplizierte SQL-Abfrage ausführen, die eine Reihe von Daten im laufenden Betrieb zusammenführt und aggregiert, oder Sie können einfach ein einzelnes JSON-Dokument aus Ihrer Mongo-Datenbank abrufen, das bereits alles enthält, was Sie zum Generieren benötigen der Bericht. Dies macht das Lesen von Daten sehr einfach (und schnell!), Kann jedoch das Schreiben von Daten ziemlich kompliziert machen (hier kommt CQRS ins Spiel).

9
Graeme Hill

Datenbanken wie MongoDB eignen sich hervorragend, wenn Sie normalerweise wissen, wo sich Ihre Daten befinden (im Gegensatz dazu, dass Sie mehrere komplizierte Abfragen schreiben müssen). Bei Mongo sind "verwandte" Daten entweder in den übergeordneten Daten verschachtelt oder sie haben Primär-/Fremdschlüssel. Dies ist großartig, wenn Sie beispielsweise Beiträge und Kommentare haben. Im Allgemeinen werden keine Kommentare außerhalb des Kontexts eines Beitrags angezeigt. Daher ist es sinnvoll, dass Kommentare in einem Beitrag enthalten sind (auf diese Weise erhalten Sie alle Kommentare für den Beitrag, ohne eine separate Tabelle abfragen zu müssen).

MongoDB ist schemenlos. Dies bedeutet, dass zum größten Teil die Datenstruktur benötigt wird, die Sie darauf werfen.

Wenn Sie jedoch Aggregatfunktionen verwenden müssen und das Bedürfnis haben, Daten auf komplexe Weise abzufragen, die durch Einbettungen oder einfache Beziehungen in Mongo nicht erreicht werden können, ist es an der Zeit, ein RDBMS wie MySQL oder PostgreSQL zu verwenden.

MongoDB soll SQL nicht ersetzen. Es erfüllt einfach unterschiedliche Anforderungen und MongoDB und ein RDBMS können zusammen verwendet werden. Meiner Meinung nach ist MongoDB nicht allzu notwendig, wenn Ihre Daten nicht flexibel oder in ein übergeordnetes Dokument eingebettet sein müssen. Die Entwicklung mit MongoDB macht sehr viel Spaß, da weitaus weniger Schritte erforderlich sind, um ein Projekt (z. B. in Rails) zum Laufen zu bringen. Müssen Sie eine Änderung vornehmen? Kein Problem. Fügen Sie Ihrem Modell einfach ein Attribut hinzu. Erledigt.

Ich kann nicht für viele andere NoSQL-Datenbanken sprechen, obwohl ich weiß, dass sie normalerweise ähnlich konzipiert sind, um einen bestimmten Bedarf zu erfüllen, der von einem RDBMS nicht erfüllt werden kann. Einige befinden sich vollständig im Speicher oder können sehr einfach gesplittert oder skaliert werden. Ich bin mir ziemlich sicher, dass Cassandra so konzipiert ist, dass es ohne Datenverlust weiterarbeitet, wenn ein Knoten ausfällt. Redis ist im Grunde ein Schlüsselwertspeicher, der sich im Speicher befindet (mit regelmäßigen Schreibvorgängen für die Persistenz). hat aber auch die Möglichkeit, Datentypen wie Mengen zu speichern und zu sortieren.

8
Ravenstine

Der größte Gewinn ist, wenn Sie Daten sharden oder Multi-Master-Datenbanken haben möchten. Sie können Daten in MySQL sharden, aber es wird zu einem großen Problem. Wenn Sie viele Schreibvorgänge ausführen, ist es häufig hilfreich, die Daten auf mehrere Server zu verteilen. Das Problem besteht darin, dass es sehr schwierig, wenn nicht unmöglich sein kann, den CAP-Satz nachzuschlagen, wenn Sie dabei eine starke referenzielle Konsistenz wünschen.

SQL-Datenbanken haben eine sehr gute Konsistenz, aber eine wirklich schlechte Partitionierungsunterstützung. NoSQL-Datenbanken tendieren dazu, in die andere Richtung zu gehen. Einfach zu partitionieren, aber oft als mögliche Konsistenz bezeichnet. Wenn Sie eine Messaging-Site erstellen, die in Ordnung ist, ist dies für eine Bank wahrscheinlich nicht in Ordnung.

Das Plus ist, dass es jetzt mehrere Modelle zum Speichern von Daten gibt, sodass Sie die Möglichkeit haben, Dinge zu implementieren, während Sie zuvor nur SQL-Datenbanken hatten.

SE Radio hatte einige gute Folgen zu diesem Thema.

6
Zachary K

MongoDB funktioniert gut, wenn Sie viele Daten schreiben und wenn Ihre Abfrageanforderungen nicht zu kompliziert sind. Daher passt MongoDB gut, wenn Sie CQRS mit Event Sourcing auf der Befehlsseite implementieren - d. H. Ihr Ereignisspeicher ist eine MongoDB-Datenbank.

Auf der Abfrageseite verwenden wir aufgrund ihrer Flexibilität immer noch eine SQL Server-Datenbank mit Ansichten und WCF-Datendiensten. Ich denke, in den meisten Fällen benötigen Sie zum Abfragen wirklich die Leistung einer relationalen Datenbank.

1
Roy Dictus

Der unmittelbare und grundlegende Unterschied zwischen MongoDB und einem RDBMS ist das zugrunde liegende Datenmodell. Eine relationale Datenbank strukturiert Daten in Tabellen und Zeilen, während MongoDB Daten in Sammlungen von JSON-Dokumenten strukturiert. JSON ist ein selbstbeschreibendes, für Menschen lesbares Datenformat. Ursprünglich für den einfachen Austausch zwischen Browser und Server konzipiert, hat es sich für viele Arten von Anwendungen durchgesetzt.

JSON-Dokumente sind aus mehreren Gründen besonders nützlich für die Datenverwaltung. Ein JSON-Dokument besteht aus einer Reihe von Feldern, die selbst Schlüssel-Wert-Paare sind. Dies bedeutet, dass jedes JSON-Dokument überall ein eigenes, für Menschen lesbares Schemadesign enthält, sodass die Dokumente problemlos zwischen Datenbank- und Clientanwendungen verschoben werden können, ohne ihre Bedeutung zu verlieren.

JSON ist auch ein natürliches Datenformat zur Verwendung in der Anwendungsschicht. JSON unterstützt eine umfangreichere und flexiblere Datenstruktur als Tabellen aus Spalten und Zeilen. JSON-Felder unterstützen nicht nur Feldtypen wie Zahl, Zeichenfolge, Boolescher Wert usw., sondern können auch Arrays oder verschachtelte Unterobjekte sein. Dies bedeutet, dass wir eine Reihe komplexer Beziehungen darstellen können, die die Objekte, mit denen unsere Anwendungen arbeiten, genauer darstellen. Die Verwendung von JSON-Dokumenten in unserer Datenbank bedeutet, dass wir keinen objektrelationalen Mapper zwischen unserer Datenbank und den von ihr bereitgestellten Anwendungen benötigen. Wir können unsere Daten in der richtigen Form beibehalten

1

Wenn Ihre Daten häufig abgefragt werden müssen, ist eine NoSQL-Lösung nicht gut, und wenn Sie Transaktionsunterstützung (ACID) benötigen, ist eine NoSql-Lösung nicht die beste Lösung. Ich denke, NoSQL glänzt, wenn Sie viele Lesevorgänge haben, die schnell sein müssen, und wenn die Struktur etwas adhoc ist, rufen Sie sie nach Dokument oder Seitenstruktur ab. Viele NoSQL-Lösungen verbessern sich jedoch sehr schnell, sodass die Mängel möglicherweise bald behoben sein werden. Wie auch immer, ich denke, relationale Datenbanken passen immer noch gut zu den meisten Anwendungen.

1
marko