Scalabilité de MongoDB

1 420 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 420
Sur SlideShare
0
Issues des intégrations
0
Intégrations
394
Actions
Partages
0
Téléchargements
46
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

×