Dimensionnement des clusters Public Cloud Databases pour MongoDB

Objectif

Pour bien démarrer avec MongoDB sur OVHcloud, cette page vous explique comment déterminer le dimensionnement initial d'un déploiement MongoDB, en fonction du choix entre un abonnement Advanced ou Production sur un réseau public ou privé. Après le déploiement du cluster, nous vous donnerons des recommandations pour vous connecter avec Compass, puis pour augmenter et diminuer la capacité d'un cluster OVHcloud.

Dimensionnement d'un cluster MongoDB

Pour dimensionner correctement un cluster MongoDB, quatre éléments clés doivent être pris en compte :

1. RAM - L'élément le plus important pour un cluster MongoDB.
2. CPU - Important pour de nombreuses parties des charges de travail MongoDB.
3. Stockage et IOPS - Minimisez les accès disque, mais assurez-vous que la couche de stockage est rapide et présente une faible latence.
4. Réseau - MongoDB est une base de données distribuée.

Le dimensionnement d'un cluster MongoDB est étroitement lié à la conception d'un schéma MongoDB. Évaluer le modèle de schéma et comprendre les schémas d'accès aux données est essentiel. Pour dimensionner efficacement un cluster, deux opérations préliminaires doivent être réalisées :

1. Qualifier :

• Définir les objets du domaine
• Définir vos requêtes
• Connaître vos index
• Déterminer votre schéma d'accès
• Choisir une clé de shard en cas de sharding

2. Quantifier :

• Estimer le nombre de documents après 1 mois, 6 mois et un an
• Identifier les données les plus fréquemment lues (par exemple, les données du dernier mois)

Déterminer la taille de la RAM

Déterminer la taille totale des index

Pour déterminer la quantité de RAM avec laquelle un cluster doit être provisionné, il est nécessaire de déterminer la taille totale des index et la taille du working set. Utilisez une fonction personnalisée dans le shell MongoDB (mongosh) ou db.collection.totalIndexSize() à cette fin.

  indexSize = function () {
    var total = 0,
      dbnames = function () {
        var r = db.adminCommand({
          listDatabases: 1
        });
        if (!r || r.databases === undefined) {
          return [];
        };
        return r.databases.map(n => n.name).filter(name => name !== "admin" && name !== "config" && name !== "local");
      };
    var div = 1024 * 1024;
    dbl = dbnames();
    for (var i = 0; i < dbl.length; i++) {
      var s = db.getSiblingDB(dbl[i]).stats();
      if (!s) continue;
      total += Number(s.indexSize ? s.indexSize : 0);
    }
    return Math.round(total / div) + ' MB';
  }

  indexSize()

Estimer la taille des index

• Les index en mémoire peuvent utiliser la compression par préfixe.
• Pour les pages en mémoire, WiredTiger stocke le préfixe commun une seule fois.
• Contrairement à la compression du stockage/des blocs, cela ne consomme pas de cycles CPU.
• L'ordre des index composés peut avoir un impact sur la taille de l'index sur le disque.

Exemple de compression par préfixe

La formule

2 * ( nombre de documents * (taille moyenne du champ * facteur de compression) )

Exemple

Pour un champ de type chaîne de caractères d'une taille moyenne de 12 octets, si nous indexons une collection de 100 000 documents sur un champ de date, la formule sera la suivante (si nous décidons de ne pas tenir compte du facteur de compression, la valeur étant très variable) :

(2*(100000*12))/1024/1024 = 2.40MB

Avec un facteur de compression heuristique :

(2*(100000*(12*0.95)))/1024/1024 = 2.28MB

Pour les index composés, la formule est identique, il suffit d'additionner toutes les tailles moyennes de champs. Mais nous nous arrêtons ici, car les autres types d'index sont bien plus difficiles à dimensionner.

Remarque sur les types d'index

• MongoDB peut indexer le texte intégral, les champs multikey (champs de type tableau) et les wildcard.
• Ces types d'index occupent plus d'espace et sont plus difficiles à calculer.
• Créer une base de données factice avec des données similaires aide à l'estimation.

Déterminer la taille du working set

