I. Notions propres à Mongo▲
On parle de NoSQL (qui veut dire Not only SQL et non ?SQL), quelles sont donc les particularités de Mongo qui en font une base NoSQL ?
Il faut tout d’abord savoir que Mongo stocke ses données en BSON. Les données sont structurées exactement comme en JSON, mais il s’agit là d’une version binaire du JSON.
Un document BSON étant similaire à un document JSON, vous en avez très certainement déjà vu… Il s’agit de ceci.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
{
"_id": "558d0b3c5fa02e7e218b4b0c",
"description": "James Bond 007 is on the search for a Russian decoding machine, known as Lektor. Bond needs to find this machine…",
"actors": "Sean Connery, Daniela Bianchi, Pedro Armendáriz, Lotte Lenya",
"director": "Terence Young",
"genre": "Action, Adventure, Thriller",
"imdbRating": "7.5",
"trailer": "https://www.youtube.com/watch?v=D-BvAV6jYgU",
"writers": "Richard Maibaum (screenplay), Johanna Harwood (adaptation)",
"year": "1962-12-31T23:00:00.000Z",
"likes":
{
"count": 29,
"likedByUser": true
}
}
Comme vous pouvez le constater, on a donc des clefs et des valeurs et, tout comme en JSON (car c’est du JSON), une valeur peut être un objet, un tableau, un tableau d’objets, etc., ce sont des sous-documents. Un document similaire à un objet JavaScript peut en contenir d’autres.
Par ailleurs, les documents ne sont pas rigides. Ainsi, un document peut contenir un champ tandis que le suivant ne contient pas ce dernier. Par exemple, dans le cas des utilisateurs d’un site, on pourrait connaître l’adresse de certains tandis qu’on l’ignore pour d’autres. Dans ce cas, contrairement au SQL où le champ serait vide, ici on peut tout simplement l’omettre (ce qui n’empêchera pas de l’ajouter par la suite).
Maintenant que vous savez ce qu’est un document, reste à comprendre la notion de collection. Rien de sorcier et, vous l’aurez peut-être déjà deviné, une collection est un groupe de documents, similaire à une table dans le monde du SQL. Vous aurez ainsi une collection regroupant les utilisateurs, une autre regroupant les articles, etc.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
{
"_id": "558d0b395fa02e7e218b458c",
"firstname": "Morgan",
"lastname": "Haraki",
"mutualFriends": 2
},
{
"_id": "558d0b395fa02e7e218b4586",
"firstname": "Fred",
"lastname": "Farrid",
"mutualFriends": 0
},
{
"_id": "558d0b395fa02e7e218b4593",
"firstname": "Jérôme",
"lastname": "Lecomte",
"mutualFriends": 23
}
II. Installation▲
Mongo tourne sur un grand nombre d’OS et d’architectures. Il n’y a rien ici de très complexe dans son installation.
Sur les systèmes Debian like, généralement un petit coup d'apt install MongoDB suffira. Vous pouvez néanmoins utiliser les dépôts alternatifs proposés par Mongo afin d’avoir une version plus récente que celle proposée par votre OS.
Pour le Mac, homebrew permet l’installation également. Pour les binaires, Windows et toutes les autres options, le plus simple est encore d’aller directement consulter la page de téléchargement officielle.
III. Utilisation courante▲
Avant de pouvoir exécuter la moindre commande, il faut que la base de données soit lancée, cela se passe avec mongod (le d de dæmon) et se connecter au shell mongoDB, cela se passe avec mongo (le client).
Pour lancer la base de données, rien de très complexe, on lance la commande mongod et on lui passe quelques options si nécessaire.
2.
3.
4.
5.
# si la base de données n'est pas dans /data/db on doit spécifier le chemin avec --dbpath
mongod --dbpath db/
# si la base doit écouter sur un port spécifique
mongod --port 42
Enfin, on connecte le client Mongo et on pourra saisir toutes nos commandes. Rien de bien complexe, comme avec MySQL, on demande à mongo de se connecter à la base. Dans sa forme la plus simple, il s'agit juste d'exécuter mongo, mais il existe de nombreuses options. Nous en verrons certaines dans la partie administration.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
# afficher toutes les bases de données
show dbs
# utiliser la base "madatabase"
use madatabase
# voir dans quelle base on est
db
# afficher les collections
show collections
# renommer une collection
db.oldname.renameCollection("newname")
# effacer une collection
db.contacts.drop()
# effacer la base dans laquelle on est
db.dropDatabase()
# insertion
db.contacts.insert({ first: 'Quentin', last: 'Busuttil' })
# sélection
db.contacts.find()
db.contacts.find({ first: 'quentin' })
db.contacts.find({ first: 'quentin', last: 'busuttil' })
# sélectionner les documents dont un array contient une valeur x
db.contacts.find({ tags: 'business' })
# ou un élément parmi plusieurs
db.contacts.find({ tags: { $in: ['business', 'french'] } })
# ou la combinaison de plusieurs
db.contacts.find({ tags: { $all: ['business', 'french'] } })
# sous cette forme l'array correspond exactement à cela (ordre des éléments compris)
db.contacts.find({ tags: ['business', 'french'] })
# requêter selon des propriétés d'un sous-document
# admettons l'objet suivant :
# { nom: "Quentin", agenda: { lundi: "programmation", mardi: "dev", mercredi: "code" } }
# on pourra matcher depuis son sous-document ainsi (notez bien les guillemets autour de agenda.mardi)
db.users.find({ 'agenda.mardi': 'dev' })
# requêter selon un match exact de sous-document
db.users.find({ agenda: { lundi: "programmation", mardi: "dev", mercredi: "code" } })
# OR sélectionner selon une condition ou une autre
# il faut utiliser $or avec un array dont chaque élément est un objet littéral de sélection
db.users.find({ $or: [{ _id:ObjectId("558d0b395fa02e7e218b4587") }, { _id:ObjectId("558d0b395fa02e7e218b4574") }] })
# récupérer seulement certains champs d'un document
db.users.find({}, { _id: 0, fild1: 1, fild2: 0 })
# type == food || snacks
db.inventory.find({ type: { $in: ['food', 'snacks'] } })
# sélectionner les documents comportant un champ particulier
db.users.find({ birthyear: { $exists: true } })
# sélectionner les documents dont la valeur est différente de
db.users.find({ birthyear: { $ne: 2000 } })
# ne récupérer que le sous-document (récup le sous-document d'id x dans le doc d'id z)
db.users.find({ _id: z, "contacts._id": x }, { "contacts.$._id" : 1 })
# ordonner la sélection
# 1 = croissant/alphabétique et -1 = décroissant/alphabétique inversé
db.users.find().sort({ addedOn: 1 })
# update
# on peut utiliser { multi: true } pour modifier plusieurs documents à la fois
# l'option { upsert: true } permet de créer le document s'il n'existe pas
db.users.update({ _id: x }, { $set: { "firstname": "Baboo" } })
# update en remplaçant le document par un nouvel objet
db.users.update({ _id: 'azert' }, obj)
# update un sous-document d'id y du doc d'id x (dans un tableau de sous-documents appelé contacts),
# on remplace le sous-doc par un autre objet
# le document à modifier ressemble ici à
#{
# _id: x,
# name: azerty,
# contacts: [
# {
# _id: y,
# name: 'qwerty',
# email: 'qwerty@heymail.fr'
# }
# ]
#}
db.users.update({ _id: x, "contacts._id": y }, { $set: { "contacts.$":myNewDocument } })
# effacer un champ
db.users.update({ _id: x }, { $unset: { contacts: "" } })
# renommer un champ
db.users.update({}, { $rename: { "ancien_nom": "nouveau_nom" } }, { multi: true })
# effacer un champ de tous les documents d'une collection
# correspond à ALTER TABLE users DROP COLUMN zorglub
db.users.update({}, { $unset: { zorglub: "" } }, { multi: true } )
# retirer un élément d'un tableau
# (on retire l'ami "yyy" du tableau "friends" de l'utilisateur "xxx")
db.users.update({ _id: xxx }, { $pull: { friends: yyy } })
# on fait la même chose, mais on retire cet ami de tous les utilisateurs
# par exemple, l'ami yyy, s'est désinscrit
db.users.update({ friends: yyy }, { $pull: { friends: yyy } }, { multi: true })
# effacer un document
db.contacts.remove({ _id: ObjectId("55accc6c039c97c5db42f192") })
# effacer tous les documents d'une collection
db.contacts.remove({})
# effacer un sous-document d'id y du doc d'id x (dans un tableau de sous-documents)
db.users.update({ _id: x }, { $pull: { contacts: { _id: y } } })
# dans le même genre $pop permet d'enlever le dernier ou le premier élément d'un tableau
# respectivement en lui passant les valeurs 1 et -1
db.users.update({ _id: x }, { $pop: { contacts: -1 } })
Il est assez lourd de devoir taper à chaque fois db.users.commande, la console Mongo est aussi un shell JavaScript, il est donc tout à fait possible d'enregistrer des choses dans des variables !
2.
3.
4.
5.
// on enregistre la collection dans une variable
t = db.users
// nous pouvons maintenant faire comme ceci
t.find().pretty()
Elle est pas belle la vie ?
De la même manière, pour mettre à jour un objet, détaillons un peu ce que nous faisons ici db.users.update({_id: 'azert'}, obj) :
2.
3.
4.
5.
6.
7.
8.
// on récupère un objet
obj = t.find({ _id: 'azert' });
// on le met à jour comme n'importe quel objet js
obj.city = "Lyon"
// et on en enregistre les modifs
db.users.update({ _id: 'azert' }, obj)
III-A. Utilisation des dates▲
JS oblige, les dates sont un peu à part entière. Dans la mesure où nous avons souvent besoin de les traiter, faisons rapidement le tour du propriétaire !
Lorsque l'on veut requêter une date dans Mongo, il faut créer un objet de type Date. Cela se fait soit directement via le constructeur Date de JavaScript, soit via le wrapper Mongo ISODate.
La fonction Date() appelée sans new retourne simplement la date courante en tant que chaîne de caractères. Les autres formes, c'est-à-dire new Date(xxx), new ISODate(xxx) et ISODate(xxx) sont équivalentes et font toutes appel au wrapper ISODate. Il ne s'agit donc que d'une question de préférence personnelle.
Maintenant que nous avons levé l'ambiguïté qu'il peut y avoir entre ces différentes méthodes, utilisons-les. Pour l'exemple, nous allons récupérer les utilisateurs créés depuis le 15 septembre 2015.
db.users.find({ signupDate: { $gte: ISODate("2015-09-15") } })Évidemment, qui dit date, dit aussi heure. Franchissons le cap de la précision, les utilisateurs qui se sont enregistrés après le 15 septembre 2015 à 13h20.
db.users.find({ signupDate: { $gte: ISODate("2015-09-15T13:20:00.000Z") } })Vous vous apercevez certainement que la précision va jusqu'à la milliseconde… En effet, le moteur de Mongo stocke et traite les dates en nombre de millisecondes depuis l'époque Unix (sous la forme d'un entier de 64 bits, si ça vous intéresse). Nous héritons donc de la précision de ce format.
Vous notez peut-être également que deux lettres viennent s'ajouter à notre équation. Le T vient simplement faire office de séparateur et indique Time, tandis que le Z signifie que nous traitons du temps en Zulu Time [en], autrement dit, l'heure UTC.
La présence ou l'absence du Z est importante. Mongo stocke dans tous les cas la date au format UTC. Cependant, si vous omettez le Z, Mongo considère qu'il s'agit du fuseau horaire courant, donc UTC+1 si vous êtes sur le fuseau horaire de Paris, ou plus généralement CET (Central European Time), autrement dit l'heure d'Europe centrale.
Vous le comprenez, en l'absence du Z, Mongo fera l'opération pour ajouter ou retrancher des heures à UTC avant de la stocker, tandis que si vous le précisez, il stocke tel quel.
IV. Administration▲
IV-A. Sécurité▲
IV-A-1. Gestion des utilisateurs▲
Par défaut, Mongo est accessible sans authentification et permet toutes les actions sur la base. Il est évident dès lors que votre base est sur un serveur connecté sur Internet et que vous passez en production, cette configuration par défaut manque de sécurité. Ça devient même clairement du suicide si vous permettez de vous connecter à la base depuis le réseau… Réglage à effectuer dans /etc/mongod.conf :
2.
3.
4.
5.
# network interfaces
net:
port: 27017
# n'autorise que l'ip localhost (réglage par défaut)
bindIp: 127.0.0.1
De manière similaire à MySQL, vous ajoutez des utilisateurs et leur attribuez des droits (ici des rôles, sur diverses bases). Nous allons pour l'exemple créer un utilisateur « buzut » qui peut lire et écrire dans la base « blog_buzut » :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
# on se place dans la base de données "buzut_blog"
use buzut_blog
db.createUser(
{
user: "buzut",
pwd: "azertyytreza",
roles: [
{ role: "readWrite", db: "buzut_blog" },
# on peut ajouter d'autres rôles sur d'autres bases
{ role: "read", db: "buzut_shop" }
]
}
)
Une fois vos utilisateurs créés, il faut que vous configuriez mongo pour qu'il demande les accès. Pour cela, dans le fichier de config – situé dans /etc/mongod.conf – il faut ajouter le paramètre de sécurité correspondant :
2.
3.
4.
5.
6.
7.
8.
# security est normalement commenté, il faut le décommenter
# ou l'ajouter s'il n'existe pas
# et ajouter la ligne suivante
security:
authorization: enabled
# vous pouvez aussi démarrer mongo avec le mode auth directement depuis la ligne de commande
mongod --auth
Si vous avez modifié le fichier de config, il faut que vous redémarriez mongo pour que les changements s'appliquent. Pour cela, faites sudo service mongod restart.
Attention, si vous créez un utilisateur non administrateur et que vous activez ensuite l'authentification, vous ne pourrez plus créer d'autres utilisateurs. Pour créer un utilisateur avec les droits administrateur :
2.
3.
4.
5.
6.
7.
8.
9.
db.createUser(
{
user: "admin",
pwd: "azertyytreza",
roles: [
{ role: "dbOwner", db: "blog_buzut" }
]
}
)
Bien pratique, vous trouverez la liste des rôles dans la doc et vous pouvez même créer des rôles sur mesure pour plus de souplesse.
Les utilisateurs sont stockés dans admin.system.users, vous pouvez donc lister l'ensemble des utilisateurs en affichant cette collection ou en utilisant la commande show users.
Vous pouvez changer le mot de passe d'un utilisateur avec db.changeUserPassword("username", "newPass") et effacer un utilisateur avec db.dropUser("username"). Ces deux commandes nécessitent les privilèges administrateur et elles doivent être exécutées depuis la base à laquelle les utilisateurs sont liés.
Enfin, il est également possible d'ajouter et révoquer des droits ultérieurement. Nous utiliserons pour cela les commandes db.grantRolesToUser et db.revokeRolesFromUser :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
# il faut être placé dans la bonne base…
# vous commencez à avoir l'habitude
# pour ajouter des droits
db.grantRolesToUser(
"buzut",
[
{ role: "readWrite", db: "logs" }
]
)
# et pour enlever des droits
db.revokeRolesFromUser(
"buzut",
[
{ role: "readWrite", db: "logs" }
]
)
IV-A-2. Connexion▲
Une fois les utilisateurs créés et la base paramétrée pour passer en mode « authorization », il faudra que vous vous connectiez avec vos identifiants, sinon, vous serez jetés ! Pour ce faire, il faut préciser le login et le mot de passe ainsi que la base à laquelle l'utilisateur est rattaché :
2.
3.
4.
5.
6.
mongo -u buzut -p azertyyterza --authenticationDatabase blog_buzut
# il est aussi possible de se logger après la connexion
mongo
use blog_buzut
db.auth("buzut", "azertyyterza")
IV-A-3. Chiffrement▲
Je ne parlerai pas ici de chiffrer la base en elle-même – cette fonction n'est disponible que pour WiredTigger dans la version entreprise de Mongo. Sans avoir la version entreprise, vous pouvez chiffrer vos partitions Linux afin de garantir un niveau de sécurité encore plus élevé. Cependant, ce n'est pas spécifique à Mongo donc nous n'en parlerons pas ici.
Nous aborderons ici la question de chiffrer la transmission de données. En effet, bien que vous ayez configuré une authentification, si vous vous connectez à votre base de données mongo depuis un client distant, tout transite en clair. En d'autres termes, il est d'une simplicité déconcertante « d'écouter » toutes les données qui transitent entre vos machines. Pour contrer cela, nous allons utiliser SSL/TLS, le même protocole de chiffrement qu'utilisent certains sites web.
Nous générons d'abord une clef autosignée pour 365 jours :
2.
3.
4.
5.
cd /etc/ssl/
openssl req -newkey rsa:4096 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key
# on crée ensuite un fichier pem en concaténant la clef et le certificat
cat mongodb-cert.key mongodb-cert.crt > mongodb.pem
Il faut évidemment configurer mongo pour qu'il requière des connexions chiffrées et lui indiquer l'emplacement du certificat. Comme d'habitude, on se dirige vers /etc/mongod.conf et on ajoute les infos liées au ssl dans la partie net.
2.
3.
4.
net:
ssl:
mode: requireSSL
PEMKeyFile: /etc/ssl/mongodb.pem
Il est également possible d'accepter à la fois les connexions sécurisées et non sécurisées. Pour cela, il faudra renseigner le paramètre allowSSL ou preferSSL en lieu et place de requireSSL. Le premier est le plus permissif puisqu'il laisse le choix, tandis que le second peut s'avérer être un bon compromis. En effet, il laisse le choix aux clients du SSL ou non, mais il l'impose aux connexions entre serveurs.
Enfin, côté client, vous devrez spécifier qu'il faut se connecter via SSL. En outre, comme nous avons ici autosigné notre certificat et que nous ne requérons pas l'authentification via SSL, nous demanderons à Mongo d'ignorer la validation du certificat. Le SSL – qui permet à la fois de chiffrer et d'authentifier – sera ici uniquement utilisé pour le chiffrement. Pour plus d'information là-dessus, n'hésitez pas à lire la doc pour la sécurisation du serveur et du client.
mongo --ssl --sslAllowInvalidCertificates --host mongo.buzut.fr -u buzut -p azertyytreza --authenticationDatabase buzut_blogIV-B. Sauvegarde et restauration▲
Enfin, une base de données doit parfois être sauvegardée et restaurée. De la même manière que mysqldump permet de faire cela chez MySQL, il est extrêmement facile de le faire avec Mongo. Dans sa forme la plus simple, il suffit d'appeler mongodump et c'est tout ! Le dump est par défaut situé dans le dossier courant. Évidemment, quelques options bien pratiques sont à connaître :
-u
- Préciser le nom d'utilisateur.
-p
- Préciser le mot de passe.
-d
- Indiquer la base de données à sauvegarder. Par défaut, le dump contient toutes les bases.
-c
- Indiquer une ou plusieurs collections à sauvegarder.
-o
- Préciser un chemin pour l'export. - envoie les données sur la sortie standard.
Pas de sauvegarde sans restauration, nous sommes d'accord ! On utilisera pour ça mongorestore adresse_du_dump. Les options sont les mêmes que mongodump. -c permet de ne récupérer qu'une seule collection. -d indique la base de données dans laquelle importer les données. Si elle n'existe pas, elle sera créée. Si vous importez dans une base de données existante et qui n'est pas vide, mongorestore insère les nouvelles données sans modifier celles existantes. Et dans le cas où un document à importer possède le même _id qu'un document existant, ce dernier ne sera pas remplacé. Pour vider la base de données cible avant import, il existe l'option --drop.
IV-C. Gestion des index▲
Comme dans MySQL, les index permettent d'accélérer les requêtes en évitant au moteur de base de données de devoir scanner tous les documents de la collection afin de trouver ceux correspondant à la requête.
Voici les commandes les plus courantes :
2.
3.
4.
5.
# créer un index
db.users.createIndex({ username: 1 })
# créer un index et préciser que la valeur doit être unique
db.users.createIndex({ email: 1 }, { unique: true })
L'index ci-dessus considérera une absence de valeur comme une valeur. Il n'y a donc qu'un email qui pourra être vide, ensuite mongo considérera les autres emails sans valeur comme dupliqués et refusera de les ajouter. Pour empêcher ce comportement, on peut utiliser l'option sparse.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
db.users.createIndex({ email: 1 }, { unique: true, sparse: true })
# pour rechercher en mode fulltext et non en exact match
# il est possible d'utiliser l'index de type text
db.users.createIndex({ firstname: "text" })
# il ne peut y avoir qu'un seul index text par collection
# cependant, on peut les combiner
db.users.createIndex({ firstname: "text", lastname: "text" })
# afficher les index d'une collection
db.collection.getIndexes()
# supprimer un index (le nom de l'index est fourni par getIndexes)
db.collection.dropIndex("indexName")
# supprimer tous les index d'une collection
db.collection.dropIndexes()
# supprimer tous les index de la base
db.getCollectionNames().forEach(function(collection) {
db[collection].dropIndexes();
});
IV-D. Données et statistiques▲
Vous n'êtes pas sans savoir que, comme dans le monde SQL, il existe chez Mongo plusieurs moteurs de stockage.
Il est intéressant de savoir ce qui se passe dans sa base. Quel moteur de stockage est utilisé, quels sont les index, combien il y en a, quelle taille font les collections… Voici quelques commandes bien pratiques :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
# pour avoir toute sorte d'infos sur le serveur (paramètres de config etc)
db.serverStatus()
# connaître en un clin d'œil le moteur de stockage
db.serverStatus().storageEngine
# si votre moteur est WiredTigger, pour en afficher la configuration
db.serverStatus().wiredTiger
# lister les index dans une collection
db.users.getIndexes()
# lister les index dans toute la base
db.getCollectionNames().forEach(function(collection) {
indexes = db[collection].getIndexes();
print("Indexes for " + collection + ":");
printjson(indexes);
});
# connaître la taille des index en mémoire (mieux vaut que ça rentre dans la RAM)
db.collection.totalIndexSize()
Pour la route, la doc de PHP propose une table des correspondances entre les commandes SQL et Mongo.
Et vous, comment s'est passée la transition du SQL à Mongo ? Lequel préférez-vous ?
V. Note de la rédaction de Developpez.com ▲
Nous tenons à remercier Quentin Busuttil qui nous a aimablement autorisés à publier son tutoriel : Commandes essentielles de MongoDB. Nous remercions également Winjerome pour la mise au gabarit et f-leb pour la relecture orthographique.
