1. Scalabilité
MongoDB Days, Paris, 2014
Alain Hélaïli – alain.helail@mongodb.com AlainHelaili

2. Vitesse

3. Volume

4. Scalabilité de MongoDB
• Cluster shardé de plus de 250 serveurs
• Plus de 300 000 opérations par seconde, 200
serveurs, 5.5 milliards de documents
• 12 shards, 108 serveurs, 10 TB de données,
12 milliards de documents, croissance de
1.5M docs par an
• 100 applications déployées sur plus de 1 000
noeuds, 20 milliards d’opérations par jour

5. 5
Performance
vs.
Relational MongoDB
Better Data Locality In-Memory Caching In-Place Updates

6. Facteurs de succès
Stockage : vitesse des accès disque, IOPS
RAM : capacité suffisante pour données actives et index
Requêtes : utilisation efficace d’index et projections
Remove : opération la plus coûteuse
Update : attention aux déplacements
Real-time ou bulk
Index : Ni trop, ni trop peu
Sharding : stratégie et clé de sharding
Ressources : ne partez pas seuls !

7. Outils
MongoDB Management Services (MMS)
mongoperf : Test la capacité du disque
mongostat : Activité des mongod
mongotop : Activité des collections
Profiler : db.setProfilingLevel(0|1|2, slowms=100ms)
Explain : db.scores.find({student:0}).explain()
mTools : https://github.com/rueckstiess/mtools
- mlogfilter, mloginfo, mplotqueries, mlogvis …

8. mtoolsmlogvis

9. mongoperf

10. Sharding

11. Données de travail trop volumineuses

12. Débit I/O insuffisant

13. Modèle de scalabilité
Vertical Horizontal

14. Shard
• Un shard est un noeud du cluster
• Il peut être un simple mongod ou un replica set

15. Stockage des métadonnées du cluster
• Config Server
– Stocke les définitions des intervalles (chunks)
et leur localisation
– 1 config server en dév, 3 en production
– Ce n’est pas un replica set

16. Routing and Managing Data
• mongos
– Agit comme routeur et équilibreur de charge
– Aucune donnée stockée, processus light
– On peut en avoir un ou plusieurs
– Localisé avec l’application ou sur serveur dédié

17. Sharding infrastructure
Config
Config
Config

18. Partionnement
de la donnée

19. Partionnement de la donnée
Activation du sharding sur la db
L’utilisateur définit une clé de sharding (fonctionnelle ou
hash) par collection
La clé de sharding définit un ensemble ordonné de
données
Chaque valeur de clé appartient à un intervalle
Les intervalles sont scindés et déplacés au fil du temps

20. Chunk initial

21. Découpage (split) des Chunks
Un chunk est scindé lorsqu’il atteint la taille maximum
(64 Mo par défaut)
On ne peut découper qu’entre 2 valeurs distinctes
Un split n’entraine pas forcément de déplacement

22. Déplacement des Chuncks
Initialement 1 seul chunk
Les chunks sont scindés automatiquement lorsqu’ils
atteignent la taille limite (64 Mo par défaut)
Les chuncks sont déplacés automatiquement
Nombre de Chunks Seuil de migration
< 20 chuncks 2
20 à 79 chuncks 4
> 80 chuncks 8

23. Déplacement des Chuncks
Le balancer d’un des mongos s’approprie le balancer lock
Un seul lock  une seule migration à la fois
Status du lock:
use config
db.locks.find({ _id: “balancer” })

24. Déplacement des Chuncks
mongos envoie une commande moveChunk à la source
Le shard source notifie le shard de destination
Le shard de destination construit les index nécessaires
Le shard de destination récupère les documents depuis la source
Les documents reste accessibles en R/W sur la source

25. Déplacement des Chuncks
Une fois les documents copiés
- Processus de synchronisation pour vérifier la transmission
-Mise à jour des config servers

26. Déplacement des Chuncks
Le shard source supprime les données déplacées
– Tous les curseurs ouverts doivent être fermés ou en timeout
– Curseurs avec NoTimeout empêche la libération du lock
Le mongos libère le lock

