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 möchten Sie MongoDB anstelle von Oracle oder MySQL verwenden? Ich verstehe den "Unterschied" in Bezug auf die Verwendung zwischen ihnen nicht wirklich.

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

Ich habe CouchDB bereits für drei Projekte mit Haustieren verwendet.

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

Der Hauptgrund, warum ich mich für etwas wie MSSQL oder MySQL entschieden habe, ist die Flexibilität, die Sie erhalten, wenn Sie es verwenden. 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 mit Beginning CouchDB von Apress gelernt, wie man es benutzt.

CouchDB verwendet beispielsweise json, um mit der Datenbank zu kommunizieren. Wenn Ihre Sprache POST-Daten unterstützt, können Sie diese zur Kommunikation mit der Datenbank verwenden.

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

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 Verknüpfungen, Transaktionen). Infolgedessen kann es 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 (in einem Cluster zu verwenden), 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 Sperren kümmern muss).
• MongoDB hat kein Schema, falls Sie einen speziellen Anwendungsfall haben, der dies ausnutzen kann.

Nachteile:

• MongoDB unterstützt keine Transaktionen . So erhält es die meisten Vorteile.
• Im Allgemeinen verursacht MongoDB mehr Arbeit (z. B. mehr CPU-Kosten) für den Client-Server . Um beispielsweise Daten zu verknüpfen, müssen mehrere Abfragen ausgeführt und die Verknüpfung auf dem Client ausgeführt werden.
• Selbst hier im Jahr 2017 gibt es für MongoDB weniger Tooling-Unterstützung als für relationale Datenbanken, nur weil es neuer ist. Es gibt auch weniger MongoDB-Experten als ihre relationalen Kollegen.

Oft missverstandene Punkte:

• Sowohl MongoDB als auch relationale Datenbanken unterstützen die Indizierung. Ihre Abfrageleistung ist hinsichtlich der Ausführung großer Abfragen ähnlich .
• MongoDB beseitigt nicht die Notwendigkeit von Migrationen und aktualisiert Ihre vorhandenen Daten, während sich Ihr Schema weiterentwickelt. Beispiel: Wenn in einer Anwendung bestimmte Daten in einer Benutzertabelle gespeichert sind und Sie diese Tabelle so ändern, dass sie andere Daten enthält (sagen wir, Sie fügen ein Profilbildfeld hinzu), müssen Sie weiterhin Folgendes tun:
  • 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 zum Zeitpunkt der Abfrage einen Standardwert bereitzustellen, wenn dieses Feld nicht vorhanden ist. ODER
  • Behandeln Sie das fehlende Feld auf andere Weise

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

Verwenden von RDBMS anstelle anderer Typen:

• Informieren Sie sich über die Idee von "NoSQL" und anderen DB-Typen:
  • NoSQL: Wenn es nur so einfach wäre
  • (oben ist verlinkt von) Wann ist MongoDB oder ein anderes dokumentenorientiertes Datenbanksystem zu verwenden? ^{derzeit auf SO gelöscht} ( mehr )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Wann wird CouchDB vs RDBMS verwendet?
• RDBMS nutzen die Indizierung stark für die Leistung. Bei sehr großen Datenbanken kann dies die Leistung beeinträchtigen oder sogar die optimale Anzahl von Zeilen pro DB / Shard verringern, für die mehr Hardware erforderlich ist
• Nicht so ideal, wenn Sie eine große Datenmenge speichern, aber weniger häufig lesen
• Wenn Sie nicht viele Auslandsbeziehungen haben, sind relationale Datenbanken möglicherweise nicht ideal (Dokumentenspeicher).

Wenn Ihre Daten nicht relational sind, kann die Verwendung von NoSQL-Datenbanken große Vorteile mit sich bringen, z. B. Leistung und Skalierbarkeit (natürlich abhängig von den Umständen). Einige Entwurfsmuster wie CQRS vereinfachen die Nutzung nicht relationaler Daten in Bereichen, die normalerweise die ausschließliche Verwendung einer SQL-Datenbank erfordern.

Es ist üblich, Datenbanken wie Mongo für zwischengespeicherte Daten zu verwenden. Wenn Sie beispielsweise einen Bericht generieren müssen, können Sie eine komplizierte SQL-Abfrage ausführen, die eine Reihe von Daten im Handumdrehen 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 generieren müssen 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).

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

MongoDB ist schemenlos. Dies bedeutet, dass die Datenstruktur, die Sie darauf werfen, größtenteils übernommen wird.

Wenn Sie andererseits Aggregatfunktionen verwenden 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 alles, was Sie brauchen, wenn Ihre Daten nicht flexibel oder in ein übergeordnetes Dokument eingebettet sein sollen. Die Entwicklung mit MongoDB macht sehr viel Spaß, da viel weniger Schritte erforderlich sind, um ein Projekt (z. B. in Rails) zum Laufen zu bringen. Müssen Sie etwas ändern? Kein Problem. Fügen Sie Ihrem Modell einfach ein Attribut hinzu. Getan.

Ich kann nicht für viele andere NoSQL-Datenbanken sprechen, obwohl ich weiß, dass sie normalerweise ähnlich konzipiert sind, um eine bestimmte Anforderung zu erfüllen, die von einem RDBMS nicht erfüllt werden kann. Einige befinden sich vollständig im Speicher oder können sehr leicht zersplittert oder skaliert werden. Ich bin mir ziemlich sicher, dass Cassandra so konzipiert ist, dass sie bei einem Ausfall eines Knotens ohne Datenverlust weiterarbeitet. Redis ist im Grunde ein Schlüsselwertspeicher, der sich im Arbeitsspeicher befindet (mit regelmäßigen Schreibvorgängen für die Persistenz), aber auch die Möglichkeit bietet, Datentypen wie Sets zu speichern und zu sortieren.

Der größte Vorteil ist, wenn Sie Daten speichern oder über Multi-Master-Datenbanken verfügen möchten. Sie können Daten in MySQL ablegen, aber es wird zu einem großen Problem. Wenn Sie viele Schreibvorgänge ausführen, ist es oft nützlich, die Daten auf mehreren Servern zu speichern. Das Problem besteht darin, dass es sehr schwierig 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 häufig wird dies als Konsistenz bezeichnet. Wenn Sie eine Messaging-Site erstellen, 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 Wahl haben, wie Sie Dinge implementieren, während Sie zuvor nur SQL-Datenbanken hatten.

SE Radio hatte einige gute Folgen zu diesem Thema.

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

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

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 für die Datenverwaltung besonders nützlich. 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 hat, sodass die Dokumente problemlos zwischen Datenbank- und Clientanwendungen wechseln können, ohne ihre Bedeutung zu verlieren.

JSON ist auch ein natürliches Datenformat zur Verwendung in der Anwendungsebene. JSON unterstützt eine umfassendere und flexiblere Datenstruktur als Tabellen, die aus Spalten und Zeilen bestehen. JSON-Felder unterstützen nicht nur Feldtypen wie number, string, boolean 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. Durch die Verwendung von JSON-Dokumenten in unserer Datenbank benötigen wir keinen objektrelationalen Mapper zwischen unserer Datenbank und den Anwendungen, für die sie bereitgestellt werden. Wir können unsere Daten in der richtigen Form beibehalten

Wenn Ihre Daten viel 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, dass NoSQL brilliert, 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. Aber viele NoSQL-Lösungen verbessern sich ziemlich schnell, so dass es vielleicht bald keine Mängel mehr gibt. Trotzdem denke ich, dass relationale Datenbanken für die meisten Anwendungen immer noch gut geeignet sind.