it-swarm.com.de

Ist die Verwendung von NoSQL-Datenbanken für große Datenmengen, bei denen Sie nach Inhalten suchen müssen, unpraktisch?

Ich lerne jetzt seit einer Woche etwas über NoSQL-Datenbanken.

Ich verstehe die Vorteile von NoSQL-Datenbanken und die vielen Anwendungsfälle, für die sie sich hervorragend eignen.

Aber oft schreiben Leute ihre Artikel so, als ob NoSQL ersetzen relationale Datenbanken könnte. Und da ist der Punkt, an dem ich mich nicht orientieren kann:

NoSQL-Datenbanken sind (häufig) Schlüsselwertspeicher.

Natürlich ist es möglich, alles in einem Schlüsselwertspeicher zu speichern (indem die Daten in JSON, XML usw. codiert werden), aber das Problem sehe ich ist, dass Sie in vielen Anwendungsfällen eine Datenmenge abrufen müssen , die einem bestimmten Kriterium entspricht. In einer NoSQL-Datenbank haben Sie nur ein Kriterium, nach dem Sie effektiv suchen können - den Schlüssel. Relationale Datenbanken sind optimiert, um effektiv nach beliebigen Werten in der Datenzeile zu suchen.

Daher sind NoSQL-Datenbanken nicht wirklich eine Wahl für persistente Daten, die nach ihrem Inhalt durchsucht werden müssen. Oder habe ich etwas falsch verstanden?

Ein Beispiel:

Sie müssen Benutzerdaten für einen Webshop speichern.

In einer relationalen Datenbank speichern Sie jeden Benutzer als Zeile in der Tabelle users mit einer ID, dem Namen, seinem Land usw.

In einer NoSQL-Datenbank würden Sie jeden Benutzer mit seiner ID als Schlüssel und allen seinen Daten (in JSON usw. codiert) als Wert speichern.

Wenn Sie also alle Benutzer aus einem bestimmten Land abrufen müssen (aus irgendeinem Grund müssen die Marketingmitarbeiter etwas über sie wissen), ist dies in der relationalen Datenbank einfach, in der NoSQL-Datenbank jedoch nicht sehr effektiv, da dies erforderlich ist Holen Sie sich jeden Benutzer, analysieren Sie alle Daten und filtern Sie.

Ich sage nicht, dass es unmöglich ist , aber es wird viel schwieriger und ich denke nicht so effektiv, wenn Sie in den Daten von NoSQL-Einträgen suchen möchten .

Sie können für jedes Land einen Schlüssel erstellen, in dem die Schlüssel aller in diesem Land lebenden Benutzer gespeichert sind, und die Benutzer eines bestimmten Landes ermitteln, indem Sie alle Schlüssel abrufen, die im Schlüssel für dieses Land hinterlegt sind. Ich denke jedoch, dass diese Technik ein komplexes Dataset noch komplexer macht - es ist schwieriger zu implementieren und nicht so effektiv wie das Abfragen einer SQL-Datenbank. Ich denke, das ist kein Weg, den Sie in der Produktion verwenden würden. Oder ist es?

Ich bin mir nicht sicher, ob ich etwas falsch verstanden oder einige Konzepte oder Best Practices zur Behandlung solcher Anwendungsfälle übersehen habe. Vielleicht könnten Sie meine Aussagen korrigieren und meine Fragen beantworten.

51
Leo Lindhorst

Ich stimme Ihrer Annahme zu, dass NoSQL nicht das Allheilmittel für alle Datenbankprobleme ist, aber ich denke, Sie verstehen einen wichtigen Punkt falsch.

In der NoSQL-Datenbank haben Sie nur ein Kriterium, nach dem Sie effektiv suchen können - den Schlüssel.

Dies ist eindeutig nicht wahr.

