Dans cette session, vous apprendrez: Les différences entre modéliser pour MongoDB versus une base de données relationnelle. Une méthodologie pour modéliser pour MongoDB qui est adaptable aux projets simples, agiles ou plus complexes. Quelques patrons de conception (design patterns) courants dans le développement d'applications avec MongoDB, dans le but de maximiser la performance.

1. Modélisation de données pour
MongoDB
Daniel Coupal, Équipe pédagogique, MongoDB
4 décembre 2018
Paris, France

2. Daniel Coupal
Équipe de formation, MongoDB
daniel.coupal@mongodb.com
Palo Alto, Californie, États-Unis
github.com/dcoupal

3. Objectifs de la présentation
a) Comprendre les différences entre modéliser pour MongoDB versus une base
de données relationnelle
b) Connaitre les phases d'une méthodologie adaptable pour modéliser MongoDB
c) Reconnaître le besoin d'appliquer des patrons de conception (Design Patterns)

4. Différences entre modéliser pour
MongoDB versus
une base de données relationnelle

6. Unité de base: Document
1. Polymorphisme
• documents peuvent contenir différents
attributs
2. Tableau (Array)
• représente une relation 1-N
• peut être indexé
3. Sous document
• groupe des attributs ensemble
4. JSON/BSON
• document souvent représenté en JSON
• BSON est le format physique

7. Cinq tables …

8. … deviennent une ou deux collections

9. 2 modèles pour un réseau social

10. Différences pour le schéma
Relationnel MongoDB
Etapes pour créer un modèle 1 - schéma
2 - développement (requêtes)
1 - identification des requêtes
2 - schéma
Schéma initial pour le problème Une solution possible en 3ième
forme normale
Plusieurs solutions possible
Schéma final Probablement dé normalise Peu de changement
Evolution du schéma Difficile et sous optimisé Facile et pas d'interruption de
service
Performance Médiocre Optimale

11. Autres considérations pour le modèle
A. Relations 1-N, où N est un nombre gigantesque
B. Imbriquer ou référencer
• Joints via $lookup
• Transactions pour multi-documents
C. Transactions disponibles pour les Replica Sets, et bientôt les Sharded Clusters
D. Clé de partitionnement (Sharding Key)
E. Index
F. Requêtes simples ou via Agrégation

12. Méthodologie adaptable pour MongoDB

14. Méthodologie
1. Identifier les requêtes
2. quantifier et qualifier les requêtes
3. modeler les relations
4. appliquer des transformations

15. Souplesse de la méthodologie
Objectif
Simplicité
Mélange de
simplicité &
performance
Performance
1. Identifier les requêtes
2. Quantifier et qualifier les requêtes ! !
3. Modeler les relations
4. Transformations (Patterns) !

16. Étude de cas: CaféEuro
A. Business: franchises de cafés
B. Sous-marques: CaféFrance, CaféBrexit, CaféCorsé
C. Objectifs:
• 10 000 établissements en Europe
D. Clés du succès:
• Meilleur café au monde
• Technologie de pointe

17. Faire le meilleur café au monde!

18. Technologie de pointe
1. Mesure d'inventaire en temps réel
• Étagères de rangements avec balances
2. Masse importante de données ("Big Data")
• Données sur chaque café servi
3. Analyse des données
• Périodes de pointe
• Protection contre le vol d'inventaire
4. MongoDB

19. Méthodologie
1. Identifier les requêtes
2. quantifier et qualifier les requêtes
3. modeler les relations
4. appliquer des transformations

20. 1 – Identifier les requêtes
Requête Opération description
1. Poids du café sur les étagères écriture Une étagère envoie un message lorsque l'on met ou
prend un sac de café
2. Besoin de livraison du café lecture Calculer le nombre de sacs de café à envoyer à chaque
établissement
3. Anomalies dans l'inventaire lecture Analytique
4. Fabrication d'une tasse de café écriture Une machine à café rapporte chaque tasse fabriquée en
temps réel
5. Analyse des tasses de café lecture Analytique
6. Support technique lecture Répondre à une requête au téléphone, ou web, d'un
franchisé

21. Méthodologie
1. Identifier les requêtes
2. quantifier et qualifier les requêtes
3. modeler les relations
4. appliquer des transformations

22. Requête Quantification Qualification
1. Poids du café sur les étagères 10/jour*étagère*établissement
=> 1/sec
<1s
écriture critique
2. Besoin de livraison du café 1/jour*établissement
=> 0.1/sec
<60s
3. Anomalies dans l'inventaire 24 lectures/jour <5mins
"collection scan"
4. Fabrication d'une tasse de café 10 000 000 écritures/jour
115 écritures/sec
<100ms
écriture non-critique
… tasses de café à l'heure de pointe 3 000 000 écritures/heure
833 écritures/sec
<100ms
écriture non-critique
5. Analyse des tasses de café 24 lectures/jour données dépassées (stale)
"collection scan"
6. Support technique 1000 lectures/jour <1s
2 – Quantifier et qualifier les requêtes

23. 2 – Quantifier et qualifier les requêtes
Requête Quantification Qualification
1. Poids du café sur les étagères 10/jour*étagère*établissement
=> 1/sec
<1s
écriture critique
2. Besoin de livraison du café 1/jour*établissement
=> 0.1/sec
<60s
3. Anomalies dans l'inventaire 24 lectures/jour <5mins
"collection scan"
4. Fabrication d'une tasse de café 10 000 000 écritures/jour
115 écritures/sec
<100ms
écriture non-critique
… tasses de café à l'heure de pointe 3 000 000 écritures/heure
833 écritures/sec
<100ms
écriture non-critique
5. Analyse des tasses de café 24 lectures/jour données dépassées (stale)
"collection scan"
6. Support technique 1000 lectures/jour <1s

