Différence entre le fractionnement et la réplication sur MongoDB

77

Je suis simplement confus au sujet de la fragmentation et de la réplication que la façon dont ils fonctionnent. Selon Définition

Réplication: Un jeu de réplicas dans MongoDB est un groupe de processus mongod qui conservent le même jeu de données.

Sharding: Le Sharding est une méthode de stockage de données sur plusieurs machines.

Si j'ai bien compris, s'il y a des données de 75 Go, la réplication (3 serveurs) stockera 75 Go de données sur chaque serveur, ce qui signifie 75 Go sur le serveur 1, 75 Go sur le serveur 2 et 75 Go sur le serveur 3 .. si je me trompe) .. et en partageant, 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. (droit?) ... mais j'ai rencontré cette ligne le tutoriel

Les fragments stockent les données. Pour assurer la haute disponibilité et la cohérence des données, dans un cluster de production fragmenté, chaque fragment est un jeu de réplicas.

Comme le jeu de répliques est de 75 Go mais le fragment est de 25 Go, alors comment ils peuvent être équivalents ... cela me laisse perplexe ... Je pense que je manque quelque chose de génial à cet égard. S'il vous plait aidez moi avec ceci.

Saad Saadi
la source

Réponses:

111

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.

Philipp
la source
2
Merci beaucoup pour la réponse détaillée ... une dernière question ... si le primaire est en panne alors qu'une opération d'écriture ou de lecture est en cours, alors..1) quel est le délai de sélection du primaire parmi les secondaires et 2) pendant ce délai, où les données seront-elles stockées temporairement?
Saad Saadi
4
@SaadSaadi Le processus d'élection primaire est décrit dans la documentation . Il faut entre 10 et 12 secondes aux secondaires pour constater que le primaire est en panne. L'élection primaire elle-même ne prend généralement que quelques millisecondes. L'ensemble de réplicas est en lecture seule tant qu'il n'y a pas de primaire. Toute tentative des applications d’écrire des données pendant cette période échouera.
Philipp
1
@Philipp: Seulement deux commentaires: (1) la clé de partition ne peut pas être modifiée (vous ne pouvez pas utiliser une partition avec une clé différente) et (2) vous pouvez lire à partir des nœuds secondaires du jeu de réplicas, mais la cohérence dépend de la préoccupation d'écriture Pour être cohérent, l’option w doit être égale au réplica set sth, ce qui n’est pas viable car chaque fragment peut avoir différentes tailles de réplica, délibérément ou en raison de défaillances de nœuds.
Mike Argyriou le
@Philipp pouvez-vous répondre à d'autres questions complémentaires sur dba.stackexchange.com/questions/208482/… ?
user3198603
18
  • La fragmentation partitionne le jeu de données en parties distinctes.
  • La réplication duplique le jeu de données.

Ces deux choses peuvent s'empiler puisqu'elles sont différentes. L'utilisation des deux signifie que vous partagerez votre ensemble de données entre plusieurs groupes de réplicas. En d'autres termes, vous répliquez des fragments; un ensemble de données sans fragments est un «fragment» unique.

Un cluster Mongo avec trois fragments et 3 réplicas aurait 9 nœuds.

  • 3 jeux de répliques à 3 nœuds.
  • Chaque réplica-set contient un seul fragment.
sysadmin1138
la source
Pour un fichier volumineux, est-il stocké dans un ou plusieurs fragments (donc entre les nœuds)?
Tony
Notez que dans MongoDB 3.4 ou version ultérieure, vous aurez également besoin de serveurs mongoDB pour la configuration et d'un serveur supplémentaire pour agir en tant que routeur Mongos. Cela porte le total du cluster 3x3 dans votre exemple à 13 serveurs au total.
jeudi
9

En partageant , vous divisez votre collection en plusieurs parties.
Répliquer votre base de données signifie que vous faites des miroirs de votre ensemble de données.

haper
la source
4

En termes de fonctionnalité livrée. La fragmentation offre évolutivité et parallélisme. La réplication fournit la disponibilité

Ashish Kumar
la source
Nope, la réplication seulement fournit également l'évolutivité et le parallélisme étant donné que les lectures sont beaucoup plus fréquentes que les écritures
Kristóf Szalay