> Conseils d'optimisation > Montée en charge verticale > Montée en charge horizontale > Procéder à la montée en charge d'une équipe opérationnelle

2. Réussir une montée en charge avec
MongoDB
Thomas Boyd
Directeur de l'équipe d'architecture de solutions chez
MongoDB

3. Montée en charge avec MongoDB
0
5,000
10,000
15,000
20,000
25,000
30,000
1 2 3 4 5 6 7 8
Opérations/seconde
Nombre de nœuds
Débit du cluster MongoDB

4. Sommaire
• Conseils d'optimisation
– Conception de schéma
– Index
– Surveillance
– WiredTiger
• Montée en charge verticale
• Montée en charge horizontale
• Procéder à la montée en charge d'une équipe
opérationnelle

5. Conseils d'optimisation : Conception
de schéma

6. Modèle de document
• Correspondance
d'objets d'application
• Flexibilité
• Performances élevées
{ "customer_id" : 123,
"first_name" : ”John",
"last_name" : "Smith",
"address" : {
"street": "123 Main Street",
"city": "Houston",
"state": "TX",
"zip_code": "77027"
}
policies: [ {
policy_number : 13,
description: “short term”,
deductible: 500
},
{ policy_number : 14,
description: “dental”,
visits: […]
} ]
}

7. Importance de la conception de schémas
• Très différente de la conception de schémas
RDBMS
• Schéma MongoDB :
– dénormaliser les données
– créer un schéma (potentiellement complexe)
en ayant une connaissance préalable (et non
une simple prévision) de vos modèles de
requête réels
– écrire des requêtes simples

8. Exemple concret
Catalogue de produits pour un détaillant en activité dans
20 pays
{
_id: 375,
en_US: { name: …, description: …, <etc…> },
en_GB: { name: …, description: …, <etc…> },
fr_FR: { name: …, description: …, <etc…> },
fr_CA: { name: …, description: …, <etc…> },
de_DE: …,
<… and so on for other locales …>
}

9. Correspondance incorrecte pour un modèle
d'accès
Requêtes d'application réelles :
db.catalog.find( { _id: 375 }, { en_US: true } );
db.catalog.find( { _id: 375 }, { fr_FR: true } );
db.catalog.find( { _id: 375 }, { de_DE: true } );
… et ainsi de suite pour les autres
paramètres régionaux

10. Utilisation insuffisante des ressources
Les données en
ROUGE sont en cours
d'utilisation. Les
données en BLEU
occupent de la
mémoire, mais ne sont
pas sollicitées.
{
_id: 375,
en_US: { name: …, description: …, <etc…> },
en_GB: { name: …, description: …, <etc…> },
fr_FR: { name: …, description: …, <etc…> },
fr_CA: { name: …, description: …, <etc…> },
de_DE: …,
de_CH: …,
<… and so on for other locales …>
}
{
_id: 42,
en_US: { name: …, description: …, <etc…> },
en_GB: { name: …, description: …, <etc…> },
fr_FR: { name: …, description: …, <etc…> },
fr_CA: { name: …, description: …, <etc…> },
de_DE: …,
de_CH: …,
<… and so on for other locales …>
}

11. Conséquences de la nouvelle conception de
schéma
• Les requêtes ont provoqué une surcharge
de mémoire minime
• x20, car de nombreux produits consomment
simultanément de la RAM
• Réduction de l'utilisation des E/S du disque
• Réduction de la latence de l'application{
_id: "375-en_GB",
name: …,
description: …,
<… the rest of the document …>
}

12. Modèles de conception de schéma
• Modèle : quantités de pré-calcul
intéressantes, idéalement avec chaque
opération d'écriture
• Modèle : placement d'éléments non liés
dans différentes collections pour exploiter
l'indexation
• Modèle à ne pas suivre : ajouter
constamment des tableaux
• Modèle à ne pas suivre : importer des
schémas relationnels directement dans
MongoDB

13. Ressources pour la conception de schémas
• En savoir plus sur la
modélisation des données, à
14 h à l'auditorium Robertston 1
(en anglais)
• Série de billets de blog, « 6
règles empiriques » (en anglais)
– Partie 1 : http://goo.gl/TFJ3dr
– Partie 2 : http://goo.gl/qTdGhP
– Partie 3 : http://goo.gl/JFO1pI
• Webinaires, formations, conseils,
etc.

14. Conseils d'optimisation : Indexation

15. Index par arbre-B
• Références structurées en arbre vers vos
documents
• Premier facteur de performance réglable
• L'indexation et la conception de schémas
vont de pair

16. Présentation des erreurs d'indexation
courantes et des solutions pour les résoudre
• Échec du développement des index requis
– Exécutez .explain(), examinez attentivement le journal de
la requête, mtools, collection system.profile
• Développement d'index superflus
– Discutez avec les développeurs de votre application à
propos de son utilisation
• Exécution des requêtes ad hoc en environnement de
production
– Utilisez un environnement de simulation, utilisez des
membres secondaires

17. Fichiers journaux mongod
Sun Jun 29 06:35:37.646 [conn2]
query test.docs query: {
parent.company: "22794",
parent.employeeId: "83881" }
ntoreturn:1 ntoskip:0
nscanned:806381 keyUpdates:0
numYields: 5 locks(micros)
r:2145254 nreturned:0 reslen:20
1156ms

18. mtools
• http://github.com/rueckstiess/mtools
• Analyse du fichier journal pour examiner les
requêtes aux performances faibles
– Découvrir les requêtes dont la durée dépasse
1 000 ms entre 6 h et 18 h :
– mlogfilter mongodb.log --from 06:00 --to
18:00 --slow 1000 > mongodb-filtered.log

19. Stratégies d'indexation
• Créez des index pouvant prendre en charge vos requêtes.
• Créez des index hautement sélectifs
• Éliminez les index en double en utilisant des index composés
– db.collection.ensureIndex({A:1, B:1, C:1})
– permet aux requêtes d'utiliser le préfixe situé le plus à
gauche
• Organisez les colonnes d'index pour prendre en charge les
analyses et les tris
• Créez des index prenant en charge les requêtes traitées
• Empêchez les analyses de collections dans des
environnements de pré-production
db.getSiblingDB("admin").runCommand( {
setParameter: 1, notablescan: 1 } )

20. Conseils d'optimisation : Surveillance

21. FAITES-LE
IMMÉDIATEMENT
EN PRÉ-PROD/STRESS

22. MongoDB Management Services (MMS)
Sauvegarde
Surveillance
Automatisation

23. MMS : Indicateurs de base de données

24. Configuration de la surveillance MMS

25. Version Cloud de MMS
1. Rendez-vous sur
http://mms.mongodb.com
2. Créez un compte
3. Installez un agent dans votre centre
de données
4. Ajoutez des hôtes à partir de
l'interface Web
5. Et voilà !

26. Moteur de stockage WiredTiger

27. Performances multipliées de 7 à 10 fois,
économie de 50 à 80 % sur l'espace de stockage
Présentation du moteur de
stockage WiredTiger
• Modèle de données, langage de
requête, opérations identiques
• Amélioration des performances
d'écriture en raison du contrôle
des accès simultanés au niveau
du document
• Économies de stockage en raison
d'une compression native
• Rétrocompatible à 100%
• Mise à niveau sans temps d'arrêt
MongoDB 3.0MongoDB 2.6
Performances

28. Montée en charge verticale

29. Facteurs :
– RAM
– Disque
– CPU
– Réseau
Nous sommes ici pour vous soutenir
Primaire
Secondaire
Secondaire
Jeu de réplicas Primaire
Secondaire
Secondaire
Jeu de réplicas

30. Le jeu de travail dépasse la mémoire
physique

31. Exemple concret
• Modifications d'état pour des entités de
l'entreprise
• Modifications d'état dans des lots
– parfois, 10 % des entités sont mises à
jour
– parfois, 100 % sont mises à jour

32. Architecture initiale
Cluster partitionné, 4 partitions soutenues par un
disque rotatif
Application / mongos
mongod

33. Montée en charge horizontale
L'évolution rapide d'une entreprise entraîne
des partitionnements supplémentaires
Application / mongos
…16 partitionnements supplémentaires…
mongod

34. Montée en charge verticale
Montée en charge des E/S par seconde avec des
disques SSD
Application / mongos
mongod SSD

35. Avant d'ajouter du matériel...
• Vérifiez que vous résolvez le bon problème de montée en
charge
• Résolvez d'abord les problèmes touchant le schéma et l'index
– les problèmes de schéma et d'index peuvent ressembler à
des problèmes de matériel
• Réglez le système d'exploitation
– Planificateur ulimits, swap, NUMA, NOOP avec hyperviseurs
• Réglez le sous-système d'E/S
– ext4 ou XFS par rapport à SAN, RAID10, readahead, noatime
• Consultez la page « Notes de production » de MongoDB
• Tenez compte des avertissements au démarrage du fichier
journal

36. Montée en charge horizontale

37. Présentation du partitionnement
Primaire
Secondaire
Secondaire
Partition 1
Primaire
Secondaire
Secondaire
Partition 2
Primaire
Secondaire
Secondaire
Partition 3
Primaire
Secondaire
Secondaire
Partition N
…
Routeur de
requête
Routeur de
requête
Routeur de
requête
……
Pilote
Application

38. Partitionnement par plage
mongod
Scalabilité de lecture/écriture
Plage de clés
0...100

39. Partitionnement par plage
Scalabilité de lecture/écriture
mongod mongod
Plage de clés
0...50
Plage de clés
51...100

40. Partitionnement
mongod mongod mongod mongod
Plage de clés
0...25
Plage de clés
26...50
Plage de clés
51...75
Plage de clés
76... 100
Scalabilité de lecture/écriture

41. Caractéristiques d'une clé de partition
• Une clé de partition adéquate a :
– une cardinalité suffisante
– des écritures distribuées
– des lectures ciblées (« isolement des requêtes »)
• Si possible, la clé de partition doit être dans chaque
requête
– sinon, procédez par ventilation/regroupement
• Il est important de choisir une clé de partition
adéquate.
– Elle a une incidence sur les performances et la
scalabilité.
– Le fait de la changer ultérieurement s'avère
coûteux.

42. Attention aux clés de partition ascendantes
• L'augmentation régulière des valeurs d'une clé de
partition peut entraîner des « points sensibles »
lors des insertions
• Exemples : horodatages, _id
Partition
1
mongos
Partition
2
Partition
3
Partition
N
[ ISODate(…), $maxKey )

43. Procéder à la montée en charge d'une
équipe opérationnelle

44. MongoDB Management Service (MMS)
Montée en
charge simplifiée
Respect des
accords sur les
niveaux de
service (ANS)
Automatisation
de vos meilleures
pratiques
Réduction des
frais de gestion

45. Sans MMS
Exemple de déploiement : 12 serveurs
Installation et configuration
Plus de 150 étapes
…Gestion des erreurs, limitation, alertes
Montée en charge, déplacement des serveurs,
redimensionnement du journal des opérations
(oplog), etc.
De 10 à plus de 180 étapes
Mises à niveau vers une version supérieure ou
antérieure
Plus de 100 étapes

46. Avec MMS

47. Les tâches courantes sont effectuées en
quelques minutes
• Déploiement : n'importe quelle taille, pour la plupart des
topologies
• Mise à niveau vers une version supérieure/antérieure :
sans temps d'arrêt
• Montée en charge : ajout/suppression de partitions ou de
réplicas sans temps d'arrêt
• Redimensionnement du journal des opérations (Oplog) :
sans temps d'arrêt
• Spécification des utilisateurs, des rôles et des rôles
personnalisés
• Provisionnement d'instances AWS et optimisation pour
MongoDB

48. MongoDB à l'échelle
250 M de
fluctuations/seco
nde
Plus
de 300 000 opér
ations/seconde
Plus
de 500 000 opér
ations/seconde
Agence fédérale
Performances
1 400 serveurs
Plus de
1 000 serveurs
Plus de
250 serveurs
Entreprise de
loisirs
Cluster
Pétaoctets
Dizaines de milliards
d'objets
13 milliards de
documents
Données
Société Internet
asiatique