Gemeinsame Features von NoSQL - Dummies

NoSQL-Bücher und -Blogs bieten unterschiedliche Meinungen darüber, was eine NoSQL-Datenbank ist. Vier Kernfeatures von NoSQL, die in der folgenden Liste aufgeführt sind, gelten für die meisten NoSQL-Datenbanken. Die Liste vergleicht NoSQL mit dem herkömmlichen relationalen DBMS:

• Schema-agnostisch: Ein Datenbankschema ist die Beschreibung aller möglichen Daten- und Datenstrukturen in einer relationalen Datenbank. Bei einer NoSQL-Datenbank ist kein Schema erforderlich, sodass Sie Informationen speichern können, ohne dass ein vordefiniertes Schemadesign erforderlich ist.

• Nicht relational: Beziehungen in einer Datenbank stellen Verbindungen zwischen Datentabellen her. Zum Beispiel kann eine Liste von Transaktionsdetails mit einer separaten Liste von Übermittlungsdetails verbunden werden. Bei einer NoSQL-Datenbank werden diese Informationen als ein Aggregat gespeichert - ein einzelner Datensatz mit allem über die Transaktion, einschließlich der Lieferadresse.

• Commodity-Hardware: Einige Datenbanken sind so ausgelegt, dass sie am besten (oder nur) mit spezieller Speicher- und Verarbeitungshardware arbeiten. Mit einer NoSQL-Datenbank können kostengünstige Standardserver verwendet werden. Durch Hinzufügen weiterer dieser preiswerten Server können NoSQL-Datenbanken für die Verarbeitung von mehr Daten skaliert werden.

• Hochverteilbar: Verteilte Datenbanken können eine Reihe von Informationen auf mehr als einem Gerät speichern und verarbeiten. Mit einer NoSQL-Datenbank kann ein Cluster von Servern verwendet werden, um eine einzelne große Datenbank zu speichern.

Schema-agnostisch

NoSQL-Datenbanken sind schemagermanistisch. Es ist nicht erforderlich, vor der Speicherung von Daten in NoSQL-Datenbanken viele Vorarbeiten zu erledigen. Sie können mit dem Codieren beginnen und Daten speichern und abrufen, ohne zu wissen, wie die Datenbank intern gespeichert und funktioniert. (Wenn Sie erweiterte Funktionen benötigen, können Sie manuell weitere Indizes hinzufügen oder Datenspeicherstrukturen optimieren.) Schema-Agnostizismus kann der wichtigste Unterschied zwischen NoSQL und relationalen Datenbanken sein.

Der große Vorteil einer schema-agnostischen Datenbank besteht darin, dass die Entwicklungszeit verkürzt wird. Dieser Vorteil steigt, wenn Sie mehrere Entwicklungsversionen durchlaufen und die internen Datenstrukturen in der Datenbank ändern müssen.

In einem herkömmlichen RDBMS durchlaufen Sie beispielsweise einen Prozess der Schema-Neugestaltung. Das Schema weist die Datenbank an, welche Daten zu erwarten sind. Ändern Sie die gespeicherten Daten oder Strukturen, und Sie müssen die Datenbank mithilfe eines geänderten Schemas neu erstellen. Wenn Sie eine Änderung vornehmen würden, müssten Sie viel Zeit damit verbringen zu entscheiden, wie Sie die vorhandenen Daten umstrukturieren möchten. In NoSQL-Datenbanken speichern Sie einfach eine andere Datenstruktur. Sie müssen die Datenbank nicht vorher mitteilen.

Möglicherweise müssen Sie Ihre Abfragen entsprechend ändern. Fügen Sie möglicherweise den gelegentlichen spezifischen -Index hinzu (z. B. einen ganzzahligen Bereichsindex, um weniger als und mehr als datentypabhängige Abfragen zuzulassen). viel weniger schmerzhaft als es mit einem RDBMS ist.

Das RDBMS wurde aufgrund seiner Flexibilität gestartet und durch die Verwendung von SQL beschleunigte es die Änderung einer Abfrage. NoSQL-Datenbanken bieten diese Flexibilität, um sowohl das Schema als auch die Abfrage zu ändern, was einer der Hauptgründe dafür ist, dass sie im Laufe der Zeit zunehmend übernommen werden.

