Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:keyvaluedb [2015/10/05 21:14] – [Datenmodell] brueck
+++ bigdata:keyvaluedb [2015/10/05 21:15] (aktuell) – [Nachteile] brueck
@@ Zeile 11: / Zeile 11: @@
 ===== Vorteile =====
-Im Gegensatz zu ihren frühen Vertretern wurden moderne Key-Value-Systeme mit einem Fokus auf [[bigdata:skalierung|Skalierbarkeit]] entwickelt. Dabei ist von Vorteil, dass die Daten als Aggregate gehalten werden, denn so können sie als (atomare) Einheit auf einem Cluster-Knoten gespeichert und/oder geladen werden, ohne verstreut zu werden. Ferner erlaubt das einfache Modell über die Schlüssel sehr schnelle Datenzugriffe, wobei sich ein zusätzlicher Performancevorteil ergibt, wenn die Daten im Hauptspeicher gehalten werden. Und schließlich bietet das (für die Datenbank opak gehaltene) aggregatorientierte Datenmodell, von etwaigen Größenbeschränkungen abgesehen, größtmögliche Freiheit, was die Struktur der Daten angeht ([[bigdata:literatur|Sadalage/Fowler 2012: S. 20f]]).
+Im Gegensatz zu ihren frühen Vertretern wurden moderne Key-Value-Systeme mit einem Fokus auf [[bigdata:skalierung|Skalierbarkeit]] entwickelt. Dabei ist von Vorteil, dass die Daten als Aggregate gehalten werden, denn so können sie als (atomare) Einheit auf einem Cluster-Knoten gespeichert und/oder geladen werden, ohne verstreut zu werden. Ferner erlaubt das einfache Modell über die Schlüssel sehr schnelle Datenzugriffe, wobei sich ein zusätzlicher Performancevorteil ergibt, wenn die Daten im Hauptspeicher gehalten werden. Und schließlich bietet das (für die Datenbank opak gehaltene) aggregatorientierte Datenmodell, von etwaigen Größenbeschränkungen abgesehen, größtmögliche Freiheit, was die Struktur der Daten angeht ([[bigdata:literatur#s|Sadalage/Fowler 2012: S. 20f]]).
 ===== Nachteile =====
-Das schlichte Modell, das den Key-Value-Stores bei der Datenhaltung zum Vorteil gereicht, birgt zugleich einige Nachteile bei der Datenverarbeitung. So kann auf die Value-Daten nur über deren Schlüssel zugegriffen werden, was ihre Abfragemöglichkeiten doch sehr einschränkt. Da die Wert-Aggregate für die Datenbank undurchsichtig gehalten sind (eben nur eine beliebige Bit-Reihenfolge), ist eine Suche oder Manipulation innerhalb dieser Wert-Objekte nicht möglich und um sie zu ändern, müssen sie überschrieben werden. Auch das Herstellen und Erkennen von Beziehungen der Aggregate untereinander ist so nicht möglich. Effektiv bietet eine API im einfachsten Falle mit Operationen wie ''put(key, value)'', ''get(key)'', ''remove(key)'', einen doch recht eingeschränkten Funktionsumfang (Vgl. [[bigdata:literatur|Voldemort o. J.]]). Insgesamt ist es in seiner Grundform ein sehr simples Datenmodell, das sich wohl nicht für Anwendungen mit komplexeren Abfragen eignet.
+Das schlichte Modell, das den Key-Value-Stores bei der Datenhaltung zum Vorteil gereicht, birgt zugleich einige Nachteile bei der Datenverarbeitung. So kann auf die Value-Daten nur über deren Schlüssel zugegriffen werden, was ihre Abfragemöglichkeiten doch sehr einschränkt. Da die Wert-Aggregate für die Datenbank undurchsichtig gehalten sind (eben nur eine beliebige Bit-Reihenfolge), ist eine Suche oder Manipulation innerhalb dieser Wert-Objekte nicht möglich und um sie zu ändern, müssen sie überschrieben werden. Auch das Herstellen und Erkennen von Beziehungen der Aggregate untereinander ist so nicht möglich. Effektiv bietet eine API im einfachsten Falle mit Operationen wie ''put(key, value)'', ''get(key)'', ''remove(key)'', einen doch recht eingeschränkten Funktionsumfang (Vgl. [[bigdata:literatur#v|Voldemort o. J.]]). Insgesamt ist es in seiner Grundform ein sehr simples Datenmodell, das sich wohl nicht für Anwendungen mit komplexeren Abfragen eignet.