Ein Leitfaden zu NoSQL für Entwickler

Wenn Sie die Trends in der Backend-Entwicklung und Big Data verfolgt haben, haben Sie wahrscheinlich bereits die Begeisterung für NoSQL- Datenbanken in den letzten Jahren bemerkt. Einige Leute lassen sich von dieser Herangehensweise an die Datenbank inspirieren, während andere glauben, dass sich darin ein Trick verbirgt: Die darin enthaltenen Datenmodelle sind nicht die gleichen wie in den üblichen relationalen Datenbanken, die Anwendungsprogrammierschnittstellen sind ungewöhnlich und die Anwendungen sind oft unverständlich. In diesem Artikel erzähle ich Ihnen, warum es diese NoSQL-Datenbanken überhaupt gab, welche Probleme sie lösen und warum plötzlich so viele verschiedene Datenbanken benötigt werden. Wenn Sie NoSQL-Neuling sind, könnte Sie der letzte Teil des Artikels besonders interessieren, in dem die NoSQL-Datenbanktypen aufgeführt sind, die es meiner Meinung nach wert sind, zunächst untersucht zu werden, um ein umfassendes Verständnis des Fachgebiets zu erlangen.

Warum brauchen wir plötzlich eine neue Datenbank?

Sie fragen sich vielleicht: Was stimmt mit relationalen Datenbanken nicht? Der Punkt ist, dass sie viele Jahre lang wirklich gut funktioniert haben, aber jetzt gibt es ein Problem, das sie nicht mehr bewältigen können. Einigen Prognosen zufolge wird die Menschheit im Jahr 2018 50.000 Gigabyte an Daten pro Sekunde erzeugen. Das ist eine kolossale Datenmenge! Seine Lagerung und Handhabung stellt eine große technische Herausforderung dar. Noch schlimmer ist, dass dieses Volumen ständig wächst. Wie sich herausstellt, eignen sich relationale Datenbanken schlecht für die Arbeit mit wirklich großen Datenmengen. Sie sind für die Ausführung auf einem einzigen Computer konzipiert. Wenn Sie mehr Anfragen bearbeiten möchten, bleibt Ihnen nur der Kauf eines Computers mit mehr RAM und einem leistungsstärkeren Prozessor. Leider ist die Anzahl der Abfragen, die eine Maschine verarbeiten kann, begrenzt und für verteiltes Arbeiten auf mehreren Maschinen benötigen wir eine andere Datenbanktechnologie. Natürlich werden einige Leser an dieser Stelle schmunzeln und sagen, dass es zwei weit verbreitete Methoden für die Verwendung mehrerer Maschinen im Fall einer relationalen Datenbank gibt: Replikation und Sharding. Das stimmt, aber diese Methoden reichen nicht aus, um unsere Aufgaben zu bewältigen. Bei der Lesereplikation handelt es sich um eine Technik, bei der jede Datenbankaktualisierung an andere Computer weitergegeben wird, die nur Leseanforderungen verarbeiten können. In diesem Fall werden alle Änderungen von einem Server, dem sogenannten Masterknoten, durchgeführt, während andere Server, sogenannte Lesereplikate, nur Kopien der Daten verwalten. Der Benutzer kann von jeder der Maschinen lesen, die Daten jedoch nur über den Masterknoten ändern. Dies ist eine komfortable und sehr beliebte Methode, die jedoch nur die Verarbeitung von mehr Leseanfragen ermöglicht und das Problem der Verarbeitung der erforderlichen Datenmengen in keiner Weise löst. Sharding ist ein weiterer beliebter Ansatz, der mehrere Instanzen einer relationalen Datenbank verwendet. Jeder von ihnen übernimmt Schreib- und Lesevorgänge für einen Teil der Daten. Wenn eine Datenbank Informationen über Kunden speichert, beispielsweise mithilfe von Sharding, kann ein Computer alle Anfragen für Kunden bearbeiten, deren Namen mit A beginnen, ein anderer Computer kann alle Daten für Kunden speichern, deren Namen mit B beginnen, und so weiter. Obwohl Sie mit Sharding mehr Daten aufzeichnen können, ist die Verwaltung einer solchen Datenbank ein echter Albtraum: Sie müssen die Daten maschinenübergreifend ausrichten und den Cluster je nach Bedarf in beide Richtungen skalieren. Obwohl es in der Theorie einfach aussieht, ist es eine ziemliche Herausforderung, es richtig hinzubekommen.

