Benutzer-Werkzeuge

Webseiten-Werkzeuge


bigdata:mongodb

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
bigdata:mongodb [2015/10/05 21:21] – [Abfragen] brueckbigdata:mongodb [2015/10/05 21:22] – [Skalierung] brueck
Zeile 74: Zeile 74:
  
 MongoDB bietet die Möglichkeit, [[bigdata:skalierung|Replikationen]] nach dem Master-Slave-Prinzip zu erstellen, die dabei helfen, die Lese-Last zu verteilen und eine gewisse Ausfallsicherheit zu garantieren. Dabei besteht ein Replica Set aus einem Master-Knoten (auch Primary genannt) und Reihe von Slave-Knoten (auch Secondary genannt). Alle Schreibzugriffe gehen über den Primary, der diese in einem „Oplog“ protokolliert, welches er dann an die Secondary-Knoten überträgt, damit diese ihre Daten aktualisieren können. MongoDB bietet die Möglichkeit, [[bigdata:skalierung|Replikationen]] nach dem Master-Slave-Prinzip zu erstellen, die dabei helfen, die Lese-Last zu verteilen und eine gewisse Ausfallsicherheit zu garantieren. Dabei besteht ein Replica Set aus einem Master-Knoten (auch Primary genannt) und Reihe von Slave-Knoten (auch Secondary genannt). Alle Schreibzugriffe gehen über den Primary, der diese in einem „Oplog“ protokolliert, welches er dann an die Secondary-Knoten überträgt, damit diese ihre Daten aktualisieren können.
-Bei der Erweiterung eines Replica Sets sorgt MongoDB automatisch für die Datenverteilung. Sollte ein Primary ausfallen, wird er durch den Secondray ersetzt, der den aktuellsten Oplog hat. ([[bigdata:literatur|Beitter/Brödel 2015]])+Bei der Erweiterung eines Replica Sets sorgt MongoDB automatisch für die Datenverteilung. Sollte ein Primary ausfallen, wird er durch den Secondray ersetzt, der den aktuellsten Oplog hat. ([[bigdata:literatur#b|Beitter/Brödel 2015]])
  
-Zur Entlastung des Systems bei Schreibzugriffen und um zusätzlichen Speicher bereitzustellen, bietet MongoDB horizontale Skalierung auch in Form von [[bigdata:skalierung#horizontale_skalierung|Sharding]] an. Bei der Verteilung der Daten wird nach einem Shard-Schlüssel vorgegangen, der so festgelgt werden sollte, dass sich Daten einer Collection möglichst zusammen auf einem Server befinden (z.B. Personendaten nach Heimatland verteilt). Dabei wird eine Collection in sogenannte Chunks aufgeteilt, die Daten in einem Bereich des Shard-Keys beinhalten. Diese Chunks werden dann auf Server verteilt, die man Shards nennt. Dies alles geschieht automatisiert und bedeutet keine Ausfallzeit des Systems, unter Umständen aber eine gedrosselte Performance, abhängig von der Masse an Daten, die verschoben werden. (vgl. [[bigdata:literatur|Edlich et al. 2010: S.125f]]; [[bigdata:literatur|Sadalage/Fowler 2012: S. 96f]]).+Zur Entlastung des Systems bei Schreibzugriffen und um zusätzlichen Speicher bereitzustellen, bietet MongoDB horizontale Skalierung auch in Form von [[bigdata:skalierung#horizontale_skalierung|Sharding]] an. Bei der Verteilung der Daten wird nach einem Shard-Schlüssel vorgegangen, der so festgelgt werden sollte, dass sich Daten einer Collection möglichst zusammen auf einem Server befinden (z.B. Personendaten nach Heimatland verteilt). Dabei wird eine Collection in sogenannte Chunks aufgeteilt, die Daten in einem Bereich des Shard-Keys beinhalten. Diese Chunks werden dann auf Server verteilt, die man Shards nennt. Dies alles geschieht automatisiert und bedeutet keine Ausfallzeit des Systems, unter Umständen aber eine gedrosselte Performance, abhängig von der Masse an Daten, die verschoben werden. (vgl. [[bigdata:literatur#e|Edlich et al. 2010: S.125f]]; [[bigdata:literatur#s|Sadalage/Fowler 2012: S. 96f]]).
  
  
bigdata/mongodb.txt · Zuletzt geändert: 2015/10/05 21:22 von brueck