Der ganze Punkt von NoSQL ist, dass es keine Standardlösungen gibt . Jedes Datenspeicherproblem ist anders, und Sie müssen die Datenspeichertechnologie auswählen, die für Ihr spezifisches Problem geeignet ist und nicht für die, die "der Standard" ist.
Das ist die ganze Prämisse von " Not Only SQL ".
Nimm ACID (hier ist ein paar Ratschläge, von denen du nie gedacht hättest, dass du StackOverflow oder wirklich irgendwo nach 1987 bekommst :-)), zum Beispiel. Es gibt eine Vielzahl von Problemen, die keine ACID-Garantien benötigen. Für diese Probleme ist ACID Overkill. Overkill, das sich in verschwendetem I / O, vergeudeten CPU-Zyklen und vergeudeter Leistung äußert. Das bedeutet verschwendete Wärme und verschwendete Energie, was wiederum Geld für Strom- und Stromrechnungen bedeutet.
Einige Probleme brauchen nur schwächere Formen dieser Garantien. Zum Beispiel ist für eine breite Palette von Webanwendungen die sogenannte mögliche Konsistenz genug. Andere Probleme benötigen höhere Garantien als die ACID im SQL-Stil.
Einige NoSQL-Datenbanken haben also keine ACID-Garantien oder haben sie nur in einer schwächeren Form. Einige können sie auf DB-Basis ein- und ausschalten. Einige können A, C, I und D auf individueller Basis ein- und ausschalten einzeln . Manche können A, C, I und D nicht nur ein- und ausschalten , sondern sie können sie auch gleitend skalieren. Manche können das sogar proper abfragen.
Wenn Sie hierarchische Daten haben, speichern Sie sie in einer hierarchischen Datenbank. Wenn Sie Diagrammdaten haben, speichern Sie sie in einer Diagrammdatenbank. Wenn Sie Schlüsselwertdaten haben, speichern Sie sie in einer Schlüsselwertdatenbank. Wenn Sie über semi-strukturierte Dokumentdaten verfügen, speichern Sie sie in einer Dokumentendatenbank. Wenn Sie semantische RDF-Daten haben, speichern Sie sie in einer dreifachen Datenbank. Wenn Sie ein Data Warehouse erstellen, speichern Sie es in einer Spaltendatenbank. Und wenn Sie relationale Daten haben, speichern Sie sie auf jeden Fall in einer relationalen Datenbank. (Aber nur wenn Sie tatsächlich relationale Daten haben!)
Es gibt keine einheitliche NoSQL-Lösung, wie Jörg erklärt (+1). Der Begriff NoSQL umfasst eine breite Palette von Datenbanktypen, die jeweils auf eine bestimmte Datendomäne zugeschnitten sind.
Ayendes That No SQL Thing Serie betrachtet einige der gängigen NoSQL-Lösungen und hebt die Stärken und Schwächen jeder Art hervor. Er bespricht das Folgende:
Sie können sich diese verschiedenen Typen als Standards innerhalb von NoSQL vorstellen. Denken Sie daran, dass jeder von ihnen auf bestimmte Datenspeicherprobleme spezialisiert ist. Es gibt keine einheitliche Lösung: Alle werden weiterhin existieren.
Einige Leute haben über Standards für Dokumentendatenbanken nachgedacht: Ссылка .
Jedoch führen Schlüssel-Wert-Speicher- und Dokument-DBs keine Joins durch und das bedeutet, dass ihre Abfragesprachen einfach und leicht zu erlernen sind. Es gibt weniger Bedarf für eine gemeinsame Sprache wie SQL.
Allerdings können .NET-Entwickler mit LINQ auf MonboDB und RavenDB von db zugreifen, und einige Leute entwickeln einen LINQ-Provider, um db CouchDB zu dokumentieren: Ссылка . LINQ ist kein NoSQL-Standard, sondern ein Standard für alles, was mit Daten zu tun hat. Sie können es verwenden, um mit einer relationalen Datenbank oder einer XML-Datei zu sprechen.
Graph-Datenbanken unterscheiden sich stark von Schlüssel-Wert-Speichern und Dokument-DBs. Ich glaube nicht, dass Sie sie in einem Standard vereinen können. Ich weiß wirklich nicht, ob es möglich ist, einen LINQ-Provider für eine Graphdatenbank zu entwickeln. Ich denke nicht, aber ich bin mir nicht sicher.
Einige NoSQL-Produkte unterstützen SQL oder eine ganze Menge davon. Dies ist der Fall von OrientDB , ein Dokument-Graph nosql dbms mit der Unterstützung von SQL. Es ist unter Apache 2 Lizenz veröffentlicht.
Außerdem kann das Dokument im JSON-Format exportiert werden (Sie können die gesamte Datenbank in JSON exportieren / importieren). Andere NoSQL-Produkte lesen / schreiben JSON.
tschüss, Lvc @
(Sprechen Sie speziell über eine Untergruppe von NoSQL, die als Dokumentendatenbanken bekannt sind.)
Viele Dokumentendatenbanken stellen keine "Abfragesprache" zur Verfügung. Stattdessen stellen sie oft Query-APIs bereit, und diese APIs sind spezifisch für die Implementierung und werden von den einzelnen Sponsoren / Eigentümern der Implementierungen gesteuert (z. B. 10gen für MongoDB).
Im XML-Datenbankbereich (eine Untergruppe von Dokumentendatenbanken) gibt es den W3C-Standard XQuery . Es ist eine Abfrage- und funktionale Programmiersprache, die für die Abfrage von Sammlungen von XML-Daten entwickelt wurde (sagt Wikipedia).
Es ist noch unklar, ob es einen Bedarf / Wunsch nach einer Standardabfrage-API (oder Sprache) für JSON-Daten gibt. JSONPath (analog zu XPath ) wurde vorgeschlagen, aber es hat wenig Aufmerksamkeit erhalten, außer dass es von Kynetx verwendet wird.