Auch bei der Abfrage müssen Sie sich nicht zu sehr um die Kenntnis der Schemaänderungen kümmern - betrachten Sie einen Index über eine Feldkontonummer, wobei Kontonummer überall in einem Dokument gespeichert werden kann, eine NoSQL-Datenbank. Sie können die Struktur ändern und verschieben, wo Kontonummer gespeichert ist, und wenn das Element an anderer Stelle im Dokument den gleichen Namen hat, steht es weiterhin zur Abfrage zur Verfügung, ohne dass Änderungen am Abfragemechanismus vorgenommen werden müssen.

Beachten Sie, dass nicht alle NoSQL-Datenbanken vollständig schema- agnostisch sind. Bei einigen wie HBase müssen Sie die Datenbank anhalten, um Spaltendefinitionen zu ändern. Sie werden immer noch als NoSQL-Datenbanken betrachtet, da nicht alle definierten Felder (in diesem Fall Spalten) im Voraus für jeden Datensatz bekannt sein müssen - nur die Spaltenfamilien.

Mit RDBMS können einzelne Felder in Datensätzen als Null -Werte identifiziert werden. Das Problem mit einem RDBMS besteht darin, dass die Größe und Leistung der gespeicherten Daten negativ beeinflusst werden, wenn der Speicher für Nullwerte reserviert wird, nur für den Fall, dass der Datensatz irgendwann in der betreffenden Spalte einen Wert hat. In Cassandra stellen Sie einfach nicht die Daten dieser Spalte zur Verfügung, wodurch das Problem gelöst wird.

Nicht relational

Relationale Datenbankverwaltungssysteme waren seit mehr als 20 Jahren die dominante Methode zum Speichern von Anwendungsdaten. Es wurde viel mathematische Arbeit geleistet, um die zugrundeliegende Theorie zu beweisen.

Diese Untermauerung beschreibt, wie sich Tabellen zueinander verhalten. Eine einzelne Order-Zeile kann sich auf viele Delivery Address-Zeilen beziehen, aber jede Delivery Address-Zeile bezieht sich auch auf mehrere Order-Zeilen. Dies ist eine Viel - bis - Vielfache Beziehung .

NoSQL-Datenbanken haben dieses Konzept von Beziehungen zwischen ihren Datensätzen nicht. Stattdessen deormalisieren sie Daten. Dies bedeutet, dass in einer NoSQL-Datenbank eine Bestellstruktur mit der Lieferadresse eingebettet wäre. Das bedeutet, dass die Lieferadresse in jeder Bestellzeile dupliziert wird, in der sie verwendet wird. Dieser Ansatz hat den Vorteil, dass keine komplexen Abfragezeit-Joins über mehrere Datenstrukturen (Tabellen) erforderlich sind.

In NoSQL-Datenbanken werden keine Informationen darüber gespeichert, wie sich einzelne Datensätze auf andere Datensätze in der Datenbank beziehen, was sich als Einschränkung anhört. NoSQL-Datenbanken sind jedoch flexibler hinsichtlich der Datenstrukturen, die Sie speichern können.

Betrachten Sie eine Bestellung von einem Online-Händler. Die Bestellung kann Produktcodes, Mengen, Artikelpreise und Artikelbeschreibungen sowie Informationen über die bestellende Person enthalten, z. B. Lieferadresse und Zahlungsinformationen.

Anstatt zehn Zeilen in eine Vielzahl von Tabellen in einer relationalen Datenbank einzufügen, können Sie stattdessen eine einzelne Struktur für alle diese Bestellinformationen speichern - zum Beispiel als JSON- oder XML-Dokument.

In der relationalen Datenbanktheorie ist es das Ziel, Ihre Daten zu zu normalisieren (das heißt, die Felder und Tabellen zu organisieren, um doppelte Daten zu entfernen). In NoSQL-Datenbanken - insbesondere in Dokument- oder Aggregatdatenbanken - deormalisieren Sie häufig Daten absichtlich und speichern einige Daten mehrfach.

Sie können z. B. die "Lieferadresse des Kunden" für viele Bestellungen, die ein Kunde im Laufe der Zeit erstellt, mehrmals speichern, anstatt sie einmal zu speichern und in mehreren Bestellungen darauf zu verweisen. Dies erfordert zusätzlichen Speicherplatz und ein wenig Sorgfalt bei der Verwaltung Ihrer Anwendung. Warum also?

Es gibt zwei Vorteile beim mehrfachen Speichern von Daten:

• Einfaches Speichern und Abrufen: Einfach speichern und einen einzelnen Datensatz erhalten.

