Différence entre partitionnement et réplication sur MongoDB
Je suis juste confus quant au fonctionnement du partage et de la réplication.
Selon les définitions que j'ai trouvées dans la documentation:
Réplication: un jeu de répliques dans MongoDB est un groupe de processus mongod qui conservent le même jeu de données.
Sharding: Sharding est une méthode pour stocker des données sur plusieurs machines.
Selon ma compréhension, si j'ai 75 Go de données, puis en utilisant la réplication (3 serveurs), il stockera 75 Go de données sur chaque serveur, soit 75 Go sur le serveur 1, 75 Go sur le serveur 2 et 75 Go sur le serveur 3. (Corrigez-moi si je me trompe).
Et en utilisant le partitionnement, il sera stocké sous forme de données de 25 Go sur le serveur-1, de 25 Go sur le serveur-2 et de 25 Go sur le serveur-3. (Droite?).
Mais j'ai rencontré cette ligne dans le tutoriel:
Les fragments stockent les données. Pour fournir une haute disponibilité et une cohérence des données, dans un cluster partagé en production, chaque fragment est un jeu de réplicas
Comme un jeu de répliques a une taille de 75 Go, mais un fragment a une taille de 25 Go, alors comment peut-il être équivalent?
Cela me rend assez confus. Je pense que je manque quelque chose d'évident. S'il vous plait, j'ai besoin de votre aide avec ceci.
Un Replica-Set signifie que vous avez plusieurs instances de MongoDB qui reflètent chacune toutes les données les unes des autres. Un jeu de répliques se compose d'un maître (également appelé "primaire") et d'un ou plusieurs esclaves (alias secondaire). Les opérations de lecture peuvent être servies par n'importe quel esclave, vous pouvez donc augmenter les performances de lecture en ajoutant plus d'esclaves à l'ensemble de réplicas (à condition que votre application cliente soit capable d'utiliser réellement différents membres de l'ensemble). Mais les opérations d'écriture ont toujours lieu sur le maître du jeu de réplicas et sont ensuite propagées aux esclaves, de sorte que les écritures ne seront pas plus rapides lorsque vous ajoutez d'autres esclaves.
Les jeux de répliques offrent également une tolérance aux pannes. Lorsque l'un des membres du jeu de répliques tombe en panne, les autres prennent le relais. Lorsque le maître descend, les esclaves élisent un nouveau maître. Pour cette raison il est suggéré pour que le déploiement productif utilise toujours MongoDB comme un jeu de répliques d'au moins trois serveurs, deux d'entre eux contenant des données (le troisième est un "arbitre" sans données qui est nécessaire pour déterminer un nouveau maître lorsque l'un des esclaves tombe en panne).
Un cluster éclaté signifie que chaque fragment du cluster (qui peut également être un jeu de répliques) prend soin d'une partie des données. Chaque requête, en lecture et en écriture, est servie 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. Quel document réside sur quelle partition est déterminée par la clé de partition de chaque collection. Il doit être choisi de manière à ce que les données puissent être réparties uniformément sur tous les clusters et de sorte qu'il soit clair pour les requêtes les plus courantes où réside la clé de partition (exemple: lorsque vous interrogez fréquemment par user_name, votre clé de partition doit inclure le champ user_name afin que chaque requête puisse être déléguée à la seule partition qui possède 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 seule instance 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 diviser 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épliques. Chaque jeu de répliques se compose 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épliques 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 du jeu de répliques 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.
- Sharding partitionne l'ensemble de données en parties discrètes.
- Réplication duplique l'ensemble de données.
Ces deux choses peuvent s'empiler car elles sont différentes. L'utilisation des deux signifie que vous répartirez votre ensemble de données sur plusieurs groupes de répliques. Autrement dit, vous répliquez des fragments; un ensemble de données sans fragments est un seul "fragment".
Un cluster Mongo avec trois fragments et 3 répliques aurait 9 nœuds.
- 3 ensembles de répliques à 3 nœuds.
- Chaque jeu de réplicas contient un seul fragment.
En sharding, vous divisez votre collection en plusieurs parties.
réplication votre base de données signifie que vous faites des miroirs de votre ensemble de données.
En termes de fonctionnalités livrées. Le sharding fournit l'évolutivité et le parallélisme. La réplication assure la disponibilité