Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:skalierung [2015/10/05 21:27] – [Nachteile] brueck
+++ bigdata:skalierung [2015/10/05 21:28] – [Replikation] brueck
@@ Zeile 35: / Zeile 35: @@
 **Horizontale Skalierung** (**Scale Out**) meint das Hinzufügen neuer Server in ein bestehendes Cluster. Die Idee dabei ist, dass ein einzelner Server irgendwann nicht mehr in der Lage ist, das Datenvolumen und die eingehenden Anfragen darauf alleine zu stemmen. Daher wird die Last auf ein Server-Cluster verteilt.
-Während man bei der vertikalen Skalierung irgendwann an die Grenzen stößt, was Hardware oder deren Preis angeht, gibt es bei der horizontalen Skalierung hingegen theoretisch keine Begrenzung, da stets neue Rechner hinzugefügt werden können. Dabei müssen diese nicht einmal besonders leistungsstark sein (vgl. [[bigdata:literatur|Chang et al. 2006: S. 1]]), was ein kostengünstiges Erweitern ermöglicht. Denkbar wäre auch eine Auslagerung auf Cloud-Services.
+Während man bei der vertikalen Skalierung irgendwann an die Grenzen stößt, was Hardware oder deren Preis angeht, gibt es bei der horizontalen Skalierung hingegen theoretisch keine Begrenzung, da stets neue Rechner hinzugefügt werden können. Dabei müssen diese nicht einmal besonders leistungsstark sein (vgl. [[bigdata:literatur#c|Chang et al. 2006: S. 1]]), was ein kostengünstiges Erweitern ermöglicht. Denkbar wäre auch eine Auslagerung auf Cloud-Services.
 Je größer ein solches System wird, desto höher wird auch die Wahrscheinlichkeit, dass ein Hardwaredefekt auftritt, besonders wenn es sich um kostengünstige Low-End-Hardware handelt. Um nun also Datenverlust zu vermeiden und eine stete Verfügbarkeit des Systems zu gewährleisten, werden Daten nicht nur auf einem Knoten gehalten, sondern mehrfach redundant auf verschiedene Knoten verteilt.
@@ Zeile 45: / Zeile 45: @@
 ==== Replikation ====
-Wenn ein System durch //Lesezugriffe// zu stark belastet wird, bietet sich eine **Master-Slave-Replikation** als Lösungsansatz für eine Entlastung an. Bei einem solchen Aufbau wird die Datenbank auf einem Master-Server und einer Reihe von Slave-Servern repliziert. Der Master behandelt die Schreibzugriffe und die Slave-Knoten die Lesezugriffe. Fallen mehr Lesezugriffe an, kann das System durch horizontales Skalieren entlastet werden, indem neue Slave-Knoten hinzugefügt werden. Ein weiterer Vorteil ist, dass die Datenbank erreichbar bleibt, auch wenn ein oder mehrere Slave-Knoten ausfallen. Fällt jedoch der Master aus, ist kein schreibender Zugriff auf die Datenbank mehr möglich, bis er wiederhergestellt oder ersetzt wurde (vgl. [[bigdata:literatur|Sadalage/Fowler 2012: S. 40]]). Zwar werden Slaves regelmäßig aktualisiert, jedoch herrscht in der Zwischenzeit eine Inkonsistenz, solange die Updates noch nicht weitergegeben wurden.
+Wenn ein System durch //Lesezugriffe// zu stark belastet wird, bietet sich eine **Master-Slave-Replikation** als Lösungsansatz für eine Entlastung an. Bei einem solchen Aufbau wird die Datenbank auf einem Master-Server und einer Reihe von Slave-Servern repliziert. Der Master behandelt die Schreibzugriffe und die Slave-Knoten die Lesezugriffe. Fallen mehr Lesezugriffe an, kann das System durch horizontales Skalieren entlastet werden, indem neue Slave-Knoten hinzugefügt werden. Ein weiterer Vorteil ist, dass die Datenbank erreichbar bleibt, auch wenn ein oder mehrere Slave-Knoten ausfallen. Fällt jedoch der Master aus, ist kein schreibender Zugriff auf die Datenbank mehr möglich, bis er wiederhergestellt oder ersetzt wurde (vgl. [[bigdata:literatur#s|Sadalage/Fowler 2012: S. 40]]). Zwar werden Slaves regelmäßig aktualisiert, jedoch herrscht in der Zwischenzeit eine Inkonsistenz, solange die Updates noch nicht weitergegeben wurden.
-Eine weitere Replikationsart ist die **Peer-to-Peer-Replikation**. Hier wurde das Master-Slave-Prinzip aufgehoben, da der Ausfall des Masters unter Umständen zu einer Unerreichbarkeit der Datenbank für Schreibzugriffe führen kann. Fällt in dieser Topologie ein Server aus, bleibt das System trotzdem voll erreichbar, da nun jeder Knoten ist nun ein „Master“ ist und sowohl //Lese-//, als auch //Schreibzugriffe// verarbeiten kann. Dabei kommunizieren die Server bei Schreibzugriffen untereinander um die Daten entsprechend aktuell zu halten. Bei gleichzeitigen Schreibzugriffen auf ein Record kann es jedoch zu Konflikten kommen, wobei unter Umständen ein Update auch verloren gehen kann. Dies lässt sich unter Inkaufnahme erhöhter Netzwerkauslastung durch Koordination unter den Knoten bei Schreibzugriffen vermeiden ([[bigdata:literatur|Sadalage/Fowler 2012: S. 43]]).
+Eine weitere Replikationsart ist die **Peer-to-Peer-Replikation**. Hier wurde das Master-Slave-Prinzip aufgehoben, da der Ausfall des Masters unter Umständen zu einer Unerreichbarkeit der Datenbank für Schreibzugriffe führen kann. Fällt in dieser Topologie ein Server aus, bleibt das System trotzdem voll erreichbar, da nun jeder Knoten ist nun ein „Master“ ist und sowohl //Lese-//, als auch //Schreibzugriffe// verarbeiten kann. Dabei kommunizieren die Server bei Schreibzugriffen untereinander um die Daten entsprechend aktuell zu halten. Bei gleichzeitigen Schreibzugriffen auf ein Record kann es jedoch zu Konflikten kommen, wobei unter Umständen ein Update auch verloren gehen kann. Dies lässt sich unter Inkaufnahme erhöhter Netzwerkauslastung durch Koordination unter den Knoten bei Schreibzugriffen vermeiden ([[bigdata:literatur#s|Sadalage/Fowler 2012: S. 43]]).