Databases Reference
In-Depth Information
In Abbildung 23.1 sehen wir die beiden Shard-Server, auf die die Dokumente ver-
teilt werden. Die Verteilung soll für den Anwender transparent sein; er erteilt nur
die Anweisungen zur Verarbeitung der Dokumente und muss sich nicht auf die
Suche nach dem richtigen Shard-Server machen. Dazu gibt es den Config-Server,
der dafür zuständig ist, die Dokumente auf die Shard-Server zu verteilen und
wiederzufinden. In Abhängigkeit von einem bestimmten Wert, kann der Config-
Server schnell ermitteln, zu welchem Shard-Server gesuchte oder neue Daten ge-
hören. Wenn die Dokumente etwa in Abhängigkeit vom Schlüssel
name
verteilt
wurden, dann ermittelt der Config-Server für die Anweisung
db.personen.find(name: 'Dagobert')
den Shard-Server, auf dem dieses Dokument liegt. Sharding kann also auch ein
Instrument zum Performance-Tuning sein: Es muss nicht mehr die ganze Collec-
tion durchsucht werden, sondern nur noch ein einzelner Shard. Damit der Config-
Server nicht zum Engpass wird und um das Risiko eines Ausfalls zu reduzieren,
können wir in einem MongoDB-Cluster mehrere Exemplare betreiben.
Der Anwender verbindet sich nicht direkt mit dem Config-Server, seine Schnitt-
stelle ist ein so genannter Router. Es kann beliebig viele dieser Router geben. Ihre
Aufgabe besteht darin, Rücksprache mit einem der Config-Server zu halten und
den Anwender dann mit dem richtigen Shard-Server zu verbinden.
Shard-Server
Shard-Server
Router
Config-Server
Abbildung 23.1:
Komponenten, die am Data-Sharding beteiligt sind
Im Produktivbetrieb werden zumindest die Shard-Server auf getrennten Maschi-
nen betrieben. Um die Funktionsweise des Sharding mit einfachen Mitteln zu er-
leben, starten wir vier Server, nämlich
zwei Shard-Server
einen Config-Server sowie