Können relationale Datenbanken verbessert werden?

Ich denke, Sie sind bereits zu der Überzeugung gelangt, dass relationale Datenbanken für die in der modernen Welt erzeugten Datenmengen nicht optimal geeignet sind. Allerdings fragen Sie sich vielleicht immer noch, warum noch niemand eine „bessere“ relationale Datenbank erstellt hat, die effizient auf mehreren Computern ausgeführt werden kann. Es mag den Anschein haben, dass diese Technologie einfach noch nicht entwickelt ist und verteilte relationale Datenbanken sehr bald erscheinen werden. Leider wird das nicht passieren. Das ist mathematisch unmöglich und man kann nichts dagegen tun. Um zu verstehen, warum das so ist, müssen Sie sich das sogenannte CAP-Theorem (auch bekannt als Brewer-Theorem) ansehen. Es wurde 1999 nachgewiesen und besagt, dass eine verteilte Datenbank, die auf mehreren Computern läuft, die folgenden drei Eigenschaften haben kann: Konsistenz – jede Leseoperation gibt die Ergebnisse der letzten entsprechenden Schreiboperation zurück. Wenn das System konsistent ist, ist es nach dem Schreiben neuer Daten nicht möglich, die alten, bereits überschriebenen Daten zu lesen. Verfügbarkeit ( A- Verfügbarkeit) – ein verteiltes System kann eine eingehende Anfrage jederzeit bearbeiten und eine fehlerfreie Antwort zurückgeben. Partitionstoleranz – die Datenbank reagiert weiterhin auf Lese- und Schreibanfragen , auch wenn einige ihrer Server vorübergehend nicht miteinander kommunizieren können. Dieser vorübergehende Ausfall wird als Netzwerkverbindungsfehler bezeichnet und kann durch eine Vielzahl von Faktoren verursacht werden, von physischen Netzwerkproblemen aufgrund eines langsamen Servers bis hin zu physischen Schäden an Netzwerkgeräten. Alle diese Eigenschaften sind sicherlich praktisch, und wir würden uns wirklich wünschen, dass eine Datenbank sie alle kombiniert. Kein vernünftiger Entwickler würde beispielsweise auf Barrierefreiheit verzichten wollen, ohne dafür eine Gegenleistung zu erhalten. Leider besagt das CAP-Theorem auch, dass es unmöglich ist, dass alle drei Eigenschaften gleichzeitig gelten. Das zu erkennen ist vielleicht nicht einfach, aber es ist möglich. Erstens: Wenn wir eine verteilte Datenbank benötigen, muss diese „trennungstolerant“ sein. Darüber wird noch nicht einmal gesprochen. Es kommt immer wieder zu Verbindungsabbrüchen und trotzdem muss unsere Datenbank funktionieren. Lassen Sie uns nun verstehen, warum wir nicht sowohl Konsistenz als auch Verfügbarkeit erreichen können. Stellen Sie sich vor, wir haben eine einfache Datenbank, die auf zwei Maschinen läuft: A und B. Jeder Benutzer kann auf eine der beiden Maschinen schreiben, woraufhin die Daten auf die andere kopiert werden. Stellen Sie sich nun vor, dass diese Maschinen vorübergehend nicht in der Lage sind, miteinander zu kommunizieren, und Maschine B nicht in der Lage ist, Daten an Maschine A zu senden oder von ihr zu empfangen. Wenn Maschine B in diesem Zeitraum eine Leseanfrage von einem Client erhält, hat sie zwei Möglichkeiten:

1. Erhalten Sie Ihre lokalen Daten zurück, auch wenn diese nicht mehr aktuell sind. In diesem Fall wird der Verfügbarkeit der Vorzug gegeben (um zumindest einige Daten zurückzugeben, auch wenn sie veraltet sind).
2. Fehler zurückgeben. In diesem Fall wird Konsistenz bevorzugt: Der Client erhält keine veralteten Daten, aber überhaupt keine Daten.

