10/05/2015

Un peu dhistoire
Initialement dvelopp par 10gen en 2007
10gen rebaptis en 2013 MongoDB, Inc.
Son nom vient de "humongous" (cest norme
!!)
Mis en open source en 2009
Dernire version stable (3.0.2) Avril 2015

Quest-ce que MongoDB?

Une base de donnes NoSQL oriente documents
Les donnes ne sont pas dcrites par un schma, elles
sont stockes sous forme de documents JSON
La base de donnes NoSQL la plus populaire
Open source et portable
crite en C++
Disponible sur Windows, Linux, Mac OS X, Solaris

10/05/2015

Caractristiques (I)
Stockage/rcupration des donnes sous forme de
documents Document (format BSON: Binary JSON)
JSON partout, y compris dans les requtes
Gestion des Index riche et complte
Tout comme dans un SGBDR
Trs efficace (B-Tree)
Puissant langage de requte ( mais ce n'est pas du
SQL)
Rplication et haute disponibilit
Architecture Map/Reduce intgre

Caractristiques (II)
Auto-Sharding (scaling horizontal)
Les collections volumineuses peuvent tre divises et
distribues sur plusieurs shards (eux-mmes situs
sur plusieurs machines). Auto-balancing intgr.
Mises jour des donnes trs rapides
Oprations de mises jour atomiques
Mises jour "in place"
Et aussi: facile installer, trs bonne documentation,
large communaut d'utilisateurs,

10/05/2015

Les outils de MongoDB

Un shell JavaScript pour la ligne de commande
Des drivers pour les diffrents langages: Python, C++,
Java,
Des outils dadministration en ligne de commandes mais
aussi graphiques (MMS, OPS manager ou produits tiers:
PHPMoAdmin, )
De nombreuses plateformes de dploiements et
dhbergement disponibles: Amazon EC2, Microsoft
Azure, Google cloud, mongodirector, mongolab,
mongoHQ, modulus,

Qui l'utilise en production?

http://www.mongodb.org/about/production-deployments/

10/05/2015

Les diffrentes bases NoSQL

Cl-Valeur
Orientes Graphe
Orientes documents
Orientes colonnes

Les diffrentes bases NoSQL

10/05/2015

SQL vs NoSQL: termes et concepts

SGBD Relationnel

MongoDB

SQL vs NoSQL: termes et concepts

SGBD Relationnel

MongoDB

10/05/2015

SQL vs NoSQL: le data model

SQL traditionnel:

MongoDB:
{"firstname" : "John", "lastname" : "Doe", "widgets": 5}
ou
{"firstname" : "John", "lastname" : "Doe", "widgets" : "five"}
ou
{"firstname" : "John", "lastname" : "Doe", "widgets" : 5, "foo" :
"bar"}

SQL vs NoSQL: le data model

Prenons l'exemple, simplifi, de la conception d'une base
de donnes pour un blog. On suppose que:
Chaque "post" a un titre unique, une description et une
url.
Chaque "post" et associ 1 ou +sieurs "tags".
Chaque "post" contient le nom de son auteur et son
nombre total de "likes".
Chaque "post" est associ 0 ou n commentaires laisss
par des utilisateurs avec leur nom, un message, une
date/heure et un certain nombre de "likes".

10/05/2015

SQL vs NoSQL: le data model

Le schma normalis pour un SGBD
relationnel pourrait tre comme suit:

SQL vs NoSQL: le data model

Le modle de donnes d-normalis pour MongoDB
pourrait tre reprsent par un document comme suit:

{
_id: ObjectId(7df78ad8902c)
title: 'Prsentation de MongoDB',
description: 'MongoDB une base de donnes NoSQL',
post_by: 'ILEM Group',
url: 'http://www.ilemgroup.com',
tags: ['mongodb', 'database', 'NoSQL'],
likes: 6,
comments: [

10/05/2015

SQL vs NoSQL: le data model

{

by_user:'p.martin@gmail.com',
message: 'Bon post mais je prfre MySQL',
date_time: new Date(2014,1,20,2,15),
likes: 1
},
{ by_user:'r.dubois@yahoo.com',
message: 'Trs intressant, merci !',
date_time : new Date(2014,1,25,7,45),
likes: 5
}

]
}

SQL vs NoSQL: le data model

1.

2.

Si le modle de donnes comporte des entits lies, il y

a deux options:
Imbriquer les entits
Ex: un post du blog embarque en son sein les
commentaires => d-normalisation
Une entit rfrence l'autre
Ex: un post du blog rfrence les commentaires =>
normalisation

10/05/2015

SQL vs NoSQL: le data model

Les deux techniques sont possibles avec MongoDB: ici la

premire est plus adapte (toute donne non utile hors
de son document parent devrait tre imbrique).
En gnral on conseille de:
Regrouper autant que possible les donnes lies
dans une seul document: pas de jointures, les
requtes restent efficaces.
Mettre dans leur propre collection les donnes
utilises plusieurs endroits: moins de redondance,
mises--jour facilites.

SQL vs NoSQL: le data model

Avantage des donnes imbriques lors de la lecture:
1 seek sur le disque, 1 a/r vers la base -> rapidit
daccs.
On vite les jointures coteuses du SQL en rcuprant
un document avec ses sous-documents.
Mais cela entrane souvent une duplication des
informations et certaines mises jour plus complexes.
Attention: la taille maxi d'un document est de 16MB
sauf si on utilise GridFS.
GridFS: permet de stocker un fichier en plusieurs
documents et permet daccder celui-ci sans le
charger en totalit en mmoire.

10/05/2015

Les requtes: sur les bases

Lister les bases de donnes
show dbs
Lister les collections
show collections
Utiliser (ou crer) une base de donnes
use db-name
Quelle est la base courante?
db

Les requtes: crer une collection

Pour crer une collection:
db.createCollection('skieurs');
ou implicitement:
db.skieurs.insert({})
ou encore:
db.skieurs.insert({ "nom":"Vuarnet",
"prenom":"Jean"})

10

10/05/2015

Les requtes: d'insertion

Pour insrer des documents:
db.skieurs.insert({ nom:"Sailer",
prenom:"Tony"})
Mais comme il ny a pas de schmas :
db.skieurs.insert( { nom: "Tomba",
prenom:"Alberto",
surnom: "La bomba"});
db.skieurs.insert( { article:"Tournevis",
prix:12.5} );

Les requtes: lies aux index

Le champ obligatoire _id est index par dfaut
Crer un index sur un champ (ordre ASC):
db.skieurs.ensureIndex({nom:1});
Crer un index compos (nom ET age en mode
ASC et DESC) :
db.skieurs.ensureIndex({nom:1, age:-1});
Voir les index dune collection
db. skieurs.getIndexes();
Supprimer un index
db. skieurs.dropIndex('nom_1')

11

10/05/2015

Les requtes: de mises--jour

Les trs efficaces update "in-place"
db.skieurs.update({ age:{$gt: 65}},
{$inc: {age: 1}});

Plus classiques:
db.skieurs.update(

{ nom: "Tomba"},
{$set: {age: 49}});
db.skieurs.update({ age:{$gt: 65}},
{$set: {cat: "Veterans-3" }});

Les requtes: de suppression

Supprimer tous les documents:
db.skieurs.remove( )
Supprimer tous les documents et les index:
db.skieurs.drop( )
Supprimer selon critres:
db.skieurs.remove( { age: { $lt: 18 } } )

12

10/05/2015

Les requtes: de suppression

Par ObjectId:
db.skieurs.remove( {"_id":
ObjectId("517e33cf4937f8d068f9e9aa")});
Par champ quelconque:
db.skieurs.remove({nom: 'Saioni'});
db.skieurs.remove({prenom: 'Franz'},1);
// suppression 1ere occurrence seulement

Les requtes: de recherche

Sur une seule valeur
db.skieurs.find({nom:"Tomba"});

Sur deux valeurs

db.skieurs.find({prenom:"Franz", age:36});

avec oprateurs
db.skieurs.find({prenom:"Franz",
age: {$gte: 36}});
db.skieurs.find({age: {$in: [36, 47, 52]}});

On peut utiliser les regexp:

db.skieurs.find({nom:/^F/});

13

10/05/2015

Les recherches groupes

SQL propose les requtes HAVING, GROUP
BY, COUNT pour travailler sur des groupes de
lignes.
MongoDB offre 3 possibilits de faire des
requtes dagrgations:
1. le pipeline d'agrgation,
2. la fonction map-reduce
3. les simples commandes d'agrgations

Les recherches groupes

Le but est de calculer le nombre de skieurs par pays:
Avec Map-Reduce (ici pas trs intressant: complexe et
peu efficace car implment en JS):
var mapFunction = function() {
emit(this.pays, 1);
};
var reduceFunction = function(pays, ages) {
return Array.sum(ages);
};
db.skieurs.mapReduce( mapFunction,reduceFunction,
{ out: "map_reduce_example" }
)

14

10/05/2015

Les recherches groupes

Avec un pipeline dagrgation (plus simple et
implment en C++):
db.skieurs.aggregate({$group:
{_id: "$pays", count: { $sum : 1} }})
Avec une commande dagrgation:
db.skieurs.group(
{
key: { pays: 1 },
reduce: function(cur, result) {
result.count += 1 },
initial: { count: 0 }
})

Rcapitulatifs: oprations CRUD

Create
db.collection.insert( <document> )
db.collection.save( <document> )
db.collection.update( <query>, <update>, {
upsert: true } )

Read
db.collection.find( <query>, <projection> )
db.collection.findOne( <query>, <projection> )

Update
db.collection.update( <query>, <update>,
<options> )

Delete
db.collection.remove( <query>, <justOne> )

15

10/05/2015

MongoDB est-il ACID ?

Atomicit : oui/non. Oprations atomiques au niveau
du document (1 seul document la fois). Pas de
transaction (sauf de manire logicielle).
Cohrence : oui. Mme si on utilise la rplication seul
le serveur primaire rpond par dfaut
Isolation : oui/non. Non car pas de transaction mais
lock au niveau des collections (tables) voire mme des
documents avec 3.0 et WiredTiger
Durabilit: oui en grande partie. Par dfaut,
journalisation des donnes et sauvegarde du journal
toutes les 100ms. En cas de rplication on peut forcer la
durabilit.

Redondance et haute disponibilit

Redondance et haute disponibilit sont
proposes par le mcanisme de replica
set .
Un replica set est un ensemble dinstances
du serveur MongoDB partageant un mme
ensemble de donnes:
1 primaire
1 ou plusieurs secondaires
1 ou plusieurs arbitres
Au total 3 instances en gnral.

16

10/05/2015

Redondance et haute disponibilit

Toutes les oprations d'critures (et par dfaut
de lectures) sont adresses au seul primaire.
Le primaire enregistre les changements sur les
donnes dans son oplog (journal)
Les membres secondaires se synchronisent
partir de loplog du primaire de manire
asynchrone.

Redondance et haute disponibilit

17

10/05/2015

Redondance et haute disponibilit

On peut, par exemple, ddier une rplique aux
oprations de rcupration des donnes, de
reporting ou de sauvegarde.
On peut utiliser la rplication pour accrotre les
performances en lecture des donnes.
En cas de panne du primaire, le "replica set" va
lire un des membres secondaires qui devient le
primaire.

Scaling horizontal: le Sharding

Si donnes trop volumineuses ou performances
trop faibles, 2 options:
1. Scaling Vertical: augmentation des
capacits du serveur physique:
++RAM,+CPU, +DISQUE -> coteux, pas
toujours possible dans le cloud
2. Scaling Horizontal: on rpartit la charge
entre plusieurs machines -> moins coteux,
plus dlicat grer

18

10/05/2015

Scaling horizontal: le Sharding

Le sharding, ou fragmentation des informations,
est le processus qui va permettre de stocker les
donnes dune (ou plusieurs) collection sur
plusieurs serveurs (les shards) formant un
cluster.
Chaque shard est une base de donnes
indpendante, et collectivement, les shards
forment une seule base de donnes logique.

Scaling horizontal: le Sharding

19

10/05/2015

Scaling horizontal: le Sharding

Afin de fournir une meilleure scurit des donnes,
chaque shard est, en gnral, un "Replica Set".
Un Routeur de Requtes (il peut y en avoir
plusieurs) traite et dirige les requtes vers le bon shard
et retourne un rsultat aux clients.
Les donnes sont partitionnes par le processus de
Sharding, en se basant sur une cl de Shard.
Cette cl, particulirement importante, doit tre bien
choisie
Mongo maintient une distribution des donnes
quilibre entre membres d'un cluster grce des
programmes de contrle (auto-sharding).

Quand utiliser MongoDB?

Besoin de requtes dynamiques.
Pas de schmas -> souplesse
Langage de requtes puissant

Besoin de bonnes performances et de grer un

volume de donnes consquent.
Conue pour tre efficace
Scaling horizontal simple et efficace

Besoin de haute disponibilit dans un

environnement non fiable:
Mise en place de "replica sets" (ensemble de serveurs
fonctionnant sur le mode maitre-esclave) simple et rapide.
Rcupration depuis un "replica" secondaire, quasi
instantane, sre et automatique.

20

10/05/2015

Quand utiliser MongoDB?

Les donnes sont de taille importante (> 1GB)
et leur Schma n'est pas stable
MongoDB travaille sans schma, l'ajout d'un nouveau
champ est instantan et n'affecte pas l'existant.

On n'a pas de DBA disposition

Pas de schma, donc pas de normalisation, pas de
jointures, "load balancing" automatique, "failover"
automatique, ...

Pour faire persister des objets

Un objet peut facilement tre srialis au format JSON et
stock tel quel dans MongoDB.
Le support du format JSON de bout en bout est un des
points les plus intressants de la MEAN Stack

Quand utiliser MongoDB?

MongoDB possde nativement des fonctions
d'indexation gospatiale
Requtes gospatiales: trouver les N
restaurants les plus proches de ma position
requtes normales avec la commande find, en
utilisant des oprateurs spcifiques comme
near, within, ...
requtes avec la commande spcifique
geoNear: obtenir les distances entre les
objets, dans un espace cartsien plat et/ou
dans un espace sphrique.

21

10/05/2015

MongoDB: ses limites

Pas de transaction donc pas idal pour une
banque par exemple (on peut toutefois les
imiter de manire logicielle)
Pas de support du langage SQL (mais un langage
de requte trs puissant).
Pas de schmas donc peu de vrifications
(contraintes dintgrit) faites par MongoDB
(mais on peut utiliser des shmas logiciels ->
mongoose).

MongoDB: ses limites

Dmission rcente d'une partie de la direction
suivie du dpart volontaire d'environ 10% du
personnel de la socit (qui compte 400
employs environ) mais c'est un cas
"classique" dans les "Startups".
Les mcanismes dauthentification,
dautorisation et de cryptage ne sont pas
activs par dfaut (dbut 2015 des tudiants
ont pu accder 40000 instances de mongoDB
non protges !!) mais les futures versions
devraient voir l'authentification active ds
l'installation.

22