Databases Reference
In-Depth Information
db.runCommand({addshard: "localhost:4711", allowlocal: true})
db.runCommand({addshard: "localhost:4712", allowlocal: true})
Anschließend aktivieren wir das Sharding für die Datenbank
mydb
und in dieser
Datenbank für die Collection
numbers
. Jetzt fehlt nur noch das Kriterium, wel-
ches Dokument in welchen Shard gehört. Hier entscheiden wir, dass die Daten-
sätze in Abhängigkeit vom Schlüssel
col1
auf die Shards verteilt werden sollen:
db.runCommand({enablesharding: "mydb"})
db.runCommand({shardcollection : "mydb.numbers", key : {col1:1}})
Die Wahl des richtigen Shard-Key ist dabei ein komplexeres Thema, als es zu-
nächst scheint. Hier sind folgenreiche Fehler möglich, von denen einige in [Cho11]
beschrieben werden.
Wir wechseln jetzt zu der Datenbank, für die wir soeben das Sharding aktiviert
haben, und erzeugen mit JavaScript sehr viele Datensätze:
use mydb
for(var i=1; i<=20000000; i++){
db.numbers.insert({col1:i, col2:4711})
}
Wir beobachten jetzt das Wachstum der Dateien in den Verzeichnissen
ShardA
und
ShardB
. Zunächst wächst nur eines von beiden, und es scheint, als ob das
Sharding gar nicht aktiviert ist. Es dauert vielleicht einige Minuten, bis man sieht,
dass auch Daten im anderen Verzeichnis abgelegt werden. Ab jetzt beobachten
wir, wie MongoDB so genannte Chunks von Daten zunächst in das eine Verzeich-
nis, dann in das andere Verzeichnis einstellt. So wird eine Verteilung erreicht, die
sicher nicht 100% gleichmäßig, dafür aber sehr effizient ist.
Es ist leicht, ein Sharding-Szenario für den Testbetrieb zu entwickeln, aber auch
für den Produktivbetreib sind nicht wesentlich mehr Schritte erforderlich. Ähn-
lich einfach ist es, ein hochverfügbares System mit Hilfe von Replikation aufzuset-
zen. Beide Skalierungstechniken können kombiniert werden. Wenn jeder Shard-
Server mindestens einmal repliziert wird, reduziert sich die Wahrscheinlichkeit
dafür, dass Daten nicht mehr verfügbar sind, dramatisch. Etablierte RDBMS bie-
ten diese Möglichkeiten in unterschiedlichem Umfang, doch können hier - wie
schon erwähnt - erhebliche Lizenzgebühren anfallen.
In diesem Kapitel haben wir MongoDB nicht zuletzt darum vorgestellt, weil die
Ideen, die hinter diesem DBMS stecken, noch mit relationaler Denkweise greif-
bar sind. Andere NoSQL-Systeme erlauben nicht einmal den Zugriff auf einzelne
Datensätze mit Hilfe von Prädikaten; hier ist nur der sequentielle Zugriff möglich.