Le working set correspond aux données les plus fréquemment utilisées que MongoDB tend à conserver en mémoire. Calculer cette valeur est complexe et peut reposer sur des hypothèses et des statistiques. Réservez de l'espace dans le cache WiredTiger pour permettre à MongoDB de travailler en mémoire avec les données fréquemment consultées.

Formule

WS = ((FDD / TDSD) * S%) * TDS

Explication de la formule

Exemple

Pour 30 jours de données fréquemment utilisées sur une année, avec 30 % des requêtes portant sur les données fréquemment utilisées, et un jeu de données de 100 Go :

WS = ((30 / 365) * 30%) * 100000 (MB) = ~2500 MB

Déterminer la quantité de RAM

Le moteur de stockage de MongoDB, WiredTiger, gère son propre cache, dans lequel résident les index et les documents lus le plus récemment, parmi un certain nombre d'autres éléments. La taille du cache correspond par défaut à environ 50 % de la RAM totale de la machine hôte. Il est possible de personnaliser la taille du cache pour un déploiement sur site. Cependant, cela n'est pas recommandé.

Si nous provisionnons 32 Go de RAM par nœud, nous pouvons alors supposer que WiredTiger disposera d'environ 16 Go pour son propre cache. WiredTiger vise à maintenir le cache rempli à 80 %. Au-delà de cette limite, il commencera à évincer des blocs. Par conséquent, seulement ~40 % de la mémoire disponible sur le système hôte sera utilisée pour les documents en cache et, surtout, pour les index.

La formule est ensuite inversée par les 250 % pour obtenir la valeur totale de RAM correcte.

Mémoire totale du cluster (TCM) = (TIS + WS) * 250% + 1000 (MB)

• Taille totale des index (TIS) en Mo
• Taille du working set (WS) en Mo

Déterminer la taille du stockage

L'estimation de la taille du stockage est assez simple. Utilisez votre jeu de données de test comme référence et observez la taille de stockage indiquée par vos db-stats. Une formule utilisable est la suivante :

Taille totale du stockage (TSS) = (TDSS / TSDC) * TADC / B%

• Taille de stockage des données de test (TDSS)
• Nombre de documents des données de test (TSDC)
• Nombre de documents cible (TADC)
• Pourcentage de marge (B%) = généralement 70 %

Exemple : Si j'ai 10 millions de documents dans mon jeu de données de test et que la taille totale de stockage de ce jeu de données est de 10 Go, et que le système cible doit stocker 1 milliard de documents, alors il faudra environ 1,4 To d'espace disque.

TSS = (10 GB / 10,000,000) * 1,000,000,000 / 70% = ~1.4 TB

Déterminer le CPU

Malheureusement, le CPU est un peu plus difficile à estimer, car cela dépend fortement du cas d'usage et du nombre de cœurs des CPU eux-mêmes.

Cependant, suivre le ratio d'1 CPU pour 4 Go de RAM pour les clusters MongoDB offre généralement les meilleures performances pour la grande majorité des cas d'usage applicables. Si l'application utilisant la base de données MongoDB ne sollicite pas beaucoup le CPU (pas de framework de pipeline d'agrégation, index couvrant parfaitement la majorité des requêtes), il est alors possible de réduire le ratio de 1/4 à 1/8. Par exemple, une charge de travail effectuant plus d'écritures que de lectures peut fonctionner normalement avec une utilisation CPU plus faible. Le rapport CPU est étroitement lié au moteur de stockage WiredTiger et à la quantité de cache qu'il gère. Pour traiter correctement le cache, ce ratio doit être respecté.

CPU total du cluster (TCC) = TCM / 4

Ainsi, dans un exemple où la quantité totale de mémoire nécessaire est de 10 Go, cela donnera un résultat de 2,5 CPU pour permettre à MongoDB de fonctionner correctement. Une taille de 16 Go de RAM produira 4 CPU.

Déterminer les IOPS de stockage

L'aspect le plus complexe consiste à déterminer le nombre d'IOPS utilisés par la couche de stockage en fonction de la charge de travail MongoDB. La seule façon de le savoir avec précision est, d'abord, de connaître la capacité de votre disque en termes d'IOPS, puis d'effectuer des tests de performance sur votre cas d'usage. Cela révélera la quantité d'IOPS consommée par MongoDB. Gardez à l'esprit que chaque mise à jour d'un seul champ d'un document entraînera une réécriture complète du document à chaque fois que le moteur de stockage décide de le persister sur le disque.

