Dans Mongo, quelle est la différence entre le sharding et la réplication ?

Question

La réplication semble être beaucoup plus simple que le sharding, à moins que je ne manque les avantages de ce que le sharding tente de réaliser. Ne fournissent-ils pas tous deux une mise à l'échelle horizontale ?

Answer 1

Dans le contexte de la mise à l'échelle de MongoDB :

• réplication crée des copies supplémentaires des données et permet un basculement automatique vers un autre nœud. La réplication peut aider à la mise à l'échelle horizontale des lectures si vous êtes d'accord pour lire des données qui ne sont potentiellement pas les plus récentes.

• sharding permet une mise à l'échelle horizontale des écritures de données en partitionnant les données sur plusieurs serveurs à l'aide d'un système de gestion des données. clé de répartition . Il est important de choisir une bonne clé d'éclats . Par exemple, un mauvais choix de clé de shard peut conduire à des "points chauds" de données qui ne sont écrites que sur un seul shard.

Un environnement sharded ajoute plus de complexité parce que MongoDB doit maintenant gérer la distribution des données et des demandes entre les shards -- des processus de configuration et de routage supplémentaires sont ajoutés pour gérer ces aspects.

La réplication et le sharding sont généralement combinés pour créer un système d'échange de données. cluster sharded où chaque tesson est soutenu par un ensemble de répliques.

Du point de vue de l'application client, vous disposez également d'un certain contrôle sur l'interaction réplication/sharding, en particulier :

• Préférences de lecture
• Écrire les préoccupations

Answer 2

Considérez que vous avez une grande collection de musique sur votre disque dur, vous stockez la musique dans un ordre logique basé sur l'année de sortie dans différents dossiers. Vous craignez de perdre votre collection en cas de défaillance du disque. Vous vous procurez donc un nouveau disque et copiez occasionnellement toute la collection en conservant la même structure de dossiers.

Sharding >> Conserver vos fichiers musicaux dans différents dossiers

Réplication >> Synchronisation de votre collection sur d'autres lecteurs

Answer 3

La réplication est une configuration maître/esclave traditionnelle, les données sont synchronisées avec les membres de sauvegarde et si le primaire tombe en panne, l'un d'eux peut prendre sa place. Il s'agit d'un outil raisonnablement simple. Il est principalement destiné à la redondance, bien que vous puissiez faire évoluer les lectures en ajoutant des membres de l'ensemble de répliques. C'est un peu compliqué, mais cela fonctionne très bien pour certaines applications.

Le sharding se situe au-dessus de la réplication, généralement. Les "Shards" dans MongoDB sont juste des ensembles de répliques avec quelque chose appelé "routeur" devant eux. Votre application se connectera au routeur, émettra des requêtes et décidera vers quel jeu de répliques (shard) elle doit se diriger. C'est beaucoup plus complexe qu'un seul ensemble de répliques, car il faut s'occuper du routeur et des serveurs de configuration (qui gardent la trace de l'emplacement des données).

Si vous voulez faire évoluer Mongo horizontalement, vous devez utiliser le shard. 10gen aime appeler la configuration du serveur routeur/configuration "auto-sharding". Il est possible de faire une forme plus ghetto de sharding où l'application décide également à quelle BD écrire.

Answer 4

Sharding

Le sharding est une technique permettant de répartir une grande collection entre plusieurs serveurs. Lorsque nous partageons, nous déployons plusieurs mongod serveurs. Et à l'avant, mongos qui est un routeur. L'application communique avec ce routeur. Ce routeur parle ensuite à différents serveurs, le mongod s. La demande et le mongos sont généralement hébergés sur le même serveur. On peut avoir plusieurs mongos services fonctionnant sur la même machine. Il est également recommandé de garder un ensemble de multiples mongod (appelés ensemble jeu de répliques ), au lieu d'un seul mongod sur chaque serveur. Un jeu de répliques permet de synchroniser les données sur plusieurs instances différentes, de sorte que si l'une d'entre elles tombe en panne, nous ne perdons aucune donnée. Logiquement, chaque ensemble de répliques peut être considéré comme un tesson . C'est transparent pour l'application, de la même manière que pour les autres. MongoDB choisit de sharder est que nous choisissons un clé de répartition .

Supposons, pour student collection nous avons stdt_id comme la clé du tesson ou ce pourrait être une clé composée. Et la mongos serveur, c'est un système basé sur la portée. Donc, basé sur le stdt_id que nous envoyons comme clé de shard, il enverra la demande à la bonne mongod instance.

Alors, que devons-nous vraiment savoir en tant que développeur ?

• insert doit inclure une clé de shard, donc si c'est une clé de shard multi-parties, nous devons inclure la clé de shard entière
• nous devons comprendre ce qu'est la clé du shard sur la collection elle-même.
• pour un update , remove , find - si mongos n'a pas de clé d'entrepôt, il va devoir diffuser la demande à tous les entrepôts qui couvrent la collection.
• pour un update - si nous ne spécifions pas la clé entière du shard, nous devons faire une mise à jour multiple pour qu'il sache qu'il doit la diffuser.

Answer 5

Chaque fois que vous pensez au sharding ou à la réplication, vous devez penser dans le contexte des opérations d'écriture/mise à jour. Si vous n'avez pas besoin de mettre à l'échelle les écritures, la réplication, plus simple, est un bon choix pour vous.

D'un autre côté, si vous chargez principalement des mises à jour/écritures, vous rencontrerez à un moment donné un goulot d'étranglement en écriture. Si une demande d'écriture arrive, Mongo bloque les autres demandes d'écriture. Ces demandes d'écriture sont bloquées jusqu'à ce que la première demande soit terminée. Si vous voulez faire évoluer ces écritures et les paralléliser, vous devez mettre en œuvre le sharding.