NoSQL-Tutorial: Arten von NoSQL-Datenbanken & Beispiel

Was ist NoSQL?

NoSQL-Datenbank NoSQL ist ein nicht-relationales Datenverwaltungssystem, das kein festes Schema benötigt. Es vermeidet Joins und ist leicht skalierbar. Hauptzweck einer NoSQL-Datenbank ist die Speicherung verteilter Daten mit enormen Speicheranforderungen. NoSQL wird für Big Data und Echtzeit-Webanwendungen eingesetzt. Beispiele hierfür sind Unternehmen wie Twitter, Facebook und Co. Google Sammeln jeden Tag Terabytes an Nutzerdaten.

NoSQL-Datenbank NoSQL steht für „Not Only SQL“ oder „Not SQL“. Obwohl „NoREL“ eine treffendere Bezeichnung wäre, hat sich NoSQL durchgesetzt. Carl Strozzi führte das NoSQL-Konzept 1998 ein.

Traditionelle relationale Datenbankmanagementsysteme (RDBMS) verwenden die SQL-Syntax, um Daten zu speichern und abzurufen und so weitere Erkenntnisse zu gewinnen. Ein NoSQL-Datenbanksystem hingegen umfasst eine breite Palette von Datenbanktechnologien, die strukturierte, semistrukturierte, unstrukturierte und polymorphe Daten speichern können. In diesem Tutorial zu NoSQL-Datenbanken erfahren Sie mehr darüber anhand eines Diagramms.

Warum NoSQL?

Das Konzept der NoSQL-Datenbanken wurde bei Internetgiganten wie Google, Facebook, Amazonusw., die mit riesigen Datenmengen umgehen. Die Systemreaktionszeit wird langsam, wenn Sie RDBMS für große Datenmengen verwenden.

Um dieses Problem zu lösen, könnten wir unsere Systeme „skalieren“, indem wir unsere vorhandene Hardware aufrüsten. Dieser Prozess ist teuer.

Die Alternative zu diesem Problem besteht darin, die Datenbanklast bei steigender Last auf mehrere Hosts zu verteilen. Diese Methode wird als „Scale-out“ bezeichnet.

NoSQL-Datenbanken sind nicht-relational und skalieren daher besser als relationale Datenbanken, da sie speziell für Webanwendungen konzipiert wurden.

Kurze Geschichte der NoSQL-Datenbanken

• 1998 – Carlo Strozzi verwendet den Begriff NoSQL für seine leichtgewichtige, quelloffene relationale Datenbank.
• 2000 – Graphdatenbank Neo4j wird eingeführt.
• 2004 - Google BigTable wurde gestartet.
• 2005 - CouchDB gestartet.
• 2007 – Die Forschungsarbeit über Amazon Dynamo ist erschienen.
• 2008 – Facebook veröffentlicht die Quellcodes Cassandra Projekt einfliessen.
• 2009 – Der Begriff NoSQL wurde wieder eingeführt.

Funktionen von NoSQL

Nicht relational

• NoSQL-Datenbanken folgen niemals dem relationales Modell.
• Verwenden Sie niemals Tabellen mit flachen, spaltenlosen Datensätzen.
• Arbeiten Sie mit in sich geschlossenen Aggregaten oder BLOBs.
• Objektrelationale Abbildung nicht erforderlichping und Datennormalisierung.
• Keine komplexen Funktionen wie Abfragesprachen, Abfrageplaner, referenzielle Integritätsverknüpfungen oder ACID.

Schemafrei

• NoSQL-Datenbanken sind entweder schemalos oder verfügen über lockere Schemata.
• Eine Definition des Datenschemas ist nicht erforderlich.
• Bieten Sie heterogene Datenstrukturen im selben Bereich an.

Einfache API

• Bietet benutzerfreundliche Schnittstellen zum Speichern und Abfragen von Daten.
• APIs ermöglichen Methoden zur Datenmanipulation und -auswahl auf niedriger Ebene.
• Textbasierte Protokolle werden hauptsächlich mit HTTP REST und JSON verwendet.
• Meist wurde eine nicht standardbasierte NoSQL-Abfragesprache verwendet.
• Webfähige Datenbanken, die als internetbasierte Dienste betrieben werden.

Verteilt

• Mehrere NoSQL-Datenbanken können verteilt ausgeführt werden.
• Bietet automatische Skalierungs- und Ausfallsicherungsfunktionen.
• Das ACID-Konzept muss oft zugunsten von Skalierbarkeit und Durchsatz vernachlässigt werden.
• Meist keine synchrone Replikation zwischen verteilten Knoten; asynchrone Multi-Master-Replikation, Peer-to-Peer-Replikation, HDFS-Replikation.
• Gewährleistet lediglich letztendliche Konsistenz.
• Shared-Nothing-Architektur. Dies ermöglicht weniger Koordination und eine höhere Verteilung.

Arten von NoSQL-Datenbanken