Zum Beispiel unterstützt MongoDB Indizes. (von https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Indizes unterstützen die effiziente Ausführung von Abfragen in MongoDB. Ohne Indizes muss MongoDB einen Sammlungsscan durchführen, d. H. Jedes Dokument in einer Sammlung scannen, um die Dokumente auszuwählen, die mit der Abfrageanweisung übereinstimmen. Wenn für eine Abfrage ein geeigneter Index vorhanden ist, kann MongoDB den Index verwenden, um die Anzahl der zu prüfenden Dokumente zu begrenzen.

Indizes sind spezielle Datenstrukturen [1], in denen ein kleiner Teil des Datensatzes der Sammlung in leicht zu durchlaufender Form gespeichert ist. Der Index speichert den Wert eines bestimmten Felds oder einer Reihe von Feldern, geordnet nach dem Wert des Feldes. Die Reihenfolge der Indexeinträge unterstützt effiziente Gleichheitsübereinstimmungen und bereichsbasierte Abfrageoperationen. Darüber hinaus kann MongoDB sortierte Ergebnisse mithilfe der Reihenfolge im Index zurückgeben.

Wie Couchbase (von http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Couchbase-Ansichten ermöglichen das Indizieren und Abfragen von Daten.

Eine Ansicht erstellt einen Index für die Daten gemäß dem definierten Format und der definierten Struktur. Die Ansicht besteht aus bestimmten Feldern und Informationen, die aus den Objekten in Couchbase extrahiert wurden.

Tatsächlich sollte alles, was sich selbst als NoSQL-Datenbank und nicht als Schlüsselwertspeicher bezeichnet, eine Art von Indexierungsschemata unterstützen.

Tatsächlich ist es oft die Flexibilität dieser Indexschemata, die NoSQL zum Leuchten bringt. Meiner Meinung nach ist die Sprache, in der die NoSQL-Indizes definiert werden, häufig ausdrucksvoller oder natürlicher als SQL. Da sie normalerweise außerhalb der Tabelle gespeichert sind, müssen Sie Ihre Tabellenschemata nicht ändern, um sie zu unterstützen. (Um nicht zu sagen, dass Sie in SQL keine ähnlichen Dinge tun können, aber für mich scheint es viel mehr Hoop-Jumping zu geben).

40

Wenn Ihr Workflow perfekt zu relationalen Datenbankabfragen passt, sind relationale Datenbanken im Allgemeinen der effizienteste Ansatz. Es ist tautologisch, aber es ist wahr.

Die Behauptung, die viele NoSQL-Befürworter machen würden, ist, dass viele Workflows tatsächlich in eine relationale Form massiert wurden und vor einer solchen Massage effektiver gewesen wären. Die Gültigkeit dieser Behauptung ist schwierig festzustellen. Natürlich gibt es Jobs, die durch SQL-Abfragen sehr gut beschrieben werden. Ich kann aus meiner Erfahrung sagen, dass meine bestimmte relationale Programmieraufgaben mit NoSQL mit nahezu der gleichen Effizienz, wenn nicht sogar mehr, hätten erledigt werden können. Dies ist jedoch eine sehr subjektive Aussage, die auf engen Erfahrungen beruht.

Ich habe das Gefühl, dass der Verkauf des NoSQL-Ansatzes zum großen Teil auf der Annahme großer Datenbanken beruht. Je größer die Datenbank ist, desto mehr müssen Sie Ihren Workflow optimieren, um die größeren Datensätze zu unterstützen. NoSQL scheint diese Pflege besser unterstützen zu können. Je größer die Datenbank ist, desto wichtiger können möglicherweise die Funktionen von NoSQL sein.

Um das Beispiel zu verwenden, ist die Abfrage in SQL nach Land genauso langsam wie der NoSQL-Scan aller Benutzer, es sei denn, Sie haben SQL ausdrücklich angewiesen, die Tabelle users nach Land zu indizieren. NoSQL kann dasselbe tun, indem Sie eine geordnete Schlüsselwertsammlung erstellen, die der Index ist (genau wie SQL unter der Haube), und diese verwalten.

Der Unterschied? In SQL-Engines war das Konzept der Indizierung der Tabelle integriert. Dies bedeutet, dass Sie weniger Arbeit erledigen müssen (Sie mussten lediglich einen Index zur Tabelle hinzufügen). Dies bedeutet jedoch auch, dass Sie weniger Kontrolle hatten. In den meisten Fällen ist dieser Kontrollverlust akzeptabel, wenn die SQL-Engine die Arbeit für Sie erledigt. In massiven Datasets möchten Sie möglicherweise ein anderes Konsistenzmodell als das typische SQL ACID-Modell. Möglicherweise möchten Sie das BASE-Modell verwenden, das eine eventuelle Konsistenz unterstützt. Dies kann in SQL sehr schwierig sein, da die SQL-Engine die Arbeit für Sie erledigt und daher nach den Regeln der SQL-Engine ausgeführt werden muss. In NoSQL werden diese Ebenen normalerweise angezeigt, sodass Sie sie hacken können.

40
Cort Ammon

NoSQL ist ein ziemlich vager Begriff, da er grundsätzlich alle Datenbanksysteme abdeckt, die nicht relational sind.

Was Sie beschreiben, ist ein Schlüsselwertspeicher , eine Art Datenbank, in der ein Datenblock unter einem Schlüssel gespeichert ist und schnell abgerufen werden kann auf, wenn Sie den Schlüssel kennen. Diese Datenbanken sind unglaublich schnell, wenn Sie den genauen Schlüssel kennen. Wenn Sie jedoch mehrere Eigenschaften der Daten suchen oder filtern müssen, ist dies langsam und umständlich.

Niemand, der bei klarem Verstand ist, würde behaupten, dass Schlüsselwertspeicher relationale Datenbanken im Allgemeinen ersetzen können. Es kann jedoch bestimmte Anwendungsfälle geben, in denen der Schlüsselwertspeicher gut passt. Schlüsselwertspeicher werden häufig zum Zwischenspeichern verwendet, da Sie Elemente normalerweise nach ID zwischenspeichern, aber keine Ad-hoc-Abfragen über Caches durchführen müssen. Beispielsweise verwendet die Stackoverflow-Site selbst Redis (eine Schlüsselwert-Datenbank) ausführlich , jedoch nur für das Zwischenspeichern von Ausgaben. Die zugrunde liegenden kanonischen Daten bleiben in einer relationalen Datenbank erhalten.

Die Antwort liegt also auf der Hand: Verwenden Sie einen Schlüsselwertspeicher, wenn Sie nur mit einem einzigen Schlüssel speichern und nachschlagen müssen. Verwenden Sie andernfalls eine andere Art von Datenbank. Und wenn Sie Zweifel haben, verwenden Sie eine relationale Datenbank, da dies die vielseitigste Art von Datenbank ist, während die NoSQL-Datenbanken häufig für ganz bestimmte Anwendungsfälle optimiert sind.

16
JacquesB

Ihre Aussagen zu relationalen Datenbanken sind alle wahr, bis zu dem Punkt, an dem Sie so viele Daten haben, dass Sie keine Kopie mehr auf einen einzelnen Server passen können. Dann stoßen Sie auf alle möglichen interessanten Probleme. Wie teilen Sie Ihre Tabellen auf, damit die meisten Ihrer Abfragen auf einem einzelnen Server ausgeführt werden können? Wie viele Kopien der Daten erstellen Sie? Wie gehen Sie mit Inkonsistenzen zwischen diesen Kopien um? Wie können Sie die Daten eines Benutzers in einem Rechenzentrum aufbewahren, das ihm geografisch relativ nahe steht?

Diese Ziele stehen oft in Konflikt miteinander. Viele Twitter-Nutzer folgen Menschen aus aller Welt. Sollte die Datenbank von Twitter geografisch für das Lesen von Tweets oder das Schreiben von Tweets optimiert werden?

Wenn Sie sich mit dieser Art von Skalierung befassen, beginnen Sie, Lösungen zu erfinden, Redundanzen hinzuzufügen und Einschränkungen aufzuerlegen, die einer NoSQL-Datenbank sehr ähnlich sind. Wenn Sie alle Ihre Daten auf eine Box packen können, erhalten Sie nur die Einschränkungen und benötigen die Vorteile nicht.

10
Karl Bielefeldt

NoSQL-Datenbanken haben sehr wenig mit „No SQL“ zu tun.

Es geht darum zuzugeben, dass Sie keine Datenbank haben können im Maßstab die immer konsistent ist nd unterstützt komplexe Transaktionen nd hat Haltbarkeit.

In einer normalen relationalen Datenbank werden alle Indizes im Rahmen einer Transaktion automatisch aktualisiert und können daher für jede Abfrage verwendet werden.

In einer NoSQL-Datenbank ist der Programmierer für die Verwaltung vieler Indizes verantwortlich, und es wird davon ausgegangen, dass die Indizes immer veraltet sind.

Zum Beispiel:

  • Ein Personenindex nach Steuernummer kann einige Personen enthalten, die den Registrierungsprozess für Steuern nie abgeschlossen haben.
  • Daher muss Code, der den Index verwendet, in der Lage sein, unvollständige Steuerregistrierungen zu verarbeiten
  • Eine andere Möglichkeit besteht darin, Zeiten zu haben, in denen eine steuerpflichtige Person nicht im Index enthalten ist. (Ihr Design muss also mit nicht konsistenten Daten fertig werden und entscheiden, wie die Daten nicht konsistent sind.)

Als reales Beispiel würde Amazon mir lieber die veraltete Beschreibung eines Buches zeigen, als die Anzeige der Webseite zu verzögern, indem darauf gewartet wird, dass 106 Computer bestätigen, dass die richtige Sperre aufgehoben wurde.

daher .....

Wenn eine einzelne normale relationale Datenbank alle Ihre Daten speichern und jede Transaktion schnell genug verarbeiten kann, sodass das Sperren Ihr System nicht daran hindert, nützliche Arbeit zu leisten, ist eine relationale Datenbank die beste Option.

Sobald Sie jedoch darüber nachdenken müssen, mehr als eine relationale Datenbank zu verwenden oder Transaktionen aufzuteilen, um Sperrfehler zu vermeiden, müssen Sie sich mit den Problemen auseinandersetzen, die bei der Verwendung von „NoSQL“ -Datenbanken auftreten.

Da „NoSQL“ -Datenbanken diese Probleme nicht verbergen, sind sie möglicherweise die beste Option, wenn Sie ein System skalieren. Denken Sie jedoch daran, dass Stackoverflow immer noch eine relationale Datenbank zum Speichern aller Daten verwendet, wobei NoSQL nur begrenzt in der Caching-Ebene verwendet wird. Sie müssen also SEHR groß sein, bevor Sie NoSQL zum Speichern Ihrer Daten verwenden müssen. =

5
Ian

Relationale Datenbanken sind so optimiert, dass sie effektiv nach beliebigen Werten in der Datenzeile suchen.

Verwechseln Sie nicht die Fähigkeit, nach "jedem" Wert in einer Zeile zu suchen, mit "jedem" Wert in einer Zeile. Der effektivste Weg, dies zu tun, erfordert einen oder mehrere Indizes. Sie könnten Indizes haben, die alle Felder enthalten, aber dann haben Sie nur behindert, dass Sie Änderungen vornehmen können, die eine Änderung des Index erfordern (Einfügen, Aktualisieren, Löschen). Sie (oder Ihr DBA) müssen die Daten, die Verwendung, Engpässe usw. verstehen.

2
JeffO