NoSQL
Eine NoSQL-Datenbank (ursprünglich "non-SQL" oder "nicht-relational") bietet einen Mechanismus für die Speicherung und den Abruf von Daten, die auf andere Weise als durch die in relationalen Datenbanken verwendeten tabellarischen Beziehungen modelliert sind. Solche Datenbanken gibt es seit den späten 1960er Jahren, aber der Name "NoSQL" wurde erst zu Beginn des 21. Jahrhunderts geprägt, ausgelöst durch die Bedürfnisse von Web 2.0-Unternehmen. NoSQL-Datenbanken werden zunehmend in Big Data- und Echtzeit-Webanwendungen eingesetzt. NoSQL-Systeme werden manchmal auch als "Not only SQL" bezeichnet, um zu betonen, dass sie SQL-ähnliche Abfragesprachen unterstützen oder neben SQL-Datenbanken in polyglott-persistenten Architekturen eingesetzt werden können. ⓘ
Zu den Beweggründen für diesen Ansatz gehören die Einfachheit des Designs, die einfachere "horizontale" Skalierung auf Cluster von Rechnern (was bei relationalen Datenbanken ein Problem darstellt), die bessere Kontrolle über die Verfügbarkeit und die Begrenzung des objektrelationalen Impedanzfehlers. Die von NoSQL-Datenbanken verwendeten Datenstrukturen (z. B. Schlüssel-Wert-Paare, breite Spalten, Graphen oder Dokumente) unterscheiden sich von denen, die standardmäßig in relationalen Datenbanken verwendet werden, was einige Operationen in NoSQL schneller macht. Die besondere Eignung einer bestimmten NoSQL-Datenbank hängt von dem Problem ab, das sie lösen muss. Manchmal werden die von NoSQL-Datenbanken verwendeten Datenstrukturen auch als "flexibler" als relationale Datenbanktabellen angesehen. ⓘ
Viele NoSQL-Speicher gehen Kompromisse bei der Konsistenz (im Sinne des CAP-Theorems) zu Gunsten von Verfügbarkeit, Partitionstoleranz und Geschwindigkeit ein. Zu den Hindernissen, die einer stärkeren Verbreitung von NoSQL-Speichern im Wege stehen, gehören die Verwendung von Abfragesprachen auf niedriger Ebene (z. B. anstelle von SQL), die fehlende Möglichkeit, Ad-hoc-Joins zwischen Tabellen durchzuführen, das Fehlen standardisierter Schnittstellen und die enormen früheren Investitionen in bestehende relationale Datenbanken. Die meisten NoSQL-Speicher verfügen nicht über echte ACID-Transaktionen, obwohl einige wenige Datenbanken diese zu einem zentralen Bestandteil ihres Designs gemacht haben. ⓘ
Stattdessen bieten die meisten NoSQL-Datenbanken ein Konzept der "eventuellen Konsistenz", bei dem Datenbankänderungen "irgendwann" (in der Regel innerhalb von Millisekunden) an alle Knoten weitergegeben werden, so dass Datenabfragen möglicherweise nicht sofort aktualisierte Daten zurückgeben oder dazu führen, dass Daten gelesen werden, die nicht korrekt sind, ein Problem, das als "stale reads" bekannt ist. Außerdem kann es bei einigen NoSQL-Systemen zu verlorenen Schreibvorgängen und anderen Formen des Datenverlusts kommen. Einige NoSQL-Systeme bieten Konzepte wie das Write-Ahead-Logging, um Datenverluste zu vermeiden. Bei der verteilten Transaktionsverarbeitung über mehrere Datenbanken hinweg stellt die Datenkonsistenz eine noch größere Herausforderung dar, die sowohl für NoSQL- als auch für relationale Datenbanken schwierig ist. Relationale Datenbanken "erlauben keine datenbankübergreifenden Einschränkungen der referentiellen Integrität". Nur wenige Systeme unterstützen sowohl ACID-Transaktionen als auch X/Open XA-Standards für die verteilte Transaktionsverarbeitung. Interaktive relationale Datenbanken haben Techniken zur Analyse von Konformitätsrelationen als gemeinsames Merkmal. Beschränkungen innerhalb der Schnittstellenumgebung werden durch semantische Virtualisierungsprotokolle überwunden, so dass NoSQL-Dienste für die meisten Betriebssysteme zugänglich sind. ⓘ
Bekannte Implementierungen sind Riak, Apache Cassandra, CouchDB, MongoDB und Redis. ⓘ
Geschichte
Der Begriff NoSQL, noch im Sinne von no SQL, wurde erstmals für eine 1998 erschienene einfache Open-Source-Datenbank verwendet, die keine SQL-Zugriffsmöglichkeit bereitstellte. Carlo Strozzi, der Entwickler dieser Datenbank, unterscheidet allerdings die NoSQL-Datenbank von der NoSQL-Bewegung insofern, als erstere eine Datenbank ist, welche auf die Verwendung der Sprache SQL verzichtet, während letztere ein Konzept ist, das vom relationalen Modell Abstand nimmt. ⓘ
Der Begriff NoSQL im Sinne von Not only SQL wurde Anfang 2009 von Johan Oskarsson für ein Treffen über verteilte strukturierte Datenspeicher neu eingeführt. Der Name war ein Versuch einer gemeinsamen Begriffsfindung für die wachsende Zahl an nicht relationalen, verteilten Datenspeichersystemen, die meist auch auf ACID-Eigenschaften verzichteten. ⓘ
Dieses Thema ist nicht ganz neu. Die Bestrebung, Daten ohne die Einschränkungen des relationalen Modells zu speichern, war bereits früher unter dem Titel dokumentenorientierte Datenbank bekannt. Insofern sind alle Vertreter dieser Thematik auch als NoSQL-Systeme zu betrachten. ⓘ
Obwohl sich NoSQL-Systeme kontinuierlich verbreiten, wird der Markt nach wie vor deutlich von relationalen Systemen dominiert (Stand 2020). ⓘ
Typen und Beispiele
Es gibt verschiedene Möglichkeiten, NoSQL-Datenbanken zu klassifizieren, mit unterschiedlichen Kategorien und Unterkategorien, von denen sich einige überschneiden. Im Folgenden finden Sie eine nicht erschöpfende Klassifizierung nach Datenmodell mit Beispielen:
| Typ | Bemerkenswerte Beispiele für diesen Typ ⓘ |
|---|---|
| Schlüssel-Wert-Cache | Apache Ignite, Couchbase, Coherence, eXtreme Scale, Hazelcast, Infinispan, Memcached, Redis, Velocity |
| Key-Value-Speicher | Azure Cosmos DB, ArangoDB, Amazon DynamoDB, Aerospike, Couchbase |
| Key-Value-Speicher (eventuell konsistent) | Azure Cosmos DB, Oracle NoSQL-Datenbank, Riak, Voldemort |
| Key-Value-Speicher (geordnet) | FoundationDB, InfinityDB, LMDB, MemcacheDB |
| Tupel-Speicher | Apache River, GigaSpaces, Tarantool, TIBCO ActiveSpaces, OpenLink Virtuoso |
| Triplestore | AllegroGraph, MarkLogic, Ontotext-OWLIM, Oracle NoSQL-Datenbank, Profium Sense, Virtuoso Universal Server |
| Objekt-Datenbank | Objectivity/DB, Perst, ZopeDB, db4o, GemStone/S, InterSystems Caché, JADE, ObjectDatabase++, ObjectDB, ObjectStore, ODABA, Realm, OpenLink Virtuoso, Versant Object Database, ZODB |
| Dokumentenspeicher | Azure Cosmos DB, ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, eXist-db, IBM Domino, MarkLogic, MongoDB, RavenDB, Qizx, RethinkDB, Elasticsearch, OrientDB |
| Breiter Spaltenspeicher | Azure Cosmos DB, Amazon DynamoDB, Bigtable, Cassandra, Google Cloud Datastore, HBase, Hypertable, ScyllaDB |
| Native Multimodell-Datenbank | ArangoDB, Azure Cosmos DB, OrientDB, MarkLogic, Apache Ignite, Couchbase, FoundationDB, MarkLogic, Oracle Database |
| Graph-Datenbank | Azure Cosmos DB, AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso |
| Mehrwerte-Datenbank | D3 Pick-Datenbank, Extensible Storage Engine (ESE/NT), InfinityDB, InterSystems Caché, jBASE Pick-Datenbank, mvBase Rocket Software, mvEnterprise Rocket Software, Northgate Information Solutions Reality (die ursprüngliche Pick/MV-Datenbank), OpenQM, Revelation Software's OpenInsight (Windows) und Advanced Revelation (DOS), UniData Rocket U2, UniVerse Rocket U2 |
Key-Value-Speicher
Key-Value (KV)-Speicher verwenden das assoziative Array (auch Map oder Dictionary genannt) als grundlegendes Datenmodell. In diesem Modell werden die Daten als eine Sammlung von Schlüssel-Wert-Paaren dargestellt, so dass jeder mögliche Schlüssel höchstens einmal in der Sammlung vorkommt. ⓘ
Das Key-Value-Modell ist eines der einfachsten nicht-trivialen Datenmodelle, und reichhaltigere Datenmodelle werden oft als Erweiterung dieses Modells implementiert. Das Schlüssel-Wert-Modell kann zu einem diskret geordneten Modell erweitert werden, bei dem die Schlüssel in lexikografischer Reihenfolge verwaltet werden. Diese Erweiterung ist insofern rechenintensiv, als sie selektive Schlüsselbereiche effizient abrufen kann. ⓘ
Schlüssel-Wert-Speicher können Konsistenzmodelle verwenden, die von eventueller Konsistenz bis zur Serialisierbarkeit reichen. Einige Datenbanken unterstützen die Ordnung von Schlüsseln. Es gibt verschiedene Hardware-Implementierungen, und einige Benutzer speichern Daten im Arbeitsspeicher (RAM), während andere sie auf Solid-State-Laufwerken (SSD) oder rotierenden Festplatten (auch Festplattenlaufwerk genannt) speichern. ⓘ
Dokumentenspeicher
Das zentrale Konzept eines Dokumentenspeichers ist das eines "Dokuments". Auch wenn sich die Details dieser Definition bei den dokumentenorientierten Datenbanken unterscheiden, gehen sie alle davon aus, dass Dokumente Daten (oder Informationen) in einigen Standardformaten oder -kodierungen kapseln und kodieren. Zu den gebräuchlichen Kodierungen gehören XML, YAML und JSON sowie binäre Formen wie BSON. Dokumente werden in der Datenbank über einen eindeutigen Schlüssel adressiert, der das jeweilige Dokument repräsentiert. Ein weiteres Merkmal einer dokumentenorientierten Datenbank ist eine API oder Abfragesprache zum Abrufen von Dokumenten auf der Grundlage ihres Inhalts. ⓘ
Verschiedene Implementierungen bieten unterschiedliche Möglichkeiten, Dokumente zu organisieren und/oder zu gruppieren:
- Sammlungen
- Schlagwörter
- Nicht sichtbare Metadaten
- Verzeichnis-Hierarchien ⓘ
Im Vergleich zu relationalen Datenbanken können Sammlungen als analog zu Tabellen und Dokumente als analog zu Datensätzen betrachtet werden. Aber sie unterscheiden sich: Jeder Datensatz in einer Tabelle hat die gleiche Abfolge von Feldern, während Dokumente in einer Sammlung völlig unterschiedliche Felder haben können. ⓘ
Graph
Graphdatenbanken sind für Daten gedacht, deren Beziehungen sich gut als Graph darstellen lassen, der aus Elementen besteht, die durch eine endliche Anzahl von Beziehungen verbunden sind. Beispiele für solche Daten sind soziale Beziehungen, öffentliche Verkehrsverbindungen, Straßenkarten, Netzwerktopologien usw. ⓘ
- Graphdatenbanken und ihre Abfragesprache ⓘ
| Bezeichnung | Sprache(n) | Anmerkungen ⓘ |
|---|---|---|
| AllegroGraph | SPARQL | RDF-Tripel-Speicher |
| Amazon Neptun | Gremlin, SPARQL | Graph-Datenbank |
| ArangoDB | AQL, JavaScript, GraphQL | Multi-Modell-DBMS Dokument, Graph-Datenbank und Key-Value-Speicher |
| Azure Cosmos DB | Gremlin | Graph-Datenbank |
| DEX/Sparksee | C++, Java, C#, Python | Graph-Datenbank |
| FlockDB | Scala | Graph-Datenbank |
| IBM Db2 | SPARQL | RDF-Dreifachspeicher, hinzugefügt in DB2 10 |
| InfiniteGraph | Java | Graph-Datenbank |
| JanusGraph | Java | Graph-Datenbank |
| MarkLogic | Java, JavaScript, SPARQL, XQuery | Multi-Modell-Dokumenten-Datenbank und RDF-Tripel-Speicher |
| Neo4j | Chiffre | Graph-Datenbank |
| OpenLink Virtuoso | C++, C#, Java, SPARQL | Hybrid aus Middleware und Datenbank-Engine |
| Oracle | SPARQL 1.1 | RDF Triple Store hinzugefügt in 11g |
| OrientDB | Java, SQL | Multi-Modell-Datenbank für Dokumente und Graphen |
| OWLIM | Java, SPARQL 1.1 | RDF-Tripel-Speicher |
| Profium Sense | Java, SPARQL | RDF-Tripel-Speicher |
| RedisGraph | Chiffre | Graph-Datenbank |
| Sqrrl Unternehmen | Java | Graph-Datenbank |
| TerminusDB | JavaScript, Python, Datalog | Quelloffener RDF-Triple-Speicher und Dokumentenspeicher |
Leistung
Die Leistung von NoSQL-Datenbanken wird in der Regel anhand des Durchsatzes bewertet, der als Operationen/Sekunde gemessen wird. Bei der Leistungsbewertung muss auf die richtigen Benchmarks geachtet werden, wie z. B. Produktionskonfigurationen, Parameter der Datenbanken, erwartetes Datenvolumen und gleichzeitige Benutzerarbeitslasten. ⓘ
Ben Scofield bewertete verschiedene Kategorien von NoSQL-Datenbanken wie folgt:
| Datenmodell | Leistung | Skalierbarkeit | Flexibilität | Komplexität | Funktionsumfang ⓘ |
|---|---|---|---|---|---|
| Key-Value-Speicher | hoch | hoch | hoch | keine | variabel (keine) |
| Spaltenorientierter Speicher | hoch | hoch | mäßig | niedrig | minimal |
| Dokumentorientierter Speicher | hoch | variabel (hoch) | hoch | niedrig | variabel (niedrig) |
| Graph-Datenbank | variabel | variabel | hoch | hoch | Graphentheorie |
| Relationale Datenbank | variabel | variabel | niedrig | mäßig | relationale Algebra |
Leistungs- und Skalierbarkeitsvergleiche werden in der Regel mit dem YCSB-Benchmark durchgeführt. ⓘ
Umgang mit relationalen Daten
Da die meisten NoSQL-Datenbanken nicht in der Lage sind, Joins in Abfragen durchzuführen, muss das Datenbankschema im Allgemeinen anders gestaltet werden. Es gibt drei Haupttechniken für den Umgang mit relationalen Daten in einer NoSQL-Datenbank. (Siehe Tabelle Join und ACID-Unterstützung für NoSQL-Datenbanken, die Joins unterstützen). ⓘ
Mehrere Abfragen
Anstatt alle Daten mit einer Abfrage abzurufen, ist es üblich, mehrere Abfragen durchzuführen, um die gewünschten Daten zu erhalten. NoSQL-Abfragen sind oft schneller als herkömmliche SQL-Abfragen, so dass die Kosten für zusätzliche Abfragen akzeptabel sein können. Wenn eine übermäßige Anzahl von Abfragen erforderlich wäre, ist einer der beiden anderen Ansätze besser geeignet. ⓘ
Caching, Replikation und nicht-normalisierte Daten
Anstatt nur Fremdschlüssel zu speichern, ist es üblich, tatsächliche Fremdwerte zusammen mit den Daten des Modells zu speichern. So kann beispielsweise jeder Blog-Kommentar neben einer Benutzerkennung auch den Benutzernamen enthalten, so dass ein einfacher Zugriff auf den Benutzernamen möglich ist, ohne dass eine weitere Abfrage erforderlich ist. Ändert sich jedoch ein Benutzername, muss dieser nun an vielen Stellen in der Datenbank geändert werden. Daher funktioniert dieser Ansatz besser, wenn Lesevorgänge viel häufiger vorkommen als Schreibvorgänge. ⓘ
Verschachtelung von Daten
Bei Dokumentendatenbanken wie MongoDB ist es üblich, mehr Daten in einer kleineren Anzahl von Sammlungen unterzubringen. In einer Blogging-Anwendung könnte man zum Beispiel Kommentare innerhalb des Blogpost-Dokuments speichern, so dass man mit einem einzigen Abruf alle Kommentare erhält. Bei diesem Ansatz enthält also ein einziges Dokument alle Daten, die Sie für eine bestimmte Aufgabe benötigen. ⓘ
ACID- und Join-Unterstützung
Eine Datenbank wird als unterstützend für ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) oder Join-Operationen gekennzeichnet, wenn die Dokumentation für die Datenbank dies behauptet. Dies bedeutet jedoch nicht notwendigerweise, dass die Fähigkeit vollständig unterstützt wird, ähnlich wie bei den meisten SQL-Datenbanken. ⓘ
| Datenbank | ACID | Verknüpfungen ⓘ |
|---|---|---|
| Aerospike | Ja | Nein |
| Apache Ignite | Ja | Ja |
| ArangoDB | Ja | Ja |
| Amazon DynamoDB | Ja | Nein |
| Couchbase | Ja | Ja |
| CouchDB | Ja | Ja |
| IBM Db2 | Ja | Ja |
| InfinityDB | Ja | Nein |
| LMDB | Ja | Nein |
| MarkLogic | Ja | Ja |
| MongoDB | Ja | Ja |
| OrientDB | Ja | Ja |