Sharding
Unter Sharding wird das horizontale Skalieren verstanden, hierbei werden viele kostengünstige Systeme zusammengeschaltet und Daten über die Systeme hinweg verteilt. Diese werden nicht willkürlich verteilt, sondern nach einem speziellem Prinzip, dem Partitionieren. Dabei werden die Daten anhand des Shardingkeys (Feld im Dokument) auf die einzelnen Maschinen aufgeteilt (in sog. Chunks). Reihenfolge der Dokumente bleibt bestehen, hierbei sollte darauf geachtet werden, dass der Shardingkey so gewählt wird, das er viele Variationen zulässt, damit die Dokumente gleichmässig verteilt werden. Falls die Variationen der einzelnen Felder ungünstig sind, können auch mehrere Felder kombiniert werden. Die aufgesplitteten Daten (Chunks) liegen nun in einem gewissen Wertebereich und werden durch eine obere Grenze und eine untere Grenze beschränkt. Diese wird auf einem Config-Server hinterlegt, er stellt somit eine Art "Telefonbuch" dar und kann jederzeit Auskunft erteilen, wo welches Dokument liegt.
MongoDB Balancing
Kommt man an die physikalischen Grenzen eines Servers, wird die Last und die Daten automatisch auf mehrere Server verteilt. Hiermit wird durch das Cluster dafür gesorgt, dass immer genügend Ressourcen für die Anfragen zur Verfügung stehen. Gleichzeitig wird darauf geachtet, wenn ein Fehler bei einem Shard (einer Datenpartitionierung) auftritt, dieser deaktiviert wird und keine Anfragen mehr an diesen weitergeleitet werden, da diese auch nicht mehr verarbeitet werden können.
Vorteile von Sharding
- Aufteilen von großen Datenmengen über mehrere Server hinweg
- Verteilen von ressourcenintensiven Schreiboperationen auf mehrere Systeme
Beispiel für ein Shardingcluster, entnommen aus Boeker (2010)
Ein Sharding-Cluster besteht aus drei Komponenten, die über das Netzwerk kommunizieren und meistens als Serverprozess ausgelegt sind.
- Shards, meist als Replica Sets, welche aus mongodb-Prozessen bestehen
- Config-Servern, welche die Metadaten des Clusters verwalten
- Mongos-Prozesse, welche als Router dienen
Shardingbeispiel
Beispielcollection
| Name | Alter | |
| Max Mustermann | max.mustermann@muster.de | 30 |
| Moritz Mustermann | moritz.mustermann@muster.de | 25 |
| Karin Schmitz | karin.schmitz@schmitz.de | 40 |
Chunktabelle aufgeteilt nach Alter
| Chunk/Server | Untere Altersgrenze | Obere Altersgrenze |
| 1 | 15 | 25 |
| 2 | 26 | 35 |
| 3 | 36 | 45 |
In diesem Beispiel ist der Shardingkey das Alter der User. Im Configserver sind drei verschiedene Chunks hinterlegt, wobei jedem dieser Chunks ein ganz bestimmter Altersbereich zugeteilt wurde. Wenn nun ein neues Dokument gespeichert werden soll, wird anhand des Alters (Wert des Shardingkeys im Dokument) der entsprechende Server und Chunk im Config-Server rausgesucht. Danach wird das Dokument an den passenden Server übermittelt und direkt dort gespeichert.