24. Espace disque
Tasses de café (une année de données)
• 10000 x 1000/jour x 365
• 3.7 milliards/année
• 370 GB (100 bytes par tasse de café)
Pesées
• 10000 x 10/jour x 365
• 365 millions/année
• 3.7 GB (100 bytes par pesée)

25. Méthodologie
1. Identifier les requêtes
2. quantifier et qualifier les requêtes
3. modeler les relations
4. appliquer des transformations

26. Relations sont importantes
Type de Relation -> 1-1 1-N N-N
Document imbriqué
dans le parent document
• une lecture
• pas de joint
• une lecture
• pas de joint
• une lecture
• pas de joint
• duplication
d'information
Document référencé
dans le parent document
• plusieurs lectures
• lectures plus petites
• plusieurs lectures
• lectures plus petites
• plusieurs lectures
• lectures plus petites
• Pas de duplication
d'information

27. Entités du CaféEuro
- Tasses de café
- Etablissements
- Machines a café
- Etagères
- Pesées
- Sacs de café

28. Méthodologie
1. Identifier les requêtes
2. quantifier et qualifier les requêtes
3. modeler les relations
4. appliquer des transformations

29. Patrons de conception (Design Patterns)

30. Ressources pour les "Design Patterns"
A. Advanced Schema Design Patterns
• MongoDB World 2017
• Webinar
B. MongoDB University
• university.mongodb.com
• M320 – Data Modeling (2019)
C. Appendice de cette présentation
• Schema Versioning Pattern
• Computed Pattern

31. Patrons - systèmes

32. Schema Versioning

33. Computed Pattern

34. Subset Pattern

35. Subset Pattern

36. Bucket Pattern

37. Bucket Pattern
{
"device_id": 000123456,
"type": "2A",
"date": ISODate("2018-03-02"),
"temp": [ [ 20.0, 20.1, 20.2, ... ],
[ 22.1, 22.1, 22.0, ... ],
...
]
}
{
"device_id": 000123456,
"type": "2A",
"date": ISODate("2018-03-03"),
"temp": [ [ 20.1, 20.2, 20.3, ... ],
[ 22.4, 22.4, 22.3, ... ],
...
]
}
{
"device_id": 000123456,
"type": "2A",
"date": ISODate("2018-03-02T13"),
"temp": { 1: 20.0, 2: 20.1, 3: 20.2, ... }
}
{
"device_id": 000123456,
"type": "2A",
"date": ISODate("2018-03-02T14"),
"temp": { 1: 22.1, 2: 22.1, 3: 22.0, ... }
}
Bucket par jour Bucket par heure

38. CaféEuro - Solution avec patterns
• Schema Versioning
• Subset
• Computed
• Bucket
• External Reference

39. Conclusion

40. Objectifs de la présentation
a) Comprendre les différences entre modéliser pour MongoDB versus une base
de données relationnelle
• Modèle document
b) Connaitre les phases d'une méthodologie adaptable pour modéliser MongoDB
• Prenez le temps de bien connaître vos requêtes
• Compromis entre simplicité et performance
c) Reconnaître le besoin d'appliquer des patrons de conception (Design Patterns)
• Atouts pour améliorer la performance de votre solution

41. A venir …
• cours intitulé "Data Modeling" sur:
university.mongodb.com

42. Merci!

43. Appendice A
Schema Versioning Pattern

44. Cauchemar: Alter Table

45. A quoi devrait ressembler une mise à jour!

46. Révision du schéma
Relationnel MongoDB
Unité avec versions Schéma Document
Procédure Difficile Relativement facile
Service lors de la révision des données Interrompu Aucune interruption
Annuler la mise à jour du schéma Difficile Relativement facile

50. Cycle de vie de l'application
1 - Modifier l'application
• permet de gérer toutes les versions de
documents
• une fonction par version
• optionnellement, change les attributs si
autre modifications
2 - Mettre à jour les serveurs de l'application
• un serveur à la fois
3 - Finalement
• retirer le code des anciennes versions.

51. Cycle de vie des documents
Nouveaux documents:
• l'application utilise le dernier format
Documents existants:
• mise à jour par l'application
• mise à jour en batch
• Pas de mise à jour, car ces documents
sont
vieux et ce n'est pas nécessaire

52. Mise à jour des documents dans le temps

53. Problem Solution
Use Cases Examples Benefits and Trade-Offs
Schema Versioning Pattern
● Avoid downtime while doing schema
upgrades
● Upgrading all documents can take hours, days
or even weeks when dealing with big data
● Don't want to update all documents
No downtime needed
Feel in control of the migration
Less future technical debt
! May need 2 indexes for same field while in
migration period
● Each document gets a "schema_version" field
● Application can handle all versions
● Choose your strategy to migrate the
documents
● Every application that use a database,
deployed in production and heavily used.
● System with a lot of legacy data

54. Appendice B
Computed Pattern

55. Opérations Mathématiques

56. Opérations Mathématiques

57. Opérations de "Fan Out"

58. Opérations de "Roll Up"

59. Problem Solution
Use Cases Examples Benefits and Trade-Offs
Computed Pattern
● Costly computation or manipulation of data
● Executed frequently on the same data,
producing the same result
Read queries are faster
Saving on resources like CPU and Disk
! May be difficult to identify the need
! Avoid applying or overusing it unless needed
● Perform the operation and store the result in
the appropriate document and collection
● If need to redo the operations, keep the
source of them
● Internet Of Things (IOT)
● Event Sourcing
● Time Series Data
● Frequent Aggregation Framework queries