Eigenschaften von NoSQL-Datenbanken

2.1 Entstehung des Begriffs NoSQL

In letzter Zeit ist der Begriff „NoSQL“ sehr in Mode gekommen und beliebt, unter diesem Zeichen werden alle Arten von Softwarelösungen aktiv entwickelt und gefördert. NoSQL ist zum Synonym für riesige Datenmengen, lineare Skalierbarkeit, Cluster, Fehlertoleranz und Nichtrelationalität geworden. Allerdings haben nur wenige Menschen ein klares Verständnis davon, was NoSQL-Speicher ist, wie der Begriff entstand und welche gemeinsamen Merkmale sie haben. Versuchen wir, diese Lücke zu schließen.

Das Interessanteste an dem Begriff ist, dass er trotz der Tatsache, dass er erstmals Ende der 90er Jahre verwendet wurde, in der Form, in der er jetzt verwendet wird, erst Mitte 2009 eine wirkliche Bedeutung erlangte. Ursprünglich war dies der Name eines Open -Quelldatenbank, erstellt von Carlo Strozzi, die alle Daten als ASCII-Dateien speicherte und für den Zugriff auf die Daten Shell-Skripte anstelle von SQL verwendete. Mit „NoSQL“ in seiner jetzigen Form hatte es nichts zu tun.

Im Juni 2009 organisierte Johan Oskarsson ein Treffen in San Francisco, um neue Trends auf dem Markt für IT-Speicher und -Verarbeitung zu diskutieren. Der Hauptimpuls für das Treffen waren neue Open-Source-Produkte wie BigTable und Dynamo. Für ein leuchtendes Zeichen für ein Meeting musste ein umfassender und prägnanter Begriff gefunden werden, der perfekt in den Twitter-Hashtag passt. Einer dieser Begriffe wurde von Eric Evans von RackSpace vorgeschlagen – „NoSQL“. Der Begriff war nur für ein Treffen geplant und hatte keine tiefe semantische Belastung, verbreitete sich jedoch wie eine virale Werbung im gesamten globalen Netzwerk und wurde de facto zum Namen einer ganzen Richtung in der IT-Branche. Auf der Konferenz sprachen übrigens Voldemort (Amazon Dynamo-Klon), Cassandra, Hbase (Analoga von Google BigTable), Hypertable, CouchDB und MongoDB.

Es ist noch einmal hervorzuheben, dass der Begriff „NoSQL“ völlig spontanen Ursprungs ist und keine allgemein anerkannte Definition oder wissenschaftliche Institution dahinter steht. Dieser Name bezeichnet eher den Vektor der IT-Entwicklung weg von relationalen Datenbanken. Es steht für Not Only SQL, obwohl es Befürworter der direkten Definition von No SQL gibt. Pramod Sadalaj und Martin Fowler haben in ihrem aktuellen Buch „NoSQL Distilled“ versucht, Wissen über die NoSQL-Welt zu gruppieren und zu systematisieren.

2.2 Grundlegende Eigenschaften von NoSQL-Datenbanken

