Mongo Dans Tous Ses Etats – Sharding

La suite de mon étude concernait le processus de sharding. Comme pour la réplication, les informations proviennent cette fois du guide sur le sharding.

Sharding

Le sharding divise la donnée et la distribue sur plusieurs machines, aussi appelé shard et résout ainsi le problème de scaling horizontal. Un cluster est constitué de shard, serveur de configuration et mongos. Le sharding réduit la quantité de donnée que chaque serveur doit stocker, ainsi que le nombre d’opérations à effectuer.

Sharded cluster = shards + query routers (mongos) + config servers

Shard (mongod / Replica Set)

Stock la donnée.
En production, pour des questions de haute disponibilité et de consistence des données, chaque shard est un replica set et le cluster est constitué de deux shards ou plus.

Query Router (mongos)

Sert d’interface avec l’application cliente et dirige les opérations vers le shard approprié. Un cluster peut contenir plusieurs routeurs pour distribuer la charge.

En production, un mongos ou plus.
Les curseurs et d’autres ressources étant spécifique à une instance de mongos, chaque client doit interagir avec seulement un mongos.

Config Server

Stock les métadatas du cluster.
Contient un mapping entre les données du cluster et les shards (Quelle donnée se trouve sur quel shard). En production, un cluster possède exactement 3 config servers.

Si un ou deux serveurs de configuration deviennent indisponible, les métadatas du cluster passe en lecture seule jusqu’à ce que les trois serveurs soient à nouveau disponible. Il est toujours possible de lire et d’écrire sur les shards mais aucune migration et aucun découpage n’aura lieu sur les chunks.

Les sauvegardes de ces serveurs sont critiques.
Si le nom ou l’adresse qu’un cluster utilise pour se connecter à un serveur de configuration change, il est nécessaire de redémarrer tous les mongod et les mongos! D’où l’utilité des CNAMEs pour identifier les serveurs de configuration.

Chaque serveur doit être sur une machine séparée.

Partitionnement des données

Le partitionnement s’effectue en utilisant une clé de sharding (sharding key).

Shard Key

Soit un champ indexé ou champ indexé composé existant dans tous les documents de la collection. MongoDB divise la shard key en morceaux (chunks) et les distribue de manière égale entre les shards. La division de la clé s’effectue soit avec un range based partitioning ou un hash based partitioning.

Pour sélectionner une shard key, déterminer les champs communément inclut dans les requêtes pour une application précise et déterminer quelles opérations demandent le plus de performance.

L’index sur la shard key ne peut pas être un multikey index.

Range Based Sharding

Séparation des données en plusieurs intervalles. Deux documents avec une clé de sharding proche ont de grandes chances d’être dans le même chunk. Néanmoins, il peut en résulter une distribution inégale des données sur les shards. Plus efficace en cas de requêtes sur des intervalles. Le router peut déterminé plus facilement vers quels shards diriger la requête.

Hash Based Sharding

MongoDB calcule un hash de la valeur du champ et utilise ces hashs pour créer les chunks. Deux documents avec une clé de sharding proche ont très peu de chance d’être dans le même chunk. Cela permet de s’assurer d’une distribution plus aléatoire des données au sein du cluster et assure une distribution régulière des données sur les shards. Une requête sur un intervalle à de grande chance de s’adresser à tous les shards.

Mécanismes

Mongo dispose de mécanismes pour éviter qu’un shard devienne trop grand: splitting et le balancer.

Splitting

Lorsqu’un chunk devient trop grand, mongo le divise en deux.
Ceci n’affecte pas les données ou les shards.

Balancing

Permet de migrer des chunks. Lorsque la distribution des données devient irrégulière, le balancer va migrer des chunks du shard avec le plus grande nombre de chunks à celui qui en possède le moins. Les données sont retirés du shard d’origine après une migration totale et réussie des données.

Anonyme

Auteur/autrice : Victor

Ingénieur en informatique de formation et de métier, j’administre ce serveur et son domaine et privilégie l'utilisation de logiciels libres au quotidien. Je construis progressivement mon "cloud" personnel service après service pour conserver un certain contrôle sur mes données numériques.

3 réflexions sur « Mongo Dans Tous Ses Etats – Sharding »

  1. Bonjour,

    Merci pour ces conseils sur le choix de la clé de sharding. J’ai cependant un problème et j’espère pouvoir trouver de l’aide avec vous.

    Je dois mettre en place un sharded cluster constitué de 2 shards pour stocker des logs d’une certaine plateforme. On me demande de dédier un nœud à la lecture. Je ne sais pas vraiment comment le faire. Est-ce que la solution se trouve dans le bon choix de la clé de sharding? Si oui, comment faire? Sinon, comment pourrais-je le faire autrement?

    1. Bonjour,

      La demande de n’effectuer la lecture que sur un seul des shards me semble plutôt étrange (j’imagine que la demande est justifiée par un contexte particulier) étant donné que l’intérêt du sharding et de répartir la donnée sur plusieurs instances (les shards) et donc de répartir la charge des lectures et des écritures sur plusieurs machines.

      En revanche, si chaque shard est un replica set (un groupe de mongod avec la même donnée), dans ce cas-là, il est effectivement possible de spécifier une préférence de lecture. Le comportement par défaut au niveau d’un replica set étant que le client va lire sur l’instance principale (primary) du replica.

      À ma connaissance, le seul moyen d’arriver à une situation semblable à ce que l’on vous demande, serait de s’assurer que le choix de la clé de sharding dirige toutes les données qui seront lues vers le shard dédié à la lecture. Mais dans ce cas, l’autre shard ne contient que des données « mortes » (pas lues, donc pas chargées en mémoire par mongo). Dans une telle situation, on aurait donc réparti (éventuellement) la charge en écriture, pas en lecture et l’intérêt du shard me semble un peu amoindri. Cela demande donc de connaître exactement les données qui seront lues, selon quels critères et de choisir les mécanismes de sharding en conséquence.

      Je vous invite également à regarder du côté du « Tag Aware Sharding » (https://docs.mongodb.com/manual/core/tag-aware-sharding/) qui doit pouvoir vous aider à diriger plus ou moins les données vers un shard ou un autre.

      1. Bonjour cher tous,

        Merci Victor pour cet éclaircissement de l’intérêt du sharding. Cette exigence m’a semblé tout aussi étrange. Il fallait que j’en sache plus. Tes explications m’ont vraiment aidé.

        Merci.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *