Mongo DB

{ name : ‘MongoDB’, type : ‘NoSQL’ }

{ speakers : [‘Oussama MAHJOUB, ‘Oussama ZOGHLAMI ], date : ‘16/12/2014’

}

SOMMAIRE

❖ Partie 1

● MongoDB

● Data Modeling

● Concepts Clés

❖ Partie 2● Retour d’expérience

MONGODB : CONTEXTE

{ number : 1 }

MONGODB : DÉFINITION

MongoDB est une base de données :

{ number : 2 }

● Open source

● Non relationnelle

● Orientée documents

● Répartie

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

MONGODB : DATA MODELING : COLLECTION

Scheamaless

{ number : 4 }

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 }

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

CONCEPTS CLÉS

❖ Journaling➢ Recouvrement après une panne

❖ ReplicaSet➢ Réplication + Disponibilité

❖ Sharding➢ Scaling horizonal + Load balancing

{ number : 7 }

CONCEPTS CLÉS : JOURNALING : PROBLÉMATIQUE

{ number : 8 }

CONCEPTS CLÉS : JOURNALING : PROBLÉMATIQUE

{ number : 8 }

Data Perdue

CONCEPTS CLÉS : JOURNALING : SANS JOURNAL

{ number : 9 }

CONCEPTS CLÉS : JOURNALING : AVEC JOURNAL

{ number : 10 }

CONCEPTS CLÉS : JOURNALING

{ number : 11 }

Replay

CONCEPTS CLÉS : JOURNALING : CONCLUSION

{ number : 12 }

● Recouvrement Automatique

● Impacte les performances d'écriture

● Activation / Désactivation au choix

CONCEPTS CLÉS : REPLICASET: PROBLÉMATIQUE

{ number : 13 }

CONCEPTS CLÉS : REPLICASET: PROBLÉMATIQUE

{ number : 14 }

Serveur Indisponible

CONCEPTS CLÉS : REPLICASET : ARCHITECTURE

{ number : 15 }

CONCEPTS CLÉS : REPLICASET : ELECTION

{ number : 16 }

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 }

CONCEPTS CLÉS : REPLICASET : EXERCICE

{ number : 18 }

Replication Factor ?

7Les arbitres ne répliquent pas

Fault tolerence Factor ?

4

Majority = 5 ; N = 9

FTL = 9 - 5 = 4

N = 9

CONCEPTS CLÉS : REPLICASET : REPLICATION

{ number : 19 }

Asynchronous Replication

oplog = log d’opérations

ReplayReplay

Comment se fait la réplication ?

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

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

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 }

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 }

CONCEPTS CLÉS : REPLICASET : CONCLUSION

● Basculement automatique par vote ( natif )

● Redondance des données

● Haute disponibilité

{ number : 24 }

CONCEPTS CLÉS : SHARDING : PROBLÉMATIQUE

{ number : 25 }

CPU limitI/O limitStorage limit

Solution : Vertical scaling● + CPU● + RAM● + Capacité Disque

CONCEPTS CLÉS : SHARDING : ARCHITECTURE

{ number : 26 }

CONCEPTS CLÉS : SHARDING : DATA DISTRIBUTION

● Collection distribution level● Shard Key = clé de

répartition

{ number : 27 }

collection : { x : 1 }{ x : 100 }{ x : -20 }

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

CONCEPTS CLÉS : SHARDING : CONCLUSION

{ number : 29 }

Une architecture en sharding garantit :

● De hautes performances

● Une haute disponibilité

● Une mise à l'échelle automatique ( natif )

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 }

RETOUR D’EXPÉRIENCE : CONTEXTE CLIENT / L’EXISTANT

{ number : 31 }

app WS Widget

Oracle

Batch

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

RETOUR D’EXPÉRIENCE : ARCHITECTURE GLOBALE DE LA SOLUTION MISE EN PLACE

{ number : 33 }

Fichiers d’entrée

Spring Batch

MongoDB

app WS

Widget PortailSpring Data MongoDB

DAO

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)

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

RETOUR D’EXPÉRIENCE : SPRING BATCH

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

RETOUR D’EXPÉRIENCE : SPRING DATA MONGODB

{ number : 37 }


RETOUR D’EXPÉRIENCE : SPRING DATA MONGO

{ number : 38 }


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.


{ number : 39 }

● Repository pour les méthodes CRUD


{ number : 40 }

● Faciliter les requêtes : requêtes via les noms des méthodes


{ number : 41 }

● Faciliter les requêtes : requêtes via les noms des méthodes


{ number : 42 }

● Faciliter les requêtes : requêtes via @Query


{ number : 43 }

● Faciliter les requêtes : requêtes via MongoTemplate

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

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.

QUESTIONS ?

{ number : 51 }

Mongo DB

Technology

Transcript of Mongo DB