Règle empirique

• Comptez une IO par écriture de 4 Ko (compressée) par unité de temps.
• À des niveaux d'écriture élevés (plusieurs K/s), les IO seront fusionnées (un document de plus de 8 Ko utilisera 2 IO).
• Il est difficile d'estimer le facteur de fusion : lorsque les demandes d'IO commencent à s'accumuler, il n'est pas rare d'observer un facteur de 5 à 10 (voire plus).
• En cas de doute, modélisez la charge de travail, testez-la et collectez des métriques.
• Prévoyez suffisamment d'IO/de débit disque pour pouvoir écrire 60 secondes de données sur le disque en quelques secondes.
• Les checkpoints sont des opérations sensibles, se produisant normalement toutes les 60 secondes, et vous voulez qu'ils s'exécutent en peu de temps.

Si vous écrivez des documents de petite taille, inférieurs à 4 Ko, il existe un risque de gaspillage d'IOPS.

L'article de blog suivant décrit comment utiliser des design patterns pour améliorer la qualité des données. Le bucket pattern, parmi d'autres patterns utiles, y est expliqué : Building with Patterns: A Summary.

Considérations réseau pour MongoDB

• Visez une latence inférieure à 1 milliseconde entre les nœuds MongoDB d'un replica set.
• Visez la bande passante la plus élevée possible entre l'application et la base de données.

En tant que base de données distribuée, MongoDB s'appuie sur un transport réseau efficace lors du routage des requêtes et de la réplication entre nœuds. Basé sur l'algorithme de compression snappy, le trafic réseau à travers un cluster MongoDB peut être compressé jusqu'à 80 %, offrant des gains de performance majeurs dans les environnements à bande passante limitée et réduisant les coûts réseau.

Vous pouvez ajouter le paramètre compressors à la chaîne de connexion pour activer la compression :

mongodb://localhost/?compressors=snappy

Créer votre cluster de base de données MongoDB

Vous pouvez vous référer à la documentation Getting Started pour créer votre cluster MongoDB en fonction du résultat du dimensionnement.

Réseaux privés et publics pour une base de données MongoDB managée

Lors du déploiement d'une base de données MongoDB managée, une décision essentielle consiste à choisir entre une configuration en réseau privé ou public. Chaque option présente ses propres avantages et points d'attention. Comprendre ces différences peut vous aider à prendre une décision éclairée, la mieux adaptée aux besoins de votre application.

Augmenter la capacité d'un cluster MongoDB

L'augmentation de la capacité d'un cluster MongoDB en ajoutant davantage de CPU, de RAM et de ressources d'I/O garantit des performances optimales à mesure que les charges de travail augmentent. Une puissance CPU accrue améliore les capacités de traitement des requêtes, tandis qu'une RAM plus importante permet de mettre en cache davantage de données en mémoire, accélérant ainsi les opérations de lecture. Une capacité d'I/O renforcée améliore les vitesses de lecture/écriture des données, essentielles pour les applications à fort débit. Globalement, l'augmentation de capacité maintient la réactivité et la fiabilité de la base de données, tout en accompagnant l'évolution des besoins métier.

Réduire la capacité d'un cluster MongoDB

La réduction de la capacité d'un cluster MongoDB permet de réduire les coûts, de simplifier la gestion et d'améliorer l'efficacité pour les charges de travail nécessitant moins de ressources, tout en minimisant la charge de maintenance.

Se connecter à une base de données MongoDB avec MongoDB Compass

Vous pouvez vous référer à la documentation Se connecter avec MongoDB Compass pour vous connecter à votre service Public Cloud Databases pour MongoDB à l'aide de MongoDB Compass.

Aller plus loin

MongoDB - Bonnes pratiques pour les développeurs

Nous voulons vos retours !

Nous serions ravis de répondre à vos questions et apprécions tout retour que vous pourriez nous faire.

Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

Rejoignez notre communauté d'utilisateurs.

Vous êtes sur Discord ? Rejoignez notre chaîne via https://discord.gg/ovhcloud et interagissez directement avec l’équipe qui développe notre service de bases de données !