Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:skalierung [2015/10/05 21:28] – [Replikation] brueck
+++ bigdata:skalierung [2015/10/05 21:28] – [Sharding] brueck
@@ Zeile 52: / Zeile 52: @@
 ==== Sharding ====
-**Sharding** hilft bei der Entlastung des Systems durch eine Verteilung der Daten in einem Server-Cluster. So können auch Datenvolumen verarbeitet werden, die zu groß für einen einzelnen Server wären. Dabei werden die Daten nicht wahllos zerteilt, sondern idealerweise so, dass Daten, auf die oft zusammen zugegriffen wird, auch auf demselben Server liegen. Tabellen können dabei anhand eines Shard-Keys (ein oder mehrere statische Attribute) in Untertabellen aufgespalten werden ([[bigdata:literatur|Microsoft o. J.]]).
+**Sharding** hilft bei der Entlastung des Systems durch eine Verteilung der Daten in einem Server-Cluster. So können auch Datenvolumen verarbeitet werden, die zu groß für einen einzelnen Server wären. Dabei werden die Daten nicht wahllos zerteilt, sondern idealerweise so, dass Daten, auf die oft zusammen zugegriffen wird, auch auf demselben Server liegen. Tabellen können dabei anhand eines Shard-Keys (ein oder mehrere statische Attribute) in Untertabellen aufgespalten werden ([[bigdata:literatur#m|Microsoft o. J.]]).
 Es kann auch sinnvoll sein, Daten, auf die aus einer bestimmten Region zugegriffen wird, auch auf Servern vor Ort oder in der Nähe zu speichern, um so die Antwortzeiten zu verkürzen. Man spricht dabei auch von **Regionalisierung**. Bei Graphdatenbanken kann das manchmal auch einen Anhaltspunkt für eine sinnvolle Schnittstelle bei der Partitionierung sein. So eine Trennung kann manchmal auch gesetzlich verlangt werden oder eine Compliance-Anforderung sein, sodass z.B. Kundendaten aus Europa auch auf europäischen Servern gespeichert werden.
@@ Zeile 58: / Zeile 58: @@
 Der Server, auf dem diese Daten liegen, ist dann auch für deren Verwaltung zuständig, ein zentraler Master, der Updates koordiniert und zu Inkonsistenzen führen kann, ist also überflüssig. Das erlaubt eine hohe Verfügbarkeit durch parallele unabhängige Zugriffe und zudem eine hohe Ausfalltoleranz, da bei einem Serverversagen nur ein Teil der Daten davon betroffen ist (durch zusätzliche Replikation der Daten kann zudem ein Datenverlust vermieden werden) und die restliche Datenbank verfügbar bleibt.
-Die meisten NoSQL-Systeme wurden für eine solche Verteilung konzipiert, ermöglichen automatisiertes Sharding und verwalten ihre Datensätze ohnehin in Aggregaten, die zusammengehörig sind und auf die in atomarer Weise zugegriffen werden kann und bei Verteilung auch nicht getrennt werden (vgl. [[bigdata:literatur|Sadalage/Fowler 2012: S. 39]]). Auf diese Weise sind schnelle Antwortzeiten der Server möglich. Allgemein empfiehlt es sich, auf verteilten Systemen mit kurzen Anfragen zu arbeiten, die möglichst nur einen Knoten benötigen, da ansonsten die Performance durch Kommunikations- oder Synchronisations-Overhead darunter leidet ([[bigdata:literatur|Stonebraker/Cattell 2011]]).
+Die meisten NoSQL-Systeme wurden für eine solche Verteilung konzipiert, ermöglichen automatisiertes Sharding und verwalten ihre Datensätze ohnehin in Aggregaten, die zusammengehörig sind und auf die in atomarer Weise zugegriffen werden kann und bei Verteilung auch nicht getrennt werden (vgl. [[bigdata:literatur#s|Sadalage/Fowler 2012: S. 39]]). Auf diese Weise sind schnelle Antwortzeiten der Server möglich. Allgemein empfiehlt es sich, auf verteilten Systemen mit kurzen Anfragen zu arbeiten, die möglichst nur einen Knoten benötigen, da ansonsten die Performance durch Kommunikations- oder Synchronisations-Overhead darunter leidet ([[bigdata:literatur#s|Stonebraker/Cattell 2011]]).
 ==== Vorteile ====