Successfully reported this slideshow.
Scalabilité 
MongoDB Days, Paris, 2014 
Alain Hélaïli – alain.helail@mongodb.com AlainHelaili
Vitesse
Volume
Scalabilité de MongoDB 
• Cluster shardé de plus de 250 serveurs 
• Plus de 300 000 opérations par seconde, 200 
serveurs,...
5 
Performance 
vs. 
Relational MongoDB 
Better Data Locality In-Memory Caching In-Place Updates
Facteurs de succès 
Stockage : vitesse des accès disque, IOPS 
RAM : capacité suffisante pour données actives et index 
Re...
Outils 
MongoDB Management Services (MMS) 
mongoperf : Test la capacité du disque 
mongostat : Activité des mongod 
mongot...
mtoolsmlogvis
mongoperf
Sharding
Données de travail trop volumineuses
Débit I/O insuffisant
Modèle de scalabilité 
Vertical Horizontal
Shard 
• Un shard est un noeud du cluster 
• Il peut être un simple mongod ou un replica set
Stockage des métadonnées du cluster 
• Config Server 
– Stocke les définitions des intervalles (chunks) 
et leur localisat...
Routing and Managing Data 
• mongos 
– Agit comme routeur et équilibreur de charge 
– Aucune donnée stockée, processus lig...
Sharding infrastructure 
Config 
Config 
Config
Partionnement 
de la donnée
Partionnement de la donnée 
Activation du sharding sur la db 
L’utilisateur définit une clé de sharding (fonctionnelle ou ...
Chunk initial
Découpage (split) des Chunks 
Un chunk est scindé lorsqu’il atteint la taille maximum 
(64 Mo par défaut) 
On ne peut déco...
Déplacement des Chuncks 
Initialement 1 seul chunk 
Les chunks sont scindés automatiquement lorsqu’ils 
atteignent la tail...
Déplacement des Chuncks 
Le balancer d’un des mongos s’approprie le balancer lock 
Un seul lock  une seule migration à la...
Déplacement des Chuncks 
mongos envoie une commande moveChunk à la source 
Le shard source notifie le shard de destination...
Déplacement des Chuncks 
Une fois les documents copiés 
- Processus de synchronisation pour vérifier la transmission 
-Mis...
Déplacement des Chuncks 
Le shard source supprime les données déplacées 
– Tous les curseurs ouverts doivent être fermés o...
Routage des 
requêtes
Routage des requêtes : Targeted Query 
• Des éléments de la clé de sharding 
sont présents dans la requêtes 
• Le mongos p...
Routage des requêtes : Scatter/Gather 
• Le mongos ne peut pas sélectionner 
un sous ensemble de shard 
• La requête est e...
Choix de clé de sharding 
• La clé de sharding est immutable 
• Les valeurs de la clé sont immutables 
• La clé de shardin...
Choix de clé de sharding 
• Cardinalité 
• Distribution des écritures 
• Isolation des requêtes 
• Performance des tris
Shard Key Hash 
• Pros: 
– Très bonne distribution des écritures 
• Cons: 
– Mise à jour des données et maintenance des in...
Shard Key à faible cardinalité 
• Peut introduire l’effet « jumbo chunks » 
• Equilibre de la charge incertain 
• Exemple ...
Shard Key Monotonique 
• Clé toujours croissante ou toujours décroissante 
• Introduit des "hot spots" à l’insertion 
• Vi...
Optimisations
Pre Splitting 
• Permet de prédéfinir le partitionnement de la 
collection : évite scissions et déplacements 
• Cas d’inge...
Tag-aware sharding 
• Découpagemacroscopique du cluster 
• Splits et Move ont toujours lieu, en respectant les 
contrainte...
Read Global/Write Local 
Primary:NYC 
Primary:LON 
Secondary:NYC 
Primary:SYD 
Secondary:LON 
Secondary:NYC 
Secondary:SYD...
Pilotage du balancer 
Pilotage manuel Arrêt pendant les imports de 
masse 
sh.startBalancer() / sh.stopBalancer() 
Schedu...
Conclusion
Conclusion 
#1 – Modélisation 
#2 – Index 
#3 – IOPS et RAM 
#4 – Sharding… avec la bonne clé 
#5 – Monitoring 
#6 –Amélio...
Scalabilité de MongoDB
Prochain SlideShare
Chargement dans…5
×

Scalabilité de MongoDB

1 914 vues

Publié le

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Scalabilité de MongoDB

  1. 1. Scalabilité MongoDB Days, Paris, 2014 Alain Hélaïli – alain.helail@mongodb.com AlainHelaili
  2. 2. Vitesse
  3. 3. Volume
  4. 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. 5 Performance vs. Relational MongoDB Better Data Locality In-Memory Caching In-Place Updates
  6. 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. 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. 8. mtoolsmlogvis
  9. 9. mongoperf
  10. 10. Sharding
  11. 11. Données de travail trop volumineuses
  12. 12. Débit I/O insuffisant
  13. 13. Modèle de scalabilité Vertical Horizontal
  14. 14. Shard • Un shard est un noeud du cluster • Il peut être un simple mongod ou un replica set
  15. 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. 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. 17. Sharding infrastructure Config Config Config
  18. 18. Partionnement de la donnée
  19. 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. 20. Chunk initial
  21. 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. 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. 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. 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. 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. 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. 27. Routage des requêtes
  28. 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. 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. 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. 31. Choix de clé de sharding • Cardinalité • Distribution des écritures • Isolation des requêtes • Performance des tris
  32. 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. 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. 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. 35. Optimisations
  36. 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. 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. 38. Read Global/Write Local Primary:NYC Primary:LON Secondary:NYC Primary:SYD Secondary:LON Secondary:NYC Secondary:SYD Secondary:LON Secondary:SYD
  39. 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. 40. Conclusion
  41. 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

×