Relationale Datenbanken streben danach, die Eigenschaften „Konsistenz“ und „Verfügbarkeit“ gleichzeitig zu verkörpern und können daher nicht in einer verteilten Umgebung betrieben werden. Der Versuch, alle Funktionen einer relationalen Datenbank in einem verteilten System zu implementieren, wird entweder unrealistisch oder schlichtweg undurchführbar sein . Andererseits legen NoSQL-Datenbanken Wert auf Skalierbarkeit und Leistung. Ihnen fehlen in der Regel „grundlegende“ Fähigkeiten wie Verbindungen und Transaktionen, und das Datenmodell erweist sich als völlig anders, vielleicht sogar in gewisser Weise einschränkend. All dies ermöglicht die Speicherung größerer Datenmengen und die Verarbeitung von mehr Abfragen als je zuvor.

Wie bringen NoSQL-Datenbanken Konsistenz und Verfügbarkeit in Einklang?

Wenn Sie sich für eine NoSQL-Datenbank entscheiden, kommt es Ihnen möglicherweise so vor, als würden Sie im Falle eines Fehlers immer entweder veraltete Daten oder eine Fehlermeldung erhalten. In der Praxis sind Verfügbarkeit und Konsistenz keineswegs die einzigen verfügbaren Optionen. Ihnen steht eine große Auswahl an Optionen zur Verfügung. Relationale Datenbanken verfügen nicht über diese Optionen, aber mit NoSQL können Sie die Abfrageausführung auf ähnliche Weise steuern. Auf die eine oder andere Weise ermöglichen sie Ihnen, zwei Parameter festzulegen, wenn Sie Schreib- oder Lesevorgänge in einer NoSQL-Datenbank ausführen: W – wie viele Maschinen im Cluster müssen das Speichern von Daten bestätigen, wenn ein Schreibvorgang ausgeführt wird . Je größer die Anzahl der Maschinen, auf denen Sie Ihre Daten schreiben, desto einfacher ist es, beim nächsten Lesevorgang die aktuellsten Daten zu lesen, aber auch desto länger dauert es. R – von wie vielen Maschinen möchten Sie Daten lesen ? In einem verteilten System kann die Verteilung von Daten an alle Maschinen in einem Cluster einige Zeit dauern, sodass einige Server über die neuesten Daten verfügen, während andere zurückbleiben. Je größer die Anzahl der Maschinen ist, von denen Daten gelesen werden, desto höher ist die Chance, aktuelle Daten zu lesen. Schauen wir uns ein praktisches Beispiel an. Wenn Sie fünf Computer in Ihrem Cluster haben und sich dafür entscheiden, Daten nur auf einen zu schreiben und dann Daten von einem zufällig ausgewählten Computer zu lesen, besteht eine 80-prozentige Chance, dass Sie veraltete Daten lesen. Andererseits wird dadurch ein Minimum an Ressourcen verbraucht. Wenn Sie also mit Altdaten zufrieden sind, ist das keine so schlechte Option. In diesem Fall sind die Parameter W und R gleich 1. Wenn Sie hingegen Daten auf alle fünf Maschinen in einer NoSQL-Datenbank schreiben, können Sie Daten von jeder Maschine lesen und erhalten garantiert jedes Mal aktuelle Daten. Die Durchführung desselben Vorgangs auf einer größeren Anzahl von Maschinen dauert länger. Wenn Ihnen jedoch aktuelle Daten wichtig sind, können Sie diese Option wählen. In diesem Fall ist W = R = 5. Wie viele Lese- und Schreibvorgänge sind für die Datenbankkonsistenz mindestens erforderlich? Hier ist eine einfache Formel: R + W ≥ N + 1 , wobei N die Anzahl der Maschinen im Cluster ist. Das bedeutet, dass Sie bei fünf Servern entweder R = 2 und W = 4 oder R = 3 und W = 3 oder R = 4 und W = 2 wählen können. In diesem Fall spielt es keine Rolle, an welche Maschinen die Daten gesendet werden geschrieben wird, erfolgt das Lesen immer von mindestens einer Maschine mit aktuellen Daten. Andere Datenbanken wie DynamoDB unterliegen anderen Einschränkungen und erlauben nur konsistente Schreibvorgänge. Jedes Datenelement wird auf drei Servern gespeichert, und wenn Daten geschrieben werden, werden sie auf zwei der drei Maschinen geschrieben. Beim Lesen von Daten können Sie jedoch eine von zwei Optionen wählen:

1. Strikt konsistenter Lesevorgang, bei dem Daten von zwei von drei Maschinen gelesen werden und immer die zuletzt geschriebenen Daten zurückgegeben werden.
2. Ein letztendlich konsistenter Lesevorgang, bei dem eine Maschine zufällig ausgewählt wird, von der die Daten gelesen werden sollen. Dies kann jedoch vorübergehend zu veralteten Daten führen.

Warum gibt es so viele NoSQL-Datenbanken?

Wenn Sie die neuesten Nachrichten im Bereich der Softwareentwicklung verfolgen, haben Sie wahrscheinlich schon von vielen verschiedenen NoSQL-Datenbanken gehört, wie zum Beispiel MongoDB, DynamoDB, Cassandra, Redis und vielen anderen. Sie fragen sich vielleicht: Warum brauchen wir so viele verschiedene NoSQL-Datenbanken? Der Grund ist einfach: Verschiedene NoSQL-Datenbanken sind darauf ausgelegt, unterschiedliche Probleme zu lösen. Aus diesem Grund ist die Zahl konkurrierender Datenbanken so groß. NoSQL-Datenbanken lassen sich in vier Hauptkategorien einteilen:

Dokumentorientierte Datenbanken

Diese Datenbanken bieten die Möglichkeit, komplexe verschachtelte Dokumente zu speichern, während die meisten relationalen Datenbanken nur eindimensionale Zeilen unterstützen. Diese Funktion kann in vielen Fällen nützlich sein, beispielsweise wenn es erforderlich ist, Informationen über einen Benutzer mit mehreren Adressen im System zu speichern. Wenn Sie eine dokumentenorientierte Datenbank verwenden, können Sie in diesem Fall einfach ein komplexes Objekt speichern, das ein Array von Adressen enthält, während Sie in einer relationalen Datenbank zwei Tabellen erstellen müssten: eine für Benutzerinformationen und eine für Adressen. Dokumentorientierte Datenbanken schließen die Lücke zwischen dem Objektmodell und dem Datenmodell. Einige relationale Datenbanken wie PostgreSQL unterstützen inzwischen auch die dokumentenorientierte Speicherung, den meisten relationalen Datenbanken fehlt diese Fähigkeit jedoch immer noch.

Schlüssel-/Wertdatenbanken

Schlüssel/Wert-Datenbanken implementieren normalerweise das einfachste NoSQL-Modell. Im Wesentlichen stellen sie Ihnen eine verteilte Hash-Tabelle zur Verfügung , die es Ihnen ermöglicht, Daten in einen bestimmten Schlüssel zu schreiben und sie damit zurückzulesen. Schlüssel/Wert-Datenbanken sind hoch skalierbar und weisen eine deutlich geringere Latenz als andere Datenbanken auf.

Graphdatenbanken

Viele Themenbereiche, beispielsweise soziale Netzwerke oder Informationen zu Filmen und Schauspielern, können als Diagramme dargestellt werden. Obwohl das Diagramm mithilfe einer relationalen Datenbank dargestellt werden kann, ist dies schwierig und unpraktisch. Wenn Sie Diagrammdaten benötigen, ist es besser, eine spezielle Diagrammdatenbank zu verwenden, die Informationen über das Diagramm in einem verteilten Cluster speichern kann und es ermöglicht, Algorithmen effizient auf Diagrammen zu implementieren.

Spaltendatenbanken

Der Hauptunterschied zwischen spaltenbasierten und anderen Arten von Datenbanken besteht in der Art und Weise, wie die Daten auf der Festplatte gespeichert werden. Relationale Datenbanken erstellen für jede Tabelle eine Datei und speichern die Werte für alle Zeilen nacheinander. Spaltendatenbanken erstellen eine Datei für jede Spalte in Ihren Tabellen. Mit dieser Struktur können Sie Daten aggregieren und bestimmte Abfragen effizienter ausführen. Sie müssen jedoch sicherstellen, dass die Daten den Einschränkungen solcher Datenbanken entsprechen.

Welche Datenbank sollten Sie wählen?

