Un ensemble de répliques signifie que vous avez plusieurs instances de MongoDB qui reflètent toutes les données les unes des autres. Un ensemble de réplicas comprend un maître (également appelé "primaire") et un ou plusieurs esclaves (ou secondaire). Les opérations de lecture peuvent être exécutées par n'importe quel esclave. Vous pouvez donc améliorer les performances de lecture en ajoutant davantage d'esclaves au jeu de réplicas (à condition que votre application cliente puisse réellement utiliser différents membres de l'ensemble). Toutefois, les opérations d'écriture ont toujours lieu sur le maître du jeu de réplicas et sont ensuite propagées aux esclaves. Par conséquent, les écritures ne seront pas plus rapides si vous ajoutez d'autres esclaves.
Les ensembles de répliques offrent également une tolérance aux pannes. Lorsqu'un des membres de l'ensemble de répliques tombe en panne, les autres prennent la relève. Lorsque le maître tombe en panne, les esclaves élisent un nouveau maître. Pour cette raison, il est conseillé, pour un déploiement productif, d’utiliser toujours MongoDB en tant que jeu de réplicas d’au moins trois serveurs, dont deux contiennent des données (le troisième est un "arbitre" sans données, indispensable pour déterminer un nouveau maître lorsque un des esclaves tombe en panne).
Un cluster fractionné signifie que chaque fragment du cluster (qui peut également être un jeu de réplicas) prend en charge une partie des données. Chaque demande, à la fois en lecture et en écriture, est traitée par le cluster où résident les données. Cela signifie que les performances en lecture et en écriture peuvent être améliorées en ajoutant plus de fragments à un cluster. Le document qui réside sur quel fragment est déterminé par la clé de fragment de chaque collection. Il doit être choisi de manière à ce que les données puissent être réparties uniformément sur toutes les grappes et à ce que les requêtes les plus courantes où la clé de fragmentation réside soient clairement définies (exemple: lorsque vous interrogez fréquemment par user_name, votre clé de fragmentation doit inclure le champ de user_namesorte que chaque requête peut être déléguée à seulement celui tesson qui a ce document).
L'inconvénient est que la tolérance aux pannes en souffre. Lorsqu'un fragment du cluster tombe en panne, toutes les données qu'il contient sont inaccessibles. Pour cette raison, chaque membre du cluster doit également être un jeu de réplicas. Ce n'est pas obligatoire. Lorsque vous ne vous souciez pas de la haute disponibilité, un fragment peut également être une instance unique de mongod sans réplication . Mais pour une utilisation en production, vous devez toujours utiliser la réplication .
Alors qu'est-ce que cela signifie pour votre exemple?
Sharded Cluster
/ | \
Shard A Shard B Shard C
/ \ / \ / \
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
|Primary| |Secondary| |Primary| |Secondary| |Primary| |Secondary|
| 25GB |=| 25GB | | 25 GB |=| 25 GB | | 25GB |=| 25GB |
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
Lorsque vous souhaitez fractionner vos données de 75 Go en 3 fragments de 25 Go chacun, vous avez besoin d'au moins 6 serveurs de base de données organisés en trois jeux de réplicas. Chaque réplica-set est constitué de deux serveurs qui ont les mêmes 25 Go de données.
Vous avez également besoin de serveurs pour les arbitres des trois jeux de réplicas, ainsi que du routeur Mongos et du serveur de configuration pour le cluster. Les arbitres sont très légers et ne sont nécessaires que lorsqu'un membre de l'ensemble de réplicas tombe en panne. Ils peuvent donc généralement partager le même matériel avec autre chose. Mais le routeur Mongos et le serveur de configuration doivent être redondants et sur leurs propres serveurs.