• Abfragegeschwindigkeit: In relationalen Datenbanken verknüpfen Sie Informationen und fügen Abhängigkeiten zwischen Tabellen zur Abfragezeit hinzu. Dies kann erfordern, dass das Datenbankmodul viele Tabellen auswertet. Je mehr Abfragebeschränkungen Sie in verschiedenen Tabellen haben, desto mehr reduzieren Sie die Abfragegeschwindigkeit. (Aus diesem Grund verfügt ein RDBMS über vorab berechnete Ansichten.) In einer NoSQL-Datenbank befinden sich alle Informationen, die Sie für die Auswertung Ihrer Abfrage benötigen, in einem einzigen Dokument. Daher können Sie schnell die Liste der übereinstimmenden Dokumente ermitteln.

Relationale Ansichten und NoSQL-Denormalisierungen sind unterschiedliche Ansätze für das Problem der Datenverteilung in Datensätzen. In NoSQL müssen Sie möglicherweise mehrere Denormalisierungen pflegen, die unterschiedliche Sichten auf dieselben Daten darstellen. Dieser Ansatz erhöht die Speicherkosten, bietet jedoch eine viel bessere Abfragezeit.

In Anbetracht der ständig sinkenden Speicherkosten und der erhöhten Geschwindigkeit der Entwicklung und Abfrage sind denormalisierte Daten (auch materialisierte Views ) kein toller Grund, NoSQL-Lösungen zu diskontieren. Es ist nur ein anderer Weg, um das gleiche Problem anzugehen, mit seinen eigenen Vor- und Nachteilen.

NoSQL ist hochverteilbar und verwendet Standardhardware

In vielen NoSQL-Datenbanken besteht eine wichtige Entwurfsentscheidung darin, mehrere Computer zum Speichern von Daten für eine einzelne Datenbank zu verwenden, anstatt die gesamte Datenbank auf einem einzelnen Server zu haben.

Es ist schwierig, Daten auf mehreren Maschinen zu speichern und abfragen zu können. Sie müssen die Abfrage an alle Server senden und auf eine Antwort warten. Hoffentlich richten Sie die Maschinen so ein, dass sie schnell genug sind, um miteinander zu kommunizieren und verteilte Abfragen zu bearbeiten!

Der Hauptvorteil dieses Ansatzes liegt im Fall sehr großer Datenmengen, da für einige Speicheranforderungen selbst der größte verfügbare einzelne Server nicht alle Daten speichern oder verarbeiten kann, die Sie benötigen. Betrachten Sie alle Nachrichten auf Twitter und Facebook. Sie benötigen einen verteilten Mechanismus, um all diese Daten effektiv zu verwalten, auch wenn es hauptsächlich darum geht, was die Leute zum Frühstück und niedlichen Katzenvideos hatten.

Ein Vorteil der Verteilung Ihrer Datenbank ist, dass Sie billigere Server verwenden können, die Commodity-Server genannt werden.Selbst für kleinere Datensätze kann es günstiger sein, drei Standardserver anstelle eines einzelnen, leistungsstärkeren Servers zu kaufen.

Ein weiterer wichtiger Vorteil ist, dass das Hinzufügen einer hohen Verfügbarkeit einfacher ist. Sie sind schon halbwegs da, indem Sie Ihre Daten verteilen. Wenn Sie Ihre Daten ein- oder zweimal auf andere Server im Cluster replizieren, können Sie auf Ihre Daten auch dann zugreifen, wenn einer der Server abstürzt, brennt und abstürzt.

Nicht alle Open-Source-Datenbanken unterstützen eine hohe Verfügbarkeit, es sei denn, Sie kaufen die unterstützte, bezahlte Version der Datenbank von dem Unternehmen, das sie entwickelt.

Eine Ausnahme von der stark verteilbaren Regel ist die von Graphdatenbanken. Um bestimmte Graphenabfragen zeitgerecht zu beantworten, müssen Daten auf einem einzigen Server gespeichert werden. Niemand hat dieses spezielle Problem bisher gelöst.

Überlegen Sie sorgfältig, ob Sie einen Dreifachladen oder einen Graphenspeicher benötigen. Dreifachgeschäfte sind allgemein verteilbar, wohingegen Graphenspeicher dies nicht sind. Welche Sie benötigen, hängt von den Fragen ab, die Sie unterstützen müssen.