it-swarm.com.de

Wann sollte ich eine NoSQL-Datenbank anstelle einer relationalen Datenbank verwenden? Ist es in Ordnung, beide auf derselben Site zu verwenden?

Was sind die Vorteile der Verwendung von NoSQL-Datenbanken? Ich habe in letzter Zeit viel darüber gelesen, bin mir aber immer noch nicht sicher, warum ich eine implementieren möchte und unter welchen Umständen ich eine verwenden möchte.

130
smfoote

Relationale Datenbanken erzwingen ACID . Sie verfügen also über schemabasierte transaktionsorientierte Datenspeicher. Es ist bewährt und für 99% der realen Anwendungen geeignet. Mit relationalen Datenbanken können Sie praktisch alles machen.

Es gibt jedoch Einschränkungen in Bezug auf Geschwindigkeit und Skalierung, wenn es um massive Datenspeicher mit hoher Verfügbarkeit geht. Zum Beispiel haben Google und Amazon Terabytes an Daten in großen Rechenzentren gespeichert. Das Abfragen und Einfügen ist in diesen Szenarien aufgrund der Blockierungs-/Schema-/Transaktionscharakteristik der RDBMs nicht ausreichend. Aus diesem Grund haben sie ihre eigenen Datenbanken (eigentlich Schlüsselwertspeicher) implementiert, um eine enorme Leistungssteigerung und Skalierbarkeit zu erzielen.

NoSQL-Datenbanken gibt es schon lange - nur der Begriff ist neu. Einige Beispiele sind Graph-, Objekt-, Spalten-, XML- und Dokumentdatenbanken.

Für Ihre 2. Frage: Ist es in Ordnung, beide auf derselben Site zu verwenden?

Warum nicht? Beides dient unterschiedlichen Zwecken, oder?

76
RameshVel

NoSQL-Lösungen sind normalerweise dazu gedacht, ein Problem zu lösen, für das relationale Datenbanken entweder nicht gut geeignet oder zu teuer sind (wie Oracle), oder Sie müssen etwas implementieren, das die relationale Natur Ihrer Datenbank ohnehin bricht.

Die Vorteile hängen in der Regel von Ihrer Nutzung ab, aber wenn Sie keine Probleme bei der Modellierung Ihrer Daten in einem RDBMS haben, sehe ich keinen Grund, warum Sie sich für NoSQL entscheiden sollten.

Ich selbst benutze MongoDB und Riak für bestimmte Probleme, bei denen ein RDBMS keine praktikable Lösung ist, und für alle anderen Dinge, die ich mit MySQL (oder SQLite zum Testen) benutze.

Wenn Sie brauchen eine NoSQL-Datenbank, die Sie normalerweise kennen, sind folgende Gründe möglich:

  • der Kunde möchte eine Verfügbarkeit von 99,999% auf einer stark frequentierten Site.
  • ihre Daten sind in SQL nicht sinnvoll. Sie führen mehrere JOIN-Abfragen durch, um auf bestimmte Informationen zuzugreifen.
  • sie brechen das relationale Modell, Sie haben CLOBs, die denormalisierte Daten speichern, und Sie generieren externe Indizes, um diese Daten zu durchsuchen.

Wenn Sie keine NoSQL-Lösung benötigen, denken Sie daran, dass diese Lösungen nicht als Ersatz für ein RDBMS gedacht waren, sondern als Alternativen, bei denen das erstere fehlschlägt und vor allem, dass sie als solche relativ neu sind und immer noch viele Fehler aufweisen fehlende Funktionen.

Oh, und in Bezug auf die zweite Frage ist es vollkommen in Ordnung, eine Technologie in Verbindung mit einer anderen zu verwenden. Um meiner Erfahrung nach vollständig zu sein, funktionieren MongoDB und MySQL problemlos zusammen, solange sie nicht auf demselben Computer installiert sind

69
Asaf

Martin Fowler hat ein exzellentes Video , das eine gute Erklärung für NoSQL-Datenbanken gibt. Der Link führt direkt zu seinen Verwendungsgründen, aber das gesamte Video enthält gute Informationen.

  1. Sie haben große Datenmengen - vor allem, wenn Sie nicht alle Daten auf einem physischen Server speichern können, da NoSQL für eine gute Skalierbarkeit ausgelegt ist.

  2. Nichtübereinstimmung der objektrelationalen Impedanz - Ihre Domänenobjekte passen nicht gut in ein relationales Datenbankschema. Mit NoSQL können Sie Ihre Daten als Dokumente (oder Diagramme) speichern, die Ihrem Datenmodell möglicherweise viel näher kommen.

34
Despertar

NoSQL ist ein Datenbanksystem, in dem Daten in das Dokument (MongoDB), das Schlüssel-Wert-Paar (MemCache, Redis) und die Diagrammstrukturform (Neo4J) organisiert werden.