NoSQL-Datenbanken Datenbanken lassen sich hauptsächlich in vier Typen unterteilen: Schlüssel-Wert-Paar-Datenbanken, spaltenorientierte Datenbanken, graphbasierte Datenbanken und dokumentenorientierte Datenbanken. Jede Kategorie hat ihre spezifischen Eigenschaften und Einschränkungen. Keine der genannten Datenbanken eignet sich optimal für alle Anwendungsfälle. Anwender sollten die Datenbank anhand ihrer Produktanforderungen auswählen.

Arten von NoSQL-Datenbanken:

• Basierend auf Schlüssel-Wert-Paaren
• Spaltenorientiertes Diagramm
• Graphenbasiert
• Dokumentenorientiert

Basierend auf Schlüsselwertpaaren

Daten werden in Schlüssel-Wert-Paaren gespeichert. Dieses System ist für die Verarbeitung großer Datenmengen und hoher Lasten ausgelegt. Datenbanken, die Schlüssel-Wert-Paare speichern, verwenden Hashtabellen, in denen jeder Schlüssel eindeutig ist und der Wert beispielsweise JSON, BLOB (Binary Large Objects) oder eine Zeichenkette sein kann.

Ein Schlüssel-Wert-Paar kann beispielsweise einen Schlüssel wie „Website“ enthalten, der mit einem Wert wie „Guru99 ".

Es handelt sich um eines der einfachsten Beispiele für NoSQL-Datenbanken. Diese Art von NoSQL-Datenbank wird für Sammlungen, Wörterbücher, assoziative Arrays usw. verwendet. Key-Value-Speicher helfen Entwicklern, schemalose Daten zu speichern. Sie eignen sich besonders für Shops.ping Warenkorbinhalt.

Redis, Dynamo und Riak sind einige Beispiele für NoSQL-Key-Value-Datenbanken. Sie basieren alle auf … Amazon’s Dynamo-Papier.

Spaltenbasiert

Spaltenorientierte Datenbanken arbeiten mit Spalten und basieren auf der BigTable-Veröffentlichung von [Name des Autors]. GoogleJede Spalte wird separat behandelt. Werte von einspaltigen Datenbanken werden zusammenhängend gespeichert.

Sie bieten eine hohe Leistung bei Aggregationsabfragen wie SUMME, ANZAHL, AVG, MIN usw., da die Daten direkt in einer Spalte verfügbar sind. Spaltenbasierte NoSQL-Datenbanken werden häufig zur Verwaltung von Data Warehouses verwendet. Business Intelligence, CRM und Bibliothekskataloge.

HBase, CassandraHypertable und NoSQL-Abfragebeispiele für spaltenbasierte Datenbanken sind Beispiele für NoSQL-Abfragen.

Dokumentenorientiert

Dokumentenorientierte NoSQL-Datenbanken speichern und rufen Daten als Schlüssel-Wert-Paare ab, wobei der Wert als Dokument gespeichert wird. Dieses Dokument wird im JSON- oder XML-Format gespeichert. Der Wert wird von der Datenbank verstanden und kann abgefragt werden.

Im Diagramm links sehen Sie Zeilen und Spalten, rechts eine Dokumentendatenbank mit einer ähnlichen Struktur wie JSON. Bei einer relationalen Datenbank müssen Sie die Spaltenstruktur kennen usw. Eine Dokumentendatenbank hingegen speichert Daten wie ein JSON-Objekt. Sie müssen diese nicht definieren, was sie flexibel macht.

Dieser Dokumenttyp wird hauptsächlich für CMS-Systeme, Blog-Plattformen, Echtzeit-Analysen und E-Commerce-Anwendungen verwendet. Er sollte nicht für komplexe Transaktionen eingesetzt werden, die mehrere Operationen oder Abfragen gegen unterschiedliche Aggregatstrukturen erfordern.

Amazon SimpleDB, CouchDB, MongoDBRiak und Lotus Notes sind beliebte dokumentenorientierte Programme. DBMS-Systeme.

Graphbasiert

Eine Graphdatenbank speichert Entitäten sowie die Beziehungen zwischen diesen Entitäten. Die Entität wird als Knoten und die Beziehung als Kante gespeichert. Eine Kante stellt eine Beziehung zwischen zwei Knoten dar. Jeder Knoten und jede Kante besitzt eine eindeutige Kennung.

Im Gegensatz zu relationalen Datenbanken, in denen Tabellen lose miteinander verknüpft sind, ist eine Graphdatenbank multirelational. Das Durchlaufen von Beziehungen ist schnell, da diese bereits in der Datenbank erfasst sind und nicht berechnet werden müssen. Graphbasierte Datenbanken werden hauptsächlich für soziale Netzwerke, Logistik und Geodaten eingesetzt.

Neo4J, Unendlicher Graph, OrientDB, und FlockDB sind einige populäre graphbasierte Datenbanken.

Abfragemechanismus-Tools für NoSQL

Der gebräuchlichste Mechanismus zum Abrufen von Daten ist der REST-basierte Abruf eines Wertes anhand seines Schlüssels/seiner ID mit einer GET-Ressource.

Dokumentenspeicherdatenbanken ermöglichen komplexere Abfragen, da sie den Wert eines Schlüssel-Wert-Paares verstehen. Zum Beispiel: CouchDB ermöglicht die Definition von Ansichten mit MapReduce.

Was ist das CAP-Theorem?

Das CAP-Theorem wird auch Brewer-Theorem genannt. Es besagt, dass ein verteilter Datenspeicher unmöglich mehr als zwei von drei Garantien bieten kann:

1. Konsistenz
2. Verfügbarkeit
3. Partitionstoleranz

Konsistenz: Die Daten sollten auch nach der Ausführung einer Operation konsistent bleiben. Das bedeutet, dass alle zukünftigen Leseanforderungen die Daten enthalten sollten, sobald sie geschrieben wurden. Beispielsweise sollten nach der Aktualisierung des Bestellstatus alle Clients dieselben Daten sehen können.

Verfügbarkeit: Die Datenbank sollte immer verfügbar und reaktionsfähig sein. Es sollte keine Ausfallzeiten geben.

Partitionstoleranz: Partitionstoleranz bedeutet, dass das System auch dann weiter funktionieren sollte, wenn die Kommunikation zwischen den Servern nicht stabil ist. Beispielsweise können die Server in mehrere Gruppen aufgeteilt werden, die möglicherweise nicht miteinander kommunizieren. Wenn hier ein Teil der Datenbank nicht verfügbar ist, bleiben andere Teile immer davon unberührt.

Eventuelle Konsistenz

Der Begriff „eventuelle Konsistenz“ bedeutet, Datenkopien auf mehreren Rechnern zu speichern, um hohe Verfügbarkeit und Skalierbarkeit zu gewährleisten. Änderungen an Daten auf einem Rechner müssen daher automatisch auf alle anderen Kopien übertragen werden.

Die Datenreplikation erfolgt möglicherweise nicht sofort, da einige Kopien umgehend aktualisiert werden, andere jedoch erst später. Diese Kopien können zunächst inkonsistent sein, gleichen sich aber im Laufe der Zeit an. Daher der Name „eventuelle Konsistenz“.

BASE: Basisch Averfügbar, Soft angeben, Eendgültige Konsistenz

• Im Prinzip bedeutet „verfügbar“, dass die Datenbank gemäß dem CAP-Theorem jederzeit verfügbar ist.
• „Soft State“ bedeutet, dass sich der Systemzustand auch ohne Eingabe ändern kann.
• Eventuelle Konsistenz bedeutet, dass das System im Laufe der Zeit konsistent wird.

Vorteile von NoSQL

• Kann als primäre oder analytische Datenquelle verwendet werden.
• Big-Data-Fähigkeiten.
• Keine zentrale Fehlerquelle.
• Einfache Replikation.
• Eine separate Caching-Schicht ist nicht erforderlich.
• Es bietet schnelle Leistung und horizontale Skalierbarkeit.
• Kann strukturierte, semistrukturierte und unstrukturierte Daten gleichermaßen gut verarbeiten.
• Objektorientierte Programmierung, die einfach zu bedienen und flexibel ist.
• NoSQL-Datenbanken benötigen keinen dedizierten Hochleistungsserver.
• Unterstützung wichtiger Entwicklersprachen und -plattformen.
• Einfacher zu implementieren als mit einem relationalen Datenbankmanagementsystem (RDBMS).
• Es kann als primäre Datenquelle für Online-Bewerbungen dienen.
• Verarbeitet Big Data und bewältigt Datengeschwindigkeit, -vielfalt, -volumen und -komplexität.
• Ausgezeichnete Fähigkeiten im Betrieb verteilter Datenbanken und mehrerer Rechenzentren.
• Dadurch entfällt die Notwendigkeit einer separaten Caching-Schicht zur Datenspeicherung.
• Bietet ein flexibles Schema-Design, das sich problemlos ohne Ausfallzeiten oder Serviceunterbrechungen ändern lässt.

Nachteile von NoSQL

• Keine Standardisierungsregeln.
• Begrenzte Abfragemöglichkeiten.
• RDBMS Die Datenbanken und Werkzeuge sind vergleichsweise ausgereift.
• Es bietet keine herkömmlichen Datenbankfunktionen, wie etwa Konsistenz bei der gleichzeitigen Ausführung mehrerer Transaktionen.
• Wenn das Datenvolumen zunimmt, wird es schwierig, eindeutige Werte beizubehalten, da die Schlüssel immer schwieriger zu verwalten sind.
• Funktioniert nicht so gut mit relationalen Daten.
• Die Lernkurve für neue Entwickler ist steil.
• Open-Source-Lösungen sind für Unternehmen nicht so beliebt.

Häufig gestellte Fragen