Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:graphdb [2015/10/05 21:23] – [Datenmodell] brueck
+++ bigdata:graphdb [2015/10/05 21:24] (aktuell) – [Nachteile] brueck
@@ Zeile 21: / Zeile 21: @@
 RDBMS sind dafür eher ungeeignet, da es für das Darstellen und Finden von Verbindungen unter Umständen viele zeitintensive JOINs benötigt, die immer kostspieliger werden, je mehr Datensätze hinzukommen und je tiefer die Verbindungen zwischen ihnen werden sollen. Graphdatenbanken bieten sich für dieses Problem als Lösung an. Sie wurden speziell dafür entwickelt und optimiert und kommen mit entsprechenden Algorithmen daher.
-Da Beziehungen schon bei ihrer Erstellung als Elemente mit angelegt werden, müssen diese bei Abfragen nicht erst aufwendig zur Laufzeit berechnet werden, sondern können direkt verwendet werden. Das bedeutet zwar höhere „Kosten“ beim Anlegen, ermöglicht dafür jedoch ein konstant schnelles Traversieren der Verbindungen/Kanten (und nicht etwa über Keys) bei Abfragen unabhängig von der Gesamtdatenmenge, da nur die für die Abfrage relevanten Verbindungen berücksichtigt werden. Man spricht bei der Navigation durch die Beziehungen auch von **indexfreier Adjazenz**, da sie nicht über globale Indizes erfolgt, sondern eben über das Traversieren der Kanten ([[bigdata:literatur|Armbruster 2014]]).
+Da Beziehungen schon bei ihrer Erstellung als Elemente mit angelegt werden, müssen diese bei Abfragen nicht erst aufwendig zur Laufzeit berechnet werden, sondern können direkt verwendet werden. Das bedeutet zwar höhere „Kosten“ beim Anlegen, ermöglicht dafür jedoch ein konstant schnelles Traversieren der Verbindungen/Kanten (und nicht etwa über Keys) bei Abfragen unabhängig von der Gesamtdatenmenge, da nur die für die Abfrage relevanten Verbindungen berücksichtigt werden. Man spricht bei der Navigation durch die Beziehungen auch von **indexfreier Adjazenz**, da sie nicht über globale Indizes erfolgt, sondern eben über das Traversieren der Kanten ([[bigdata:literatur#a|Armbruster 2014]]).
 Ein weiterer Vorteil zeigt sich in der Konzeptionsphase bei der Modellierung. Hier hört man gelegentlich das Motto //„if you can whiteboard it, you can graph it“//. Das meint, dass sich Graphen, wie sie leicht verständlich auf Papier oder Whiteboards aufgemalt werden, auch genauso als Datenbank umsetzen lassen können.
@@ Zeile 30: / Zeile 30: @@
 ===== Nachteile =====
-Im Gegenteil zu den übrigen NoSQL-Datenbanken, die ihre Daten hauptsächlich nach ihrem Primärschlüssel in Aggregaten verteilen, müssen Graphdatenbanken ihr Beziehungsgeflecht irgendwie aufbrechen, um das System auf einer verteilten Architektur skalieren zu können und müssen dafür auch entsprechende Operationen bereitstellen. [[bigdata:skalierung|Sharding]] ist also kein so einfacher Prozess wie bei den anderen Systemen und führt eher zu Performanceverlust, als –gewinn, da diese Systeme eher für Ein-Server-Architekturen entworfen wurden, auf denen das Traversieren schneller geschieht, als auf verteilten Systemen. ([[bigdata:literatur|Sadalage/Fowler 2012: S. 119]]) Reicht die Kapazität des Servers nicht aus und soll die Graphdatenbank verteilt werden, muss der Graph in Teilgraphen [[bigdata:skalierung|partitioniert]] werden, wobei sich das Finden einer sinnvollen Stelle dafür als schwierig erweisen kann und eingehend untersucht werden sollte.
+Im Gegenteil zu den übrigen NoSQL-Datenbanken, die ihre Daten hauptsächlich nach ihrem Primärschlüssel in Aggregaten verteilen, müssen Graphdatenbanken ihr Beziehungsgeflecht irgendwie aufbrechen, um das System auf einer verteilten Architektur skalieren zu können und müssen dafür auch entsprechende Operationen bereitstellen. [[bigdata:skalierung|Sharding]] ist also kein so einfacher Prozess wie bei den anderen Systemen und führt eher zu Performanceverlust, als –gewinn, da diese Systeme eher für Ein-Server-Architekturen entworfen wurden, auf denen das Traversieren schneller geschieht, als auf verteilten Systemen. ([[bigdata:literatur#s|Sadalage/Fowler 2012: S. 119]]) Reicht die Kapazität des Servers nicht aus und soll die Graphdatenbank verteilt werden, muss der Graph in Teilgraphen [[bigdata:skalierung|partitioniert]] werden, wobei sich das Finden einer sinnvollen Stelle dafür als schwierig erweisen kann und eingehend untersucht werden sollte.