Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:skalierung [2015/10/05 21:28] – [Horizontale Skalierung] brueck
+++ bigdata:skalierung [2015/10/05 21:28] – [Replikation] brueck
@@ 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]]).