27. Routage des
requêtes

28. Routage des requêtes : Targeted Query
• Des éléments de la clé de sharding
sont présents dans la requêtes
• Le mongos peut cibler un sous
ensemble de shard
• Une partie des shards n’est pas
sollicité

29. Routage des requêtes : Scatter/Gather
• Le mongos ne peut pas sélectionner
un sous ensemble de shard
• La requête est envoyée à l’ensemble
des shards
• La fusion des résultats et le tri final
sont effectués sur le shard primaire
de la base de données
• Aggrégation : pipeline est découpé
en 2 à partir du premier $group ou
$sort

30. Choix de clé de sharding
• La clé de sharding est immutable
• Les valeurs de la clé sont immutables
• La clé de sharding doit être indexée
• Taille limitée à 512 octets
• Clé de sharding requise pour insertions
• Clé de sharding utilisée pour le routage des
requête : critique pour la peformance

31. Choix de clé de sharding
• Cardinalité
• Distribution des écritures
• Isolation des requêtes
• Performance des tris

32. Shard Key Hash
• Pros:
– Très bonne distribution des écritures
• Cons:
– Mise à jour des données et maintenance des index coûteuses
– Requêtes sur des intervalles et tris  scatter gather
Shard 1
mongos
Shard 2 Shard 3 Shard N

33. Shard Key à faible cardinalité
• Peut introduire l’effet « jumbo chunks »
• Equilibre de la charge incertain
• Exemple : booléen, année de naissance…
Shard 1
mongos
Shard 2 Shard 3 Shard N
[ a, b[ [ c, d[

34. Shard Key Monotonique
• Clé toujours croissante ou toujours décroissante
• Introduit des "hot spots" à l’insertion
• Vitesse d’insertion non liée au nombre de shards
• Examples: timestamps, _id
Shard 1
mongos
[ ISODate(…),
$maxKey )
Shard 2 Shard 3 Shard N

35. Optimisations

36. Pre Splitting
• Permet de prédéfinir le partitionnement de la
collection : évite scissions et déplacements
• Cas d’ingestionmassive de données
• Lorsque la collection est vide uniquement
for ( var x=97; x<97+26; x++ ) { //a, b, c, d….
for( var y=97; y<97+26; y+=6 ) { //a, g, m, s, y
var prefix = String.fromCharCode(x)+String.fromCharCode(y);
//prefix = aa, ag, am, as, ay, ba, bg…
db.runCommand( { split : "myapp.users" , middle : { email : prefix } } );
}
}

37. Tag-aware sharding
• Découpagemacroscopique du cluster
• Splits et Move ont toujours lieu, en respectant les
contraintes
• Un tag définit un intervalle
• Recouvre plusieurs chunks
• Recouvre plusieurs shards
sh.addShardTag("shard0000", "NYC")
sh.addShardTag("shard0001", "NYC")
sh.addShardTag("shard0002", "NYC")
sh.addShardTag("shard0003", "SFO")
sh.addTagRange("records.users", { zipcode: "10001" }, { zipcode: "10281" }, "NYC")
sh.addTagRange("records.users", { zipcode: "11201" }, { zipcode: "11240" }, "NYC")
sh.addTagRange("records.users", { zipcode: "94102" }, { zipcode: "94135" }, "SFO")

38. Read Global/Write Local
Primary:NYC
Primary:LON
Secondary:NYC
Primary:SYD
Secondary:LON
Secondary:NYC
Secondary:SYD
Secondary:LON
Secondary:SYD

39. Pilotage du balancer
Pilotage manuel Arrêt pendant les imports de
masse
sh.startBalancer() / sh.stopBalancer()
Scheduling  Fonctionnement pendant les
périodes calmes
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start :
"23:00", stop : "6:00" } } }, true )

40. Conclusion

41. Conclusion
#1 – Modélisation
#2 – Index
#3 – IOPS et RAM
#4 – Sharding… avec la bonne clé
#5 – Monitoring
#6 –Améliorations 2.8
#7 – Nous pouvons vous aider