Die Auswahl einer Datenbank ist normalerweise ein frustrierendes Problem, und bei so vielen verfügbaren Optionen kann es wie eine überwältigende Aufgabe erscheinen. Die gute Nachricht ist, dass es nicht nötig ist, sich nur für eines zu entscheiden. Anstatt eine einzige monolithische Anwendung zu erstellen, die alle Funktionen implementiert und Zugriff auf alle Systemdaten hat, können Sie ein anderes modernes Muster namens Microservices verwenden : Teilen Sie die Anwendung in eine Reihe unabhängiger Dienste auf. Jeder Dienst löst sein eigenes enges Problem und verwendet nur seine eigene Datenbank, die zur Lösung dieses Problems am besten geeignet ist.

Wie soll man das alles lernen?

Bei so vielen Datenbanken kann es wie eine unmögliche Aufgabe erscheinen, sie alle zu lernen. Die gute Nachricht: Sie müssen das nicht tun. Es gibt nur wenige Grundtypen von NoSQL-Datenbanken, und wenn Sie verstehen, wie sie funktionieren, werden die anderen viel einfacher zu verstehen sein. Außerdem werden einige NoSQL-Datenbanken viel häufiger verwendet als andere, daher ist es am besten, Ihre Bemühungen auf die gängigsten Lösungen zu konzentrieren. Hier ist eine Liste der am häufigsten verwendeten NoSQL-Datenbanken, die Sie sich meiner Meinung nach ansehen sollten:

1. MongoDB . Wahrscheinlich die beliebteste NoSQL-Datenbank auf dem Markt. Wenn ein Unternehmen keine relationale Datenbank als primären Datenspeicher verwendet, verwendet es wahrscheinlich MongoDB. Dies ist ein flexibler Dokumentenspeicher mit einer guten Auswahl an Werkzeugen. Zu Beginn seiner Karriere hatte MongoDB den schlechten Ruf, in einigen Fällen Daten zu verlieren , aber seitdem haben sich seine Stabilität und Zuverlässigkeit erheblich verbessert. Schauen Sie sich diesen MongoDB-Kurs an , wenn Sie mehr erfahren möchten.


2. DynamoDB . Wenn Sie Amazon Web Services (AWS) nutzen, sollten Sie mehr über DynamoDB erfahren. Es handelt sich um eine äußerst zuverlässige, skalierbare Datenbank mit geringer Latenz, umfangreichem Funktionsumfang und Integration in viele andere AWS-Dienste. Das Beste daran ist, dass Sie es nicht selbst bereitstellen müssen. Das Einrichten eines skalierbaren DynamoDB-Clusters, der Tausende von Abfragen verarbeiten kann, ist nur ein paar Klicks entfernt. Wenn Sie das interessiert, können Sie sich diesen Kurs ansehen.


3. Neo4j . Die gebräuchlichste Graphdatenbank. Dies ist eine skalierbare und stabile Lösung, die für diejenigen geeignet ist, die ein Diagrammdatenmodell verwenden möchten. Wenn Sie mehr erfahren möchten, beginnen Sie mit diesem Kurs .


4. Redis . Während die anderen hier beschriebenen Datenbanken zum Speichern von Kernanwendungsdaten verwendet werden, wird Redis hauptsächlich zum Implementieren von Caches und zum Speichern von Hilfsdaten verwendet. In vielen Fällen wird eine der oben genannten Datenbanken zusammen mit Redis verwendet. Um mehr zu erfahren, schauen Sie sich diesen Kurs an.

Im Jahr 2018 mit NoSQL

NoSQL-Datenbanken sind ein riesiges und schnell wachsendes Feld. Sie ermöglichen die Speicherung und Verarbeitung bisher unvorstellbarer Datenmengen, sind jedoch mit Kosten verbunden. Diese Datenbanken verfügen nicht über viele der Funktionen, die Sie von relationalen Datenbanken kennen, und es kann schwierig sein, sich auf deren Verwendung vorzubereiten. Aber sobald Sie den Dreh raus haben, können Sie skalierbare, verteilte Datenbanken erstellen, die erstaunliche Mengen an Lese- und Schreibanfragen verarbeiten können, was äußerst wichtig sein kann, da immer größere Datenmengen generiert werden. Original: https://simpleprogrammer.com/guide-nosql-software-developers/