Présentation et retour d'expérience sur MongoDB

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 }