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.