bigdata:dokumentdb
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
bigdata:dokumentdb [2015/10/05 19:41] – [Verwendung] brueck | bigdata:dokumentdb [2015/10/05 21:19] – [Datenmodell] brueck | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Dokumentenorientierte Datenbanken ====== | ====== Dokumentenorientierte Datenbanken ====== | ||
- | **Dokumentenorientierte Datenbanken** (oder auch **dokumenten// | + | **Dokumentenorientierte Datenbanken** (oder auch **dokumenten// |
Zeile 7: | Zeile 7: | ||
Das Datenmodell ist ähnlich dem der [[bigdata: | Das Datenmodell ist ähnlich dem der [[bigdata: | ||
- | Wie auch bei Key-Value-Systemen werden Daten als Aggregate zusammengefasst. Für gewöhnlich handelt es sich dabei um JSON-Objekte (JavaScript Object Notation), da sie ein weitverbreitetes Datenformat für Webanwendungen und Apps sind (denkbar wären aber auch XML-Dokumente). JSON (und auch XML) verlangen keine vordefinierten Felder und können selbst wiederum beliebig verschachtelte Elemente enthalten. Im Gegensatz zu Key-Value-Stores ist die Dokumentenstruktur für die Datenbanken aber transparenter gestaltet ([[bigdata: | + | Wie auch bei Key-Value-Systemen werden Daten als Aggregate zusammengefasst. Für gewöhnlich handelt es sich dabei um JSON-Objekte (JavaScript Object Notation), da sie ein weitverbreitetes Datenformat für Webanwendungen und Apps sind (denkbar wären aber auch XML-Dokumente). JSON (und auch XML) verlangen keine vordefinierten Felder und können selbst wiederum beliebig verschachtelte Elemente enthalten. Im Gegensatz zu Key-Value-Stores ist die Dokumentenstruktur für die Datenbanken aber transparenter gestaltet ([[bigdata: |
Wie bei den anderen NoSQL-Datenmodellen auch, wird hier kein Schema vorgegeben. Die (JSON-)Dokumente können also nach Belieben gestaltet und ergänzt werden, ohne dass solche Änderungen zuvor dem System bekannt gemacht werden. Das gewährleistet große Flexibilität und bedeutet einen großen Vorteil gegenüber den herkömmlichen relationalen DBMS. | Wie bei den anderen NoSQL-Datenmodellen auch, wird hier kein Schema vorgegeben. Die (JSON-)Dokumente können also nach Belieben gestaltet und ergänzt werden, ohne dass solche Änderungen zuvor dem System bekannt gemacht werden. Das gewährleistet große Flexibilität und bedeutet einen großen Vorteil gegenüber den herkömmlichen relationalen DBMS. | ||
Zeile 13: | Zeile 13: | ||
Zwar ist keinerlei Struktur vorgeschrieben und tatsächlich kann jedes Dokument vollkommen anders aufgebaut sein, doch in der Regel wird man nicht wahllos Felder anlegen, sondern dabei ein gewisses, der Anwendung entsprechendes (indirektes) Schema verfolgen, um im Nachhinein auch eine Voraussetzung für sinnvolle Abfragen zu schaffen. So würde man bei einem Shop instinktiv davon ausgehen, dass in einem Dokument für eine Bestellung sowohl ein Feld „Preis“, | Zwar ist keinerlei Struktur vorgeschrieben und tatsächlich kann jedes Dokument vollkommen anders aufgebaut sein, doch in der Regel wird man nicht wahllos Felder anlegen, sondern dabei ein gewisses, der Anwendung entsprechendes (indirektes) Schema verfolgen, um im Nachhinein auch eine Voraussetzung für sinnvolle Abfragen zu schaffen. So würde man bei einem Shop instinktiv davon ausgehen, dass in einem Dokument für eine Bestellung sowohl ein Feld „Preis“, | ||
+ | {{ : | ||
+ | (Grafik-Quelle: | ||
===== Vorteile ===== | ===== Vorteile ===== |
bigdata/dokumentdb.txt · Zuletzt geändert: 2015/10/05 21:19 von brueck