ApsaraDB for MongoDB:Présentation des clusters fragmentés MongoDB

Quand utiliser un cluster fragmenté ?

Comment déterminer le nombre de shards et de nœuds mongos ?

Sélection de la clé de fragmentation

• Stratégies de fragmentation prises en charge par les clusters fragmentés MongoDB

  • La fragmentation par plage prend en charge les requêtes de plage basées sur la clé de fragmentation.

  • La fragmentation par hachage répartit uniformément les écritures entre les shards.

  • La fragmentation consciente des tags vous permet de personnaliser les règles de distribution des chunks.

    Remarque

    • Fonctionnement

      1. Utilisez sh.addShardTag() pour définir le tag A sur un shard.

      2. Utilisez sh.addTagRange() pour définir le tag A sur une plage de chunks d'une collection. MongoDB veille ensuite à ce que la plage de chunks avec le tag A, ou un sur-ensemble de cette plage, soit distribuée sur le shard portant le tag A.

    • Scénarios

      • Définissez des tags de centre de données sur des shards déployés dans différents centres de données. Cela permet de distribuer les données de différentes plages de chunks vers les centres de données spécifiés.

      • Définissez des tags de niveau de service sur des shards ayant différentes capacités de service. Cela permet de distribuer davantage de chunks vers les shards disposant de capacités supérieures.

    • Remarques

      ApsaraDB for MongoDB ne peut pas distribuer directement les chunks vers les nœuds de shard étiquetés avec les tags spécifiés. Les chunks sont progressivement distribués à mesure que le fractionnement et la migration des chunks sont fréquemment déclenchés par les opérations d'insertion et de mise à jour. Assurez-vous que l'équilibreur de charge est activé pendant le processus de distribution. Après l'ajout de tags aux plages de chunks, les données écrites peuvent ne pas être distribuées vers le nœud de shard qui possède les mêmes tags que les plages de chunks.

• Problèmes que la fragmentation par plage et par hachage ne peuvent pas résoudre

  • La plage de valeurs de la clé de fragmentation est trop restreinte. Par exemple, si vous utilisez un centre de données comme clé de fragmentation, la fragmentation n'est pas efficace car il y a généralement peu de centres de données.

  • Une valeur spécifique de la clé de fragmentation est présente dans trop de documents. Cela peut entraîner la formation d'un chunk unique surdimensionné, appelé jumbo chunk, qui affecte la migration des chunks et l'équilibrage de la charge.

  • Les requêtes et les mises à jour basées sur un champ autre que la clé de fragmentation deviennent des requêtes de type scatter-gather, qui sont inefficaces.

• Caractéristiques d'une bonne clé de fragmentation

  • Cardinalité suffisante

  • Écritures réparties uniformément

  • Évitez les requêtes de type scatter-gather (lectures ciblées).

Exemple :

Une application IoT utilise une instance de cluster fragmenté pour stocker les journaux de millions d'appareils. Chaque appareil envoie des journaux à l'instance de cluster fragmenté toutes les 10 secondes. Les journaux contiennent des informations telles que les identifiants des appareils et les horodatages. Les journaux générés pour un appareil spécifique sur une période donnée font souvent l'objet de requêtes.

Requête : recherche des journaux d'un appareil spécifique dans une plage horaire définie.

• (Méthode recommandée) Méthode 1 : Utilisez une clé de fragmentation composite composée de l'identifiant de l'appareil et de l'horodatage avec une fragmentation par plage.

  • Les écritures sont réparties uniformément entre plusieurs shards.

  • Les données correspondant au même identifiant d'appareil sont également réparties entre plusieurs chunks en fonction de l'horodatage.

  • Les requêtes portant sur une plage horaire par identifiant d'appareil peuvent être exécutées directement à l'aide de l'index composite (deviceId, timestamp).

• Méthode 2 : Utilisez l'horodatage comme clé de fragmentation avec une fragmentation par plage.

  • Les nouvelles écritures comportent des horodatages consécutifs et sont toutes envoyées vers le même shard, ce qui entraîne une répartition inégale des écritures.

  • Les requêtes par identifiant d'appareil sont dispersées sur tous les shards, ce qui est inefficace.

• Méthode 3 : Utilisez l'horodatage comme clé de fragmentation avec une fragmentation par hachage.

  • Les écritures sont réparties uniformément entre plusieurs shards.

  • Les requêtes par identifiant d'appareil sont dispersées sur tous les shards, ce qui est inefficace.

• Méthode 4 : Utilisez l'identifiant de l'appareil comme clé de fragmentation avec une fragmentation par hachage.

  Remarque

  Si l'identifiant de l'appareil ne présente aucun motif évident, vous pouvez utiliser la fragmentation par plage.

  • Les écritures sont réparties uniformément entre plusieurs shards.

  • Les données correspondant au même identifiant d'appareil ne peuvent pas être subdivisées davantage et ne peuvent être distribuées que vers un seul chunk. Cela provoque la formation de jumbo chunks. Les requêtes par identifiant d'appareil sont envoyées vers un seul shard. Une fois la requête routée vers ce shard, une requête de plage basée sur l'horodatage nécessite une analyse complète de la table et un tri.

Jumbo chunk et taille par chunk

La taille par défaut d'un chunk dans une instance de cluster fragmenté est de 64 Mo. Si la taille d'un chunk dépasse 64 Mo et que le chunk ne peut pas être fractionné, il est marqué comme jumbo chunk. Par exemple, si tous les documents ont la même valeur de clé de fragmentation, ces documents sont stockés dans le même chunk, qui ne peut pas être fractionné. L'équilibreur de charge ne peut pas migrer les jumbo chunks, ce qui peut provoquer un déséquilibre de la charge. Nous vous recommandons d'éviter la formation de jumbo chunks.

À propos de l'équilibrage de la charge

Un thread d'arrière-plan exécuté sur les nœuds mongos de l'instance met en œuvre l'équilibrage automatique de la charge dans un cluster fragmenté. Une seule tâche de migration peut être exécutée pour chaque collection à un instant donné. L'équilibrage de la charge est déclenché en fonction du nombre de chunks par collection sur chaque nœud de shard. Si la différence entre le nombre de chunks d'une collection sur un nœud de shard et le nombre total de chunks de la collection atteint le seuil spécifié, ApsaraDB for MongoDB commence à migrer les chunks de la collection depuis le nœud de shard vers d'autres nœuds de shard. Spécifiez un seuil en fonction du nombre total de chunks.

use config
                db.settings.update(
                { _id: "balancer" },
                { $set: { activeWindow : { start : "02:00", stop : "06:00" } } },
                { upsert: true }
                )
            

sh.stopBalancer()            

Paramètre d'archivage dans la commande moveChunk

Si une instance de cluster fragmenté exécute MongoDB 3.0 ou une version antérieure, l'utilisation de l'espace disque dans le catalogue de données peut continuer à augmenter même après l'arrêt des écritures de données.

Ce problème est causé par l'élément de configuration sharding.archiveMovedChunks dont la valeur par défaut est true dans MongoDB 3.0 et les versions antérieures. Ce paramètre signifie que lors d'une opération moveChunk, le shard source archive les données du chunk migré à des fins de récupération. Par conséquent, lorsqu'un chunk est migré, l'espace disque sur le nœud source n'est pas libéré, tandis que le nœud de destination utilise un nouvel espace disque.