Es gibt nur wenige gemeinsame Merkmale für alle NoSQL-Systeme, da viele heterogene Systeme mittlerweile unter dem NoSQL-Label verborgen sind (die vielleicht vollständigste Liste finden Sie unter http://nosql-database.org/). Viele Eigenschaften sind nur bestimmten NoSQL-Datenbanken eigen, ich werde dies bei der Auflistung auf jeden Fall erwähnen.

1. Es wird kein SQL verwendet

Ich meine ANSI SQL DML, da viele Datenbanken versuchen, Abfragesprachen ähnlich der bekannten Lieblingssyntax zu verwenden, aber niemand hat es geschafft, sie vollständig zu implementieren, und es ist unwahrscheinlich, dass dies gelingt. Allerdings gibt es Gerüchten zufolge Startups, die versuchen, SQL zu implementieren, beispielsweise in hadup ( http://www.drawntoscalehq.com/ und http://www.hadapt.com/ ).

2. Unstrukturiert (schemalos)

Das bedeutet, dass in NoSQL-Datenbanken im Gegensatz zu relationalen Datenbanken die Datenstruktur nicht reguliert ist (oder schwach typisiert ist, wenn wir Analogien zu Programmiersprachen ziehen) – Sie können ein beliebiges Feld in einer separaten Zeile oder einem separaten Dokument hinzufügen, ohne die Struktur zuvor deklarativ zu ändern der gesamten Tabelle. Wenn also eine Änderung des Datenmodells erforderlich ist, besteht die einzig ausreichende Maßnahme darin, die Änderung im Anwendungscode widerzuspiegeln.

Wenn Sie beispielsweise ein Feld in MongoDB umbenennen:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

Wenn wir die Anwendungslogik ändern, erwarten wir auch beim Lesen ein neues Feld. Aufgrund des Fehlens eines Datenschemas fehlt jedoch das Feld „totalSum“ in anderen bereits vorhandenen Order-Objekten. In dieser Situation gibt es zwei Optionen für das weitere Vorgehen.

Die erste besteht darin, alle Dokumente zu crawlen und dieses Feld in allen vorhandenen Dokumenten zu aktualisieren. Aufgrund der Datenmenge erfolgt dieser Vorgang ohne Sperren (vergleichbar mit dem Befehl alter table rename columns), so dass beim Update bereits vorhandene Daten von anderen Prozessen gelesen werden können. Daher ist die zweite Möglichkeit – das Einchecken des Anwendungscodes – unumgänglich:

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

Und bereits bei der Neuaufnahme schreiben wir dieses Feld in einem neuen Format in die Datenbank.

Eine angenehme Folge des Fehlens eines Schemas ist die Effizienz der Arbeit mit spärlichen Daten. Wenn ein Dokument über ein date_published-Feld verfügt und das zweite nicht, wird für das zweite Dokument kein leeres date_published-Feld erstellt. Dies ist im Prinzip logisch, aber ein weniger offensichtliches Beispiel sind NoSQL-Datenbanken mit Spaltenfamilie, die die bekannten Konzepte von Tabellen/Spalten verwenden. Aufgrund des Fehlens eines Schemas werden Spalten jedoch nicht deklarativ deklariert und können während der Datenbanksitzung eines Benutzers geändert/hinzugefügt werden. Dies ermöglicht insbesondere die Verwendung dynamischer Spalten zur Implementierung von Listen.

Das unstrukturierte Schema hat seine Nachteile – zusätzlich zum oben erwähnten Overhead im Anwendungscode beim Ändern des Datenmodells – das Fehlen jeglicher Einschränkungen von der Basis (nicht null, eindeutig, Check-Constraint usw.) und dort Es gibt zusätzliche Schwierigkeiten beim Verständnis und der Kontrolle der Strukturdaten, wenn parallel mit der Datenbank verschiedener Projekte gearbeitet wird (es gibt keine Wörterbücher auf der Seite der Datenbank). In einer sich schnell verändernden modernen Welt ist diese Flexibilität jedoch immer noch von Vorteil. Ein Beispiel ist Twitter, das vor fünf Jahren neben dem Tweet nur wenige zusätzliche Informationen (Zeit, Twitter-Handle und ein paar weitere Bytes an Metainformationen) speicherte, mittlerweile aber zusätzlich zur Nachricht selbst noch ein paar mehr Kilobyte an Metadaten werden in der Datenbank gespeichert.

(Im Folgenden sprechen wir hauptsächlich über Schlüsselwert-, Dokument- und Spaltenfamiliendatenbanken. Diagrammdatenbanken verfügen möglicherweise nicht über diese Eigenschaften.)

2.3. Darstellung von Daten in Form von Aggregaten (Aggregaten)

Im Gegensatz zum relationalen Modell, das die logische Geschäftsentität der Anwendung zu Normalisierungszwecken in verschiedenen physischen Tabellen speichert, arbeiten NoSQL-Speicher mit diesen Entitäten so, als wären sie ganzheitliche Objekte:

Dieses Beispiel zeigt Aggregationen für ein standardmäßiges konzeptionelles relationales E-Commerce-Modell „Bestellung – Bestellartikel – Zahlungen – Produkt“. In beiden Fällen wird die Bestellung mit Positionen in einem logischen Objekt zusammengefasst, während jede Position einen Link zum Produkt und einige seiner Attribute, beispielsweise den Namen, speichert (eine solche Denormalisierung ist notwendig, um beim Abrufen kein Produktobjekt anzufordern). eine Ordnung - die Hauptregel verteilter Systeme sind „Verbindungen“ zwischen Objekten). In einem Aggregat werden Zahlungen mit der Bestellung zusammengefasst und sind integraler Bestandteil des Objekts, im anderen werden sie in einem separaten Objekt platziert. Dies zeigt die Hauptregel für den Entwurf einer Datenstruktur in NoSQL-Datenbanken: Sie muss den Anforderungen der Anwendung entsprechen und so weit wie möglich für die häufigsten Anforderungen optimiert sein.

Viele werden Einwände erheben und darauf hinweisen, dass die Arbeit mit großen, häufig denormalisierten Objekten mit zahlreichen Problemen behaftet ist, wenn beliebige Datenabfragen durchgeführt werden, wenn Abfragen nicht in die Struktur von Aggregaten passen. Was passiert, wenn wir Bestellungen zusammen mit Bestellpositionen und Zahlungen verwenden (so funktioniert die App), das Unternehmen uns jedoch auffordert, zu zählen, wie viele Einheiten eines bestimmten Produkts im letzten Monat verkauft wurden? In diesem Fall müssen wir, anstatt die OrderItem-Tabelle zu scannen (im Fall eines relationalen Modells), die gesamten Bestellungen im NoSQL-Speicher abrufen, obwohl wir nicht viele dieser Informationen benötigen. Leider ist dies ein Kompromiss, der in einem verteilten System eingegangen werden muss: Wir können die Daten nicht wie in einem herkömmlichen Einzelserversystem normalisieren.

Ich habe versucht, die Vor- und Nachteile beider Ansätze in einer Tabelle zusammenzufassen: