Database Reference
In-Depth Information
5.4 Tag 3: Replica-Sets, Sharding, GeoSpatial und GridFS
Mongo hat leistungsfähige Möglichkeiten, Daten auf unterschiedliche Art
und Weise zu speichern und abzurufen. Andererseits können das andere
Datenbanken auch. Was Dokumenten-Datenbanken so einzigartig macht,
ist ihre Fähigkeit, beliebig verschachtelte, schemafreie Datendokumente zu
verarbeiten. Was Mongo im Bereich der Dokumentenspeicher zu etwas Be-
sonderem macht, ist seine Fähigkeit, über mehrere Server zu skalieren. Es
kann Collections replizieren (auf andere Server kopieren) oder in mehrere
Teile zerlegen (Sharding) und Queries parallel ausführen. Das erhöht die Ver-
fügbarkeit.
Replica-Sets
Mongo wurde nicht als Standalone-Lösung entwickelt, sondern um zu wach-
sen. Datenkonsistenz und Partitionstoleranz sind wichtige Aspekte, doch die
Aufteilung von Daten (Sharding) hat ihren Preis: Geht ein Teil einer Collec-
tion verloren, wirkt sich das auf alle Daten aus. Wie gut kann die Abfrage
einer Länder-Collection sein, wenn sie nur die westliche Hemisphäre ent-
hält? Mongo löst diese implizite Sharding-Schwäche auf ganz einfache Wei-
se: Duplikation. Sie werden in der Produktion keine einzelne Mongo-Instanz
einsetzen, sondern die Daten über mehrere Services replizieren.
Heute halten wir uns nicht mit der vorhandenen Datenbank auf, sondern
beginnen von vorne und starten einige neue Server. Mongos Standardport
ist 27017, weshalb wir jedem Server einen anderen Port geben. Denken Sie
daran, dass Sie zuerst die Datenverzeichnisse erzeugen müssen, weshalb wir
drei davon anlegen:
$ mkdir
./mongo1 ./mongo2 ./mongo3