Vielleicht gibt es hier mögliche Fragen und Antworten für "Wann Sie sich für NoSQL entscheiden sollten":

  1. Benötigen Sie ein flexibles Schema oder beschäftigen Sie sich mit baumartigen Daten?
    Im Allgemeinen beginnen wir in der agilen Entwicklung mit dem Entwurf von Systemen, ohne alle Anforderungen im Voraus zu kennen. Später müssen wir im gesamten Entwicklungsdatenbanksystem möglicherweise häufige Entwurfsänderungen vornehmen, um MVP (Minimal Viable Product) zu präsentieren. Oder Sie haben es mit einem dynamischen Datenschema zu tun. z.B. Systemprotokolle, sehr genaues Beispiel sind AWS Cloudwatch-Protokolle.

  2. Datensatz ist riesig/groß?
    Ja, NoSQL-Datenbanken sind die besten Kandidaten für Anwendungen, bei denen die Datenbank Millionen oder sogar Milliarden von Datensätzen verwalten muss, ohne die Leistung zu beeinträchtigen.

  3. Kompromiss zwischen Skalierung und Konsistenz
    Im Gegensatz zu RDMS kann die NoSQL-Datenbank hier und da kleine Daten verlieren (Hinweis: Die Wahrscheinlichkeit beträgt .x%), ist jedoch in Bezug auf die Leistung einfach zu skalieren. Beispiel: Dies eignet sich möglicherweise zum Speichern von Personen, die in einer Instant Messaging-App online sind, Token in einer Datenbank und zum Protokollieren von Website-Verkehrsstatistiken.

  4. Durchführen von Geolocation-Vorgängen: MongoDB bietet umfangreiche Unterstützung für GeoQuerying- und Geolocation-Vorgänge. Ich habe dieses Feature von MongoDB wirklich geliebt.

Kurz gesagt, MongoDB eignet sich hervorragend für Anwendungen, in denen Sie dynamisch strukturierte Daten in großem Maßstab speichern können.

13
Hrishikesh

Zur Beantwortung der Frage fehlen einige wesentliche Informationen: Welche Anwendungsfälle muss die Datenbank abdecken können? Müssen komplexe Analysen aus vorhandenen Daten durchgeführt werden ( OLAP ) oder muss die Anwendung in der Lage sein, viele Transaktionen zu verarbeiten ( OLTP )? Wie ist die Datenstruktur? Das ist noch lange nicht das Ende der Fragestunde.

Meiner Meinung nach ist es falsch, technologische Entscheidungen auf der Grundlage kühner Schlagworte zu treffen, ohne genau zu wissen, was dahinter steckt. NoSQL wird oft für seine Skalierbarkeit gelobt. Man muss aber auch wissen, dass horizontale Skalierung (über mehrere Knoten) auch ihren Preis hat und nicht kostenlos ist. Dann müssen Sie sich mit Themen wie eventuelle Konsistenz befassen und festlegen, wie Datenkonflikte gelöst werden sollen, wenn sie nicht auf Datenbankebene gelöst werden können. Dies gilt jedoch für alle verteilten Datenbanksysteme.

Die Freude der Entwickler mit dem Wort "schema less" bei NoSQL ist am Anfang auch sehr groß. Dieses Schlagwort ist nach einer technischen Analyse schnell entzaubert, da es beim Schreiben kein Schema erfordert, sondern beim Lesen ins Spiel kommt. Deshalb sollte es korrekterweise "Schema beim Lesen" sein. Es kann verlockend sein, Daten nach eigenem Ermessen schreiben zu können. Aber wie gehe ich mit der Situation um, wenn Daten vorhanden sind, die neue Version der Anwendung jedoch ein anderes Schema erwartet?

Das Dokumentmodell (wie zum Beispiel in MongoDB) ist nicht geeignet für Datenmodelle, bei denen es viele Beziehungen zwischen den Daten gibt. Verknüpfungen müssen auf Anwendungsebene durchgeführt werden, was zusätzlichen Aufwand bedeutet und warum ich Dinge programmieren sollte, die die Datenbank tun sollte.

Wenn Sie argumentieren, dass Google und Amazon ihre eigenen Datenbanken entwickelt haben, weil herkömmliche RDBMS die Datenflut nicht mehr bewältigen können, können Sie nur sagen: Sie sind nicht Google und Amazon. Diese Unternehmen sind die Speerspitze, etwa 0,01% der Szenarien, in denen traditionelle Datenbanken nicht mehr geeignet sind, sondern für den Rest der Welt.

Was nicht unwichtig ist: SQL gibt es seit über 40 Jahren und Millionen von Stunden Entwicklungszeit sind in große Systeme wie Oracle oder Microsoft SQL geflossen. Dies muss durch einige neue Datenbanken erreicht werden. Manchmal ist es auch einfacher, einen SQL-Administrator als jemanden für MongoDB zu finden. Das bringt uns zur Frage der Wartung und des Managements. Ein Thema, das nicht gerade sexy ist, aber Teil der Technologieentscheidung ist.

3
Stefan Prugg

Ich bin auf diese Frage gestoßen, als ich nach überzeugenden Gründen gesucht habe, um vom RDBMS-Design abzuweichen.

Es gibt ein großartiges post von Julian Brown, das die Einschränkungen verteilter Systeme beleuchtet. Das Konzept heißt Brewer's CAP Theorem und lautet zusammenfassend:

Die drei Anforderungen verteilter Systeme sind: Konsistenz, Verfügbarkeit und Partitionstoleranz (kurz CAP). Es können aber immer nur zwei gleichzeitig sein.

Und so habe ich es für mich zusammengefasst:

Sie sollten sich für NoSQL entscheiden, wenn Sie auf Konsistenz verzichten.

2
Jermin Bazazian