Concepts du partitionnement : blocs, équilibreur et clés de partition

Le partitionnement est la stratégie de mise à l’échelle horizontale de MongoDB. Au lieu de stocker toutes les données dans un seul ensemble de réplication, un cluster partitionné répartit les données entre plusieurs partitions, chacune étant elle-même un ensemble de réplication. Vous pouvez ainsi faire évoluer horizontalement le stockage, le débit et la mémoire en ajoutant des partitions à mesure que vos données augmentent.

Un cluster partitionné possède trois rôles : Partitions — ensembles de réplication qui stockent les données réelles. mongos — routeur de requêtes qui reçoit les connexions des clients et achemine les opérations vers la ou les partitions appropriées. Serveurs de configuration — ensemble de réplication qui stocke les métadonnées du cluster, notamment les plages de clés de partitionnement et l’emplacement des segments. Les clients se connectent toujours à mongos, jamais directement aux partitions.

La clé de partitionnement est un champ, ou un ensemble de champs, que vous choisissez lors du partitionnement d’une collection. MongoDB utilise la valeur de cette clé pour déterminer à quelle partition appartient un document. Chaque document d’une collection partitionnée doit contenir la clé de partitionnement, et cette clé est immuable : vous ne pouvez pas la modifier après le partitionnement. Choisir la mauvaise clé de partitionnement est l’erreur de mise à l’échelle MongoDB la plus courante.

MongoDB divise la plage de la clé de partitionnement en segments — des plages contiguës de valeurs de clé de partitionnement. Chaque segment réside sur une seule partition. Par défaut, un segment peut atteindre 128 Mo avant que MongoDB ne le divise en deux segments plus petits. La partition sur laquelle réside chaque segment est suivie dans les métadonnées du serveur de configuration.

Le rééquilibreur est un processus d’arrière-plan qui surveille la répartition des segments entre les partitions. Si une partition possède beaucoup plus de segments que les autres (par défaut, une différence d’au moins 8), le rééquilibreur migre des segments de la partition la plus chargée vers des partitions moins sollicitées. Les migrations se produisent automatiquement et tentent d’éviter les périodes de trafic maximal.

Lorsqu’une requête inclut la clé de partitionnement, mongos l’achemine directement vers la ou les quelques partitions qui contiennent les documents correspondants : il s’agit d’une requête ciblée. Lorsque la requête n’inclut pas la clé de partitionnement, mongos doit l’envoyer à toutes les partitions et fusionner les résultats : il s’agit d’une requête de diffusion générale. Les requêtes ciblées sont considérablement plus rapides. Concevez vos requêtes autour de la clé de partitionnement pour obtenir les meilleures performances.

Un fragment chaud (ou point chaud) apparaît lorsqu’une part disproportionnée des lectures ou des écritures arrive sur un seul fragment. Causes courantes : l’utilisation d’une clé de partitionnement qui augmente de manière monotone (comme createdAt ou ObjectId), de sorte que toutes les nouvelles insertions vont toujours dans le bloc le plus élevé, ou l’utilisation d’une clé à faible cardinalité (comme une valeur booléenne), qui limite le parallélisme. Les fragments chauds annulent les avantages du partitionnement.

Un bloc jumbo est un bloc qui a dépassé la taille maximale, mais qui ne peut pas être divisé parce que tous ses documents partagent la même valeur de clé de partitionnement. Les blocs jumbo ne peuvent pas être migrés par l’équilibreur et créent un déséquilibre persistant. La solution consiste à choisir une clé de partitionnement avec une cardinalité suffisante afin qu’aucune valeur de clé ne corresponde à davantage de documents qu’un seul bloc ne peut en contenir.

sh.status() donne une vue complète de votre cluster partitionné : les collections partitionnées, le nombre de blocs présents sur chaque fragment et les intervalles de clés détenus par chaque fragment. Utilisez-le pour repérer rapidement une distribution déséquilibrée des blocs et confirmer que l’équilibreur a terminé les migrations après l’ajout d’un nouveau fragment.

L’ajout d’un fragment à un cluster en fonctionnement est une opération en ligne. L’équilibreur migre automatiquement les blocs des fragments existants vers le nouveau fragment au fil du temps. Vous pouvez prédécouper les blocs avant d’ajouter un fragment afin d’accélérer la distribution initiale, notamment lors du chargement massif de données. L’ajout de fragments ne nécessite aucune interruption de service.

Le partitionnement ajoute une complexité opérationnelle. Avant de partitionner, épuisez les possibilités de mise à l’échelle verticale et d’indexation. Déclencheurs courants du partitionnement : un volume de données > 1–2 TB sur un jeu de réplicas unique, un débit d’écriture qui sature un nœud primaire unique, ou un jeu de travail qui ne tient plus dans la RAM. Effectuez toujours des évaluations comparatives avec explain() et le profilage avant de décider de partitionner.

Dans cette leçon, vous avez appris que : le partitionnement distribue les données entre plusieurs fragments (jeux de réplicas) à l’aide d’une clé de partitionnement, les blocs sont des intervalles contigus de clés de partitionnement que l’équilibreur migre afin de maintenir une distribution uniforme, et les requêtes ciblées (incluant la clé de partitionnement) sont bien plus efficaces que les requêtes de diffusion-collecte. Nous allons maintenant voir comment choisir la bonne clé de partitionnement.