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

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

Ich verstehe wirklich die Vorteile von NoSQL-Datenbanken und die vielen Anwendungsfälle, für die sie großartig sind.

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

NoSQL-Datenbanken sind (oft) Schlüsselwertspeicher.

Natürlich ist es möglich , zu speichern , alles in einen Schlüssel-Wert - Speicher (durch die Daten in JSON codiert, XML, was auch immer), aber das Problem , das ich sehe , ist , dass Sie brauchen , um zu bekommen eine gewisse Menge an Daten , die ein bestimmtes Kriterium übereinstimmt, in vielen Anwendungsfälle. In einer NoSQL-Datenbank gibt es nur ein Kriterium, nach dem Sie effektiv suchen können - den Schlüssel. Relationale Datenbanken werden optimiert, um effektiv nach jedem Wert in der Datenzeile zu suchen.

NoSQL-Datenbanken sind also 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 usersTabelle mit einer ID, dem Namen, seinem Land usw.

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

Wenn Sie also alle Benutzer aus einem bestimmten Land abrufen möchten (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 kniffliger und ich denke, es ist nicht so effektiv, wenn Sie in den Daten von NoSQL-Einträgen suchen möchten.

Sie können einen Schlüssel für jedes Land erstellen, in dem die Schlüssel aller in diesem Land lebenden Benutzer gespeichert sind, und die Benutzer eines bestimmten Landes abrufen, indem Sie alle Schlüssel abrufen, die im Schlüssel für dieses Land hinterlegt sind. Aber ich denke, diese Technik macht ein komplexes Dataset noch komplexer - 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 missverstanden oder einige Konzepte oder bewährte Methoden zur Behandlung solcher Anwendungsfälle übersehen habe. Vielleicht könnten Sie meine Aussagen korrigieren und meine Fragen beantworten.

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

In der NoSQL-Datenbank gibt es 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, dh jedes Dokument in einer Sammlung scannen, um die Dokumente auszuwählen, die der Abfrageanweisung entsprechen. Wenn für eine Abfrage ein geeigneter Index vorhanden ist, kann MongoDB den Index verwenden, um die Anzahl der zu überprüfenden Dokumente zu begrenzen.

Indizes sind spezielle Datenstrukturen [1], die einen kleinen Teil des Datensatzes der Sammlung in leicht zu durchsuchender Form speichern. Der Index speichert den Wert eines bestimmten Feldes oder einer Reihe von Feldern, geordnet nach dem Wert des Feldes. Die Reihenfolge der Indexeinträge unterstützt effiziente Gleichheitsübereinstimmungen und bereichsbezogene Abfrageoperationen. Außerdem kann MongoDB sortierte Ergebnisse anhand der Reihenfolge im Index zurückgeben.

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

Couchbase-Ansichten ermöglichen die Indizierung und Abfrage 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 Indexschema 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, oft ausdrucksvoller oder natürlicher als SQL. Da sie normalerweise außerhalb der Tabelle leben, müssen Sie Ihre Tabellenschemata nicht ändern, um sie zu unterstützen. (Um nicht zu sagen, dass Sie in SQL keine ähnlichen Aktionen ausführen können, aber für mich scheint es, dass viel mehr Hoop-Jumping erforderlich ist).

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

Viele NoSQL-Befürworter behaupten, dass viele Workflows tatsächlich in eine relationale Form gebracht wurden und vor einer solchen Massage effektiver gewesen wären. Die Gültigkeit dieses Anspruchs ist nur schwer festzustellen. Offensichtlich gibt es Jobs, die durch SQL-Abfragen sehr gut beschrieben werden. Aus meiner Erfahrung kann ich sagen, dass meine speziellen relationalen Programmieraufgaben mit NoSQL mit nahezu der gleichen Effizienz hätten erledigt werden können, wenn nicht sogar mit mehr. Dies ist jedoch eine sehr subjektive Aussage, die auf engen Erfahrungen basiert.

Ich habe das Gefühl, dass ein Großteil des Verkaufs des NoSQL-Ansatzes 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 Datasets zu unterstützen. NoSQL scheint diese Bemühungen besser zu unterstützen. Je größer die Datenbank ist, desto wichtiger können die Funktionen von NoSQL sein.

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

Der Unterschied? SQL-Engines hatten das Konzept, die Tabelle zu indizieren. Dies bedeutet, dass Sie weniger Arbeit erledigen müssen (alles, was Sie tun müssen, ist, der Tabelle einen Index hinzuzufü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 umfangreichen Datasets möchten Sie jedoch 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, sodass dies nach den Regeln der SQL-Engine erfolgen muss. In NoSQL sind diese Ebenen in der Regel freigelegt, sodass Sie sie angreifen können.

NoSQL ist ein eher vager Begriff, da er grundsätzlich alle nicht relationalen Datenbanksysteme abdeckt.

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

Niemand, der bei Verstand ist, würde behaupten, Schlüsselwertspeicher könnten relationale Datenbanken im Allgemeinen ersetzen. 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 in der Regel nach ID zwischenspeichern, jedoch keine Ad-hoc-Abfragen für Caches durchführen müssen. Beispielsweise verwendet die Stackoverflow-Site selbst Redis (einen Schlüsselwert db) in großem Umfang , jedoch nur zum Zwischenspeichern der Ausgabe. Die zugrunde liegenden kanonischen Daten werden weiterhin in einer relationalen Datenbank gespeichert.

Die Antwort liegt auf der Hand: Verwenden Sie einen Schlüsselwertspeicher, wenn Sie nur einen einzigen Schlüssel zum Speichern und Nachschlagen benötigen. 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.

Ihre Aussagen zu relationalen Datenbanken sind zutreffend, bis zu dem Zeitpunkt, an dem Sie über so viele Daten verfügen, dass Sie keine Kopie mehr auf einem einzelnen Server speichern können. Dann stoßen Sie auf allerlei interessante Probleme. Wie können Sie Ihre Tabellen aufteilen, damit die meisten Ihrer Abfragen auf einem einzelnen Server ausgeführt werden können? Wie viele Kopien der Daten machen Sie? Wie gehen Sie mit Inkonsistenzen zwischen diesen Kopien um? Wie bewahren Sie die Daten eines Benutzers in einem Rechenzentrum auf, das ihm geografisch relativ nahe steht?

Diese Ziele stehen häufig im Widerspruch zueinander. Viele Twitter-Nutzer folgen Leuten aus der ganzen Welt. Sollte die Datenbank von Twitter geografisch optimiert werden, um Tweets zu lesen oder Tweets zu schreiben?

Es stellt sich heraus, dass Sie, wenn Sie sich mit dieser Art von Skalierung befassen, anfangen, Lösungen zu erfinden, Redundanzen hinzuzufügen und Einschränkungen aufzuerlegen, die einer NoSQL-Datenbank sehr ähnlich sind. Wenn Sie alle Ihre Daten in einer Box unterbringen können, gelten nur die Einschränkungen und Sie müssen die Vorteile nicht in Anspruch nehmen.

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

Sie sind etwa zugibt , dass Sie nicht eine Datenbank eingegeben haben , in großem Maßstab , die immer konsistent ist und unterstützt komplexe Transaktionen und hat lange Lebensdauer.

In einer normalen relationalen Datenbank werden alle Indizes im Rahmen einer Transaktion automatisch aktualisiert und können 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 Indizes immer veraltet sind.

Zum Beispiel:

• Ein Index der Personen nach Steuernummer kann einige Personen enthalten, die den Prozess der Steuerregistrierung niemals abschließen.
• Daher muss Code, der den Index verwendet, in der Lage sein, eine unvollständige Steuerregistrierung zu bewältigen
• Eine andere Möglichkeit besteht darin, Zeiten zu haben, in denen eine Person, die für Steuern registriert ist, nicht im Index enthalten ist. (Ihr Design muss sich also mit nicht konsistenten Daten auseinandersetzen und entscheiden, wie die Daten nicht konsistent sein sollen.)

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

Deshalb.....

Wenn eine einzelne normale relationale Datenbank alle Ihre Daten enthalten und jede Transaktion so schnell verarbeiten kann, dass das Sperren Ihr System nicht von nützlichen Aufgaben abhält, 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 befassen, 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. Beachten Sie jedoch, dass Stackoverflow weiterhin eine relationale Datenbank zum Speichern aller Daten verwendet, wobei NoSQL in der Caching-Ebene nur in begrenztem Umfang verwendet wird. Sie müssen also SEHR groß sein, bevor Sie NoSQL zum Speichern Ihrer Daten verwenden müssen.

Relationale Datenbanken werden optimiert, um effektiv nach jedem Wert in der Datenzeile zu suchen.

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

Es gibt bereits viele Antworten, aber ich wollte nur meine Zusammenfassung hinzufügen.

Das NoSQL-Konzept deckt eine Vielzahl unterschiedlicher Ansätze ab, um Daten auf der Festplatte und im Speicher zu organisieren und über eine Abfragesprache verfügbar zu machen (einige sind sogar SQL-ähnlich!). Meiner Ansicht nach liegt die Stärke in dieser Vielzahl von Systemen, sodass Sie das beste Werkzeug für den Job auswählen können. Hoffentlich können Sie ein Dutzend unterschiedlicher Anforderungen mit nur wenigen unterschiedlichen Lösungen abdecken, und Sie möchten nicht ein Dutzend unterschiedlicher Systeme verwalten.

Relationale Datenbanken können Sie sehr weit bringen und sind eine bewährte Technologie, aber genau wie die Datenbank möchten Sie möglicherweise die Programmiersprache basierend auf den Anforderungen jedes Projekts auswählen (wobei auch die Erfahrung des Teams berücksichtigt wird).

Ich benutze jetzt seit zwei Jahren couchdb. Es wird hauptsächlich für die Verwaltung und Konfiguration von Inhalten verwendet.

Hierarchische Beziehungen sind viel einfacher zu verwalten, wenn Sie sie visualisieren können. Bei meistens gelesenen Daten ist es in vielen Fällen einfacher, JSON zu bearbeiten, als eine UPDATE-Anweisung zu schreiben. Benötigt eigentlich keinen Programmierer, um JSON zu bearbeiten. Und SQL gibt Ihnen Zeilen und Spalten, die Sie dann in eine Art Objektstruktur abbilden müssen.

Sie erhalten auch eine Leistungssteigerung, weil Sie bei komplexen Abfragen nicht 10 bis 20 Tabellen beitreten. Couchdb-Ansichten sind sehr schnell, da das JavaScript, auf dem sie basieren, zum Zeitpunkt der Abfrage nicht ausgeführt wird.

Die meisten Programmierer verstehen Javascript, und die meisten Programmierer haben gelegentlich Probleme mit SQL.

In Couchdb kann eine Ansicht als Zusammenfassung eines JSON-Dokuments betrachtet werden. Wie die Ansichtsdaten strukturiert sind, bleibt Ihnen überlassen (Sie sind nicht an die ursprüngliche Hierarchie gebunden).

Ich würde Couchdb nicht für hochgradig transaktionale Daten verwenden, aber für semistatische Daten mit einer Struktur vom Typ Teileexplosion ist die Arbeit mit Couchdb VIEL einfacher als mit SQL.

Beachten Sie jedoch, dass es keine eindeutige 'Normalisierung' gibt, die angewendet werden kann (obwohl das Vermeiden von Datenduplikationen ein würdiges Ziel ist), und dass es im Wesentlichen eine 'optimistische' Aktualisierungsstrategie gibt, die einer optimistischen Sperrung ähnelt.