Benutzer-Werkzeuge

Webseiten-Werkzeuge


bigdata:dokumentdb

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
bigdata:dokumentdb [2015/10/05 21:18] – [Dokumentenorientierte Datenbanken] brueckbigdata:dokumentdb [2015/10/05 21:19] (aktuell) – [Nachteile] brueck
Zeile 7: Zeile 7:
  
 Das Datenmodell ist ähnlich dem der [[bigdata:keyvaluedb|Key-Value-Datenbanken]]. Im Prinzip ist ihr Modell gleich: Es gibt einen Schlüssel, zu dem ein Wert gehört. Tatsächlich sind die Grenzen fließend und nicht immer klar zu unterscheiden. Oft findet man in unterschiedlichen Quellen unterschiedliche Zuordnungen, wenn es um die Kategorisierung einzelner Vertreter der beiden Datenmodelle geht. Das Datenmodell ist ähnlich dem der [[bigdata:keyvaluedb|Key-Value-Datenbanken]]. Im Prinzip ist ihr Modell gleich: Es gibt einen Schlüssel, zu dem ein Wert gehört. Tatsächlich sind die Grenzen fließend und nicht immer klar zu unterscheiden. Oft findet man in unterschiedlichen Quellen unterschiedliche Zuordnungen, wenn es um die Kategorisierung einzelner Vertreter der beiden Datenmodelle geht.
-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:literatur|Sadalage/Fowler 2012: S. 20]]). Das ermöglicht sowohl das Suchen nach Dokumenten, als auch das Suchen nach-, sowie das Updaten von Abschnitten //innerhalb// dieser Dokumente. In gewisser Weise können sie als Erweiterung der Key-Value-Gattung betrachtet werden.+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:literatur#s|Sadalage/Fowler 2012: S. 20]]). Das ermöglicht sowohl das Suchen nach Dokumenten, als auch das Suchen nach-, sowie das Updaten von Abschnitten //innerhalb// dieser Dokumente. In gewisser Weise können sie als Erweiterung der Key-Value-Gattung betrachtet werden.
  
 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 14: Zeile 14:
  
 {{ :bigdata:documentstore.png |}} {{ :bigdata:documentstore.png |}}
-(Grafik-Quelle: [[bigdata:literatur|Couchbase o. J.]])+(Grafik-Quelle: [[bigdata:literatur#c|Couchbase o. J.]])
  
 ===== Vorteile ===== ===== Vorteile =====
Zeile 23: Zeile 23:
 ===== Nachteile ===== ===== Nachteile =====
  
-Auch hier ist es nicht ohne Weiteres möglich, Beziehungen zwischen den Dokumenten herzustellen. Es ist zwar möglich, ID-Felder in die Dokumente zu schreiben, jedoch sind darüber keine Direkten JOINs möglich, da zunächst ein Dokument geladen und nach der ID gesucht wird und dann im nächsten Schritt erneut die Datenbank befragt werden muss, um ein Dokument mit der passenden ID zu suchen und zu laden, um dann eine Schnittmenge zu erstellen. Da es sich um ein nichtrelationales Modell handelt, bietet die Datenbank dafür auch keinerlei Abfragemöglichkeiten und müssen daher selbst programmiert werden. Für Anwendungen, bei denen komplexere Beziehungen wichtig sind, eignen sie sich also eher nicht. Während die Schemafreiheit einerseits zwar große Flexibilität bei der Modellierung bietet, bedeutet sie andererseits jedoch Aufwand bei der Abfrageprogrammierung, da zuvor der Applikationscode studiert werden muss, um Einblicke über das indirekte Schema der Datenbank gewinnen zu können ([[bigdata:literatur|Sadalage/Fowler 2012: S. 29]]). Zudem müssen Festlegungen zu Dokumentenstrukturen, eventuelle Wertprüfungen, Trigger und dergleichen in der Anwendung programmiert werden und können nicht von der Datenbank selbst übernommen werden.+Auch hier ist es nicht ohne Weiteres möglich, Beziehungen zwischen den Dokumenten herzustellen. Es ist zwar möglich, ID-Felder in die Dokumente zu schreiben, jedoch sind darüber keine Direkten JOINs möglich, da zunächst ein Dokument geladen und nach der ID gesucht wird und dann im nächsten Schritt erneut die Datenbank befragt werden muss, um ein Dokument mit der passenden ID zu suchen und zu laden, um dann eine Schnittmenge zu erstellen. Da es sich um ein nichtrelationales Modell handelt, bietet die Datenbank dafür auch keinerlei Abfragemöglichkeiten und müssen daher selbst programmiert werden. Für Anwendungen, bei denen komplexere Beziehungen wichtig sind, eignen sie sich also eher nicht. Während die Schemafreiheit einerseits zwar große Flexibilität bei der Modellierung bietet, bedeutet sie andererseits jedoch Aufwand bei der Abfrageprogrammierung, da zuvor der Applikationscode studiert werden muss, um Einblicke über das indirekte Schema der Datenbank gewinnen zu können ([[bigdata:literatur#s|Sadalage/Fowler 2012: S. 29]]). Zudem müssen Festlegungen zu Dokumentenstrukturen, eventuelle Wertprüfungen, Trigger und dergleichen in der Anwendung programmiert werden und können nicht von der Datenbank selbst übernommen werden.
  
  
bigdata/dokumentdb.txt · Zuletzt geändert: 2015/10/05 21:19 von brueck