Ein Replica-Set bedeutet, dass Sie mehrere Instanzen von MongoDB haben, die alle Daten voneinander spiegeln. Ein Replikat-Set besteht aus einem Master (auch "Primary" genannt) und einem oder mehreren Slaves (auch "Secondary" genannt). Lesevorgänge können von jedem Slave ausgeführt werden, sodass Sie die Leseleistung steigern können, indem Sie dem Replikatsatz weitere Slaves hinzufügen (vorausgesetzt, Ihre Clientanwendung kann tatsächlich verschiedene Set-Member verwenden). Schreibvorgänge finden jedoch immer auf dem Master des Replikat-Sets statt und werden dann an die Slaves weitergegeben, sodass das Schreiben nicht schneller wird, wenn Sie weitere Slaves hinzufügen.
Replikat-Sets bieten auch Fehlertoleranz. Wenn eines der Mitglieder des Replikat-Sets ausfällt, übernehmen die anderen. Wenn der Master abstürzt, wählen die Slaves einen neuen Master. Aus diesem Grund wird für eine produktive Bereitstellung empfohlen , MongoDB immer als Replikat-Set von mindestens drei Servern zu verwenden, von denen zwei Daten enthalten (der dritte ist ein datenloser "Arbiter", der zur Bestimmung eines neuen Masters erforderlich ist, wenn einer der Sklaven geht unter).
Ein Sharded Cluster bedeutet, dass jeder Shard des Clusters (der auch ein Replikatsatz sein kann) einen Teil der Daten verwaltet. Jede Anforderung, sowohl Lese- als auch Schreibzugriff, wird von dem Cluster bedient, in dem sich die Daten befinden. Dies bedeutet, dass sowohl die Lese- als auch die Schreibleistung gesteigert werden kann, indem einem Cluster mehr Shards hinzugefügt werden. Welches Dokument sich auf welchem Shard befindet, wird durch den Shard-Schlüssel jeder Sammlung bestimmt. Es sollte so gewählt werden, dass die Daten gleichmäßig auf alle Cluster verteilt werden können und für die häufigsten Abfragen, in denen sich der Shard-Key befindet, klar ist (Beispiel: Wenn Sie häufig nach fragen user_name, sollte Ihr Shard-Key den enthalten Feld, user_nameso dass jede Abfrage nur an den einen Shard delegiert werden kann, der dieses Dokument enthält).
Der Nachteil ist, dass die Fehlertoleranz leidet. Wenn ein Shard des Clusters ausfällt, kann auf keine Daten zugegriffen werden. Aus diesem Grund sollte jedes Mitglied des Clusters auch ein Replikatsatz sein. Dies ist nicht erforderlich. Wenn Sie sich nicht für Hochverfügbarkeit interessieren, kann ein Shard auch eine einzelne mongod-Instanz ohne Replikation sein . Aber für produktions verwenden sollten Sie immer die Replikation verwenden .
Was bedeutet das für Ihr Beispiel?
Sharded Cluster
/ | \
Shard A Shard B Shard C
/ \ / \ / \
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
|Primary| |Secondary| |Primary| |Secondary| |Primary| |Secondary|
| 25GB |=| 25GB | | 25 GB |=| 25 GB | | 25GB |=| 25GB |
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
Wenn Sie Ihre Daten mit 75 GB in 3 Shards mit jeweils 25 GB aufteilen möchten, benötigen Sie mindestens 6 Datenbankserver, die in drei Replikatsätzen organisiert sind. Jeder Replikatsatz besteht aus zwei Servern mit denselben 25 GB Daten.
Sie benötigen außerdem Server für die Arbiter der drei Replikatsätze sowie den Mongos-Router und den Konfigurationsserver für den Cluster. Die Arbiter sind sehr kompakt und werden nur benötigt, wenn ein Mitglied der Replikatgruppe ausfällt. Daher können sie in der Regel dieselbe Hardware mit etwas anderem gemeinsam nutzen. Aber Mongos Router und Config-Server sollten redundant und auf eigenen Servern sein.
Diese beiden Dinge können gestapelt werden, da sie unterschiedlich sind. Wenn Sie beides verwenden, werden Sie Ihren Datensatz über mehrere Gruppen von Replikaten hinweg teilen. Anders ausgedrückt: Du replizierst Scherben. Ein Datensatz ohne Scherben ist eine einzelne "Scherbe".
Ein Mongo-Cluster mit drei Scherben und drei Repliken hätte 9 Knoten.
quelle
Durch sharding spaltete Sie Ihre Sammlung in mehrere Teile.
Wenn Sie Ihre Datenbank replizieren, wird Ihr Datensatz gespiegelt.
quelle
In Sachen Funktionalität geliefert. Sharding bietet Skalierbarkeit und Parallelität. Replikation sorgt für Verfügbarkeit
quelle