Le document présente MongoDB, une base de données NoSQL orientée documents, en détaillant son modèle de données, ses concepts clés comme le journaling, le replicaset et le sharding, ainsi que des exemples d'application. Il fournit également un retour d'expérience sur l'intégration de MongoDB avec Spring et les bénéfices en matière de performance et de disponibilité. Enfin, des conclusions soulignent l'efficacité de la solution mise en place et les améliorations notables en termes de temps de traitement.

1. { name : ‘MongoDB’, type : ‘NoSQL’ }
{
speakers : [‘Oussama MAHJOUB, ‘Oussama ZOGHLAMI ],
date : ‘16/12/2014’
}

2. SOMMAIRE
❖ Partie 1
● MongoDB
● Data Modeling
● Concepts Clés
❖ Partie 2
● Retour d’expérience

3. MONGODB : CONTEXTE
{ number : 1 }

4. MONGODB : DÉFINITION
MongoDB est une base de données :
{ number : 2 }
● Open source
● Non relationnelle
● Orientée documents
● Répartie

5. JSON Style :
{
_id : "10001",
loc : [-73.99670500000001,40.74838],
pop : 18913,
state : "NY",
city : {
name : "NEW YORK",
description : “Cool description goes here !”
}
}
MONGODB : DATA MODELING : DOCUMENT
{ number : 3 }
Unique Document ID
Key
Value
Sub Document

6. MONGODB : DATA MODELING : COLLECTION
Scheamaless
{ number : 4 }

7. MONGODB : DATA MODELING : CRUD
❖ Count :
collection.count( query )
❖ Find:
collection.find( query , fields )
❖ Insert :
collection.insert( document )
❖ Update :
collection.update( query, update, upsert, multi )
❖ Delete :
collection.remove( query )
{ number : 5 }

8. MONGODB : DATA MODELING : INDEXES
{ number : 6 }
{
_id : "10001",
area : 5
pop : 18913,
state : "NY",
loc : [-73.99670500000001,40.74838],
city : {
name : "NEW YORK",
description : “Cool description goes here !”
}
}
● Single Field Index
● Compound Index
● Multikey Index
● Geospatial Index
● Text Index

9. CONCEPTS CLÉS
❖ Journaling
➢ Recouvrement après une panne
❖ ReplicaSet
➢ Réplication + Disponibilité
❖ Sharding
➢ Scaling horizonal + Load balancing
{ number : 7 }

10. CONCEPTS CLÉS : JOURNALING : PROBLÉMATIQUE
{ number : 8 }

11. CONCEPTS CLÉS : JOURNALING : PROBLÉMATIQUE
{ number : 8 }
Data
Perdue

12. CONCEPTS CLÉS : JOURNALING : SANS JOURNAL
{ number : 9 }

13. CONCEPTS CLÉS : JOURNALING : AVEC JOURNAL
{ number : 10 }

14. CONCEPTS CLÉS : JOURNALING
{ number : 11 }
Replay

15. CONCEPTS CLÉS : JOURNALING : CONCLUSION
{ number : 12 }
● Recouvrement
Automatique
● Impacte les performances
d'écriture
● Activation / Désactivation
au choix

16. CONCEPTS CLÉS : REPLICASET: PROBLÉMATIQUE
{ number : 13 }

17. CONCEPTS CLÉS : REPLICASET: PROBLÉMATIQUE
{ number : 14 }
Serveur Indisponible

18. CONCEPTS CLÉS : REPLICASET : ARCHITECTURE
{ number : 15 }

19. CONCEPTS CLÉS : REPLICASET : ELECTION
{ number : 16 }

20. CONCEPTS CLÉS : REPLICASET : MESURES
Replication Factor = Nombre de fois ou la donnée est répliquée dans le
replicaset
Fault tolerence Factor = Nombre de noeuds que je peux perdre dans le
replicaset sans impacter la réussite de l'élection
{ number : 17 }

21. CONCEPTS CLÉS : REPLICASET : EXERCICE
{ number : 18 }
Replication Factor ?
7
Les arbitres ne répliquent pas
Fault tolerence Factor ?
4
Majority = 5 ; N = 9
FTL = 9 - 5 = 4
N = 9

22. CONCEPTS CLÉS : REPLICASET : REPLICATION
{ number : 19 }
Asynchronous
Replication
oplog = log d’opérations
ReplayReplay
Comment se fait la
réplication ?

23. CONCEPTS CLÉS : REPLICASET : OPLOG
{ number : 20 }
Oplog :
● Structure de donnée circulaire
● Sa taille définit le nombre max d’opérations que les secondaires
peuvent rattraper

24. CONCEPTS CLÉS : REPLICASET : EXERCICE
{ number : 21 }
Oplog size = 120 opérations
Moyenne d'écriture = 2 opérations / minute
Durée max de l’opération de réparation
pour garantir une cohérence des
données au redémarrage du serveur
secondaire ?
60 min = 120 / 2

25. CONCEPTS CLÉS : REPLICASET : WRITE CONCERN
Niveau de garantie sur l’écriture des données :
● Unaknowledged : Aucune garantie
● Primary : Le noeud primaire a notifié l'écriture
● Majority : La majorité des noeuds ont notifié l'écriture
{ number : 22 }

26. CONCEPTS CLÉS : REPLICASET : READ PREFERENCES
Configuration pour la lecture des données :
● Primary: Toujours lire du noeud primaire
● Secondary : Autoriser la lecture d’un noeud secondaire
● Nearest : Lire du noeud le plus proche
{ number : 23 }

27. CONCEPTS CLÉS : REPLICASET : CONCLUSION
● Basculement automatique par vote ( natif )
● Redondance des données
● Haute disponibilité
{ number : 24 }

28. CONCEPTS CLÉS : SHARDING : PROBLÉMATIQUE
{ number : 25 }
CPU limit
I/O limit
Storage limit
Solution : Vertical scaling
● + CPU
● + RAM
● + Capacité Disque

29. CONCEPTS CLÉS : SHARDING : ARCHITECTURE
{ number : 26 }

30. CONCEPTS CLÉS : SHARDING : DATA DISTRIBUTION
● Collection distribution level
● Shard Key = clé de
répartition
{ number : 27 }
collection :
{ x : 1 }
{ x : 100 }
{ x : -20 }

31. CONCEPTS CLÉS : SHARDING : SHARD KEY
{ number : 28 }
Considérations sur le choix de la clé :
● Existe dans touts les documents de la collection
● Utilisée dans la majorité des requêtes
● Divisible / Haute Cardinalité
● Écriture Aléatoire

32. CONCEPTS CLÉS : SHARDING : CONCLUSION
{ number : 29 }
Une architecture en sharding garantit :
● De hautes performances
● Une haute disponibilité
● Une mise à l'échelle automatique ( natif )

33. CONCEPTS CLÉS : RÉSUMÉ
Automatic Failover Automatic
Replication
Automatic Load
Balancing
Single Instance N N N
ReplicaSet Y Y N
Sharded Cluster Y Y Y
{ number : 30 }

34. RETOUR D’EXPÉRIENCE : CONTEXTE CLIENT / L’EXISTANT
{ number : 31 }
app WS Widget
Oracle
Batch

35. RETOUR D’EXPÉRIENCE : LE DÉFI ?
Générer les rapports depuis la base de données :
{ number : 32 }
● Contrainte : Ne pas retarder l’heure d’envoi.
● Réduire le temps du chargement au niveau du portail.
Accélérer l'accès aux données des diffusions :
Avec l’intégration de 400 000 données par jour :
Accélérer la sauvegarde des données lors de l’intégration

36. RETOUR D’EXPÉRIENCE : ARCHITECTURE GLOBALE DE LA SOLUTION MISE EN PLACE
{ number : 33 }
Fichiers d’entrée
Spring Batch
MongoDB
app WS
Widget Portail
Spring Data MongoDB
DAO

37. RETOUR D’EXPÉRIENCE : MONGODB
{ number : 34 }
● Tous les avantages cités précédemment (Clustering, Sharding,
ReplicatSet …)
● Modélisation basée sur la notion de Documents (JSON)

38. RETOUR D’EXPÉRIENCE : SPRING BATCH
{ number : 35 }
● Framework destiné aux applications Batch (lecture, traitement et stockage d’un grand volume
de données)
● Offre une interface d’administration des Batchs.
● Facilement intégrable avec d’autres framework Spring
● Offre des fonctionnalités avancées tel que la parallélisation des traitements

39. RETOUR D’EXPÉRIENCE : SPRING BATCH

40. RETOUR D’EXPÉRIENCE : SPRING DATA MONGODB
{ number : 36 }
● API Spring pour faciliter l’accès à des bases MongoDB
● Mapping Objet/Document basé sur les annotations.
● Offre un Repository pour les méthodes CRUD
● Facilite les requêtes

41. RETOUR D’EXPÉRIENCE : SPRING DATA MONGODB
{ number : 37 }
● Mapping Objet/Document basé sur les annotations.

42. RETOUR D’EXPÉRIENCE : SPRING DATA MONGO
{ number : 38 }
● Mapping Objet/Document basé sur les annotations.
Annotation Description
@Document Indique qu’il s’agit d’une collection.
@Id Spécifie l’identifiant de la collection.
@CompoundIndex Permet de rajouter un index sur la collection.
@Transient Permet d’exclure la persistance d’un attribut.
@Field Permet de spécifier le nom de l’attribut dans la base.
@PersistenceConstructor Constructeur utilisé lors de l’instantiation de l’objet à partir de la Base.

43. RETOUR D’EXPÉRIENCE : SPRING DATA MONGO
{ number : 39 }
● Repository pour les méthodes CRUD

44. RETOUR D’EXPÉRIENCE : SPRING DATA MONGO
{ number : 40 }
● Faciliter les requêtes : requêtes via les noms des méthodes

45. RETOUR D’EXPÉRIENCE : SPRING DATA MONGO
{ number : 41 }
● Faciliter les requêtes : requêtes via les noms des méthodes

46. RETOUR D’EXPÉRIENCE : SPRING DATA MONGO
{ number : 42 }
● Faciliter les requêtes : requêtes via @Query

47. RETOUR D’EXPÉRIENCE : SPRING DATA MONGO
{ number : 43 }
● Faciliter les requêtes : requêtes via MongoTemplate

48. RETOUR D’EXPÉRIENCE : BILAN
{ number : 49 }
Ancien POC
Intégration / Datasave des
données ≃ 11 Minutes ≃ 40 Secondes
Récupération des
données depuis le portail ≃ 30 Secondes ≃ 3 Secondes

49. CONCLUSION
{ number : 50 }
● En peu de temps, on a réalisé grand chose.
● Facilité de mise en place et de la prise en main.
● Amélioration en terme de performances garantie.

50. QUESTIONS ?
{ number : 51 }