Gestion des documents

et des

Schémas de données

MongoDB vs mySQL

Base NOSQL

non relationnelle

orientée document

Vocabulaire

SQL vs Mongo

Base <=> Base
Collection <=> Table
Document / Objet <=> Ligne / Enregistrement
Champ <=> Colonne
Sous document ou Lien <=> Jointure

Mongo

Base de données

NoSQL avec
- replication
- sharding
Orientée documents
- sans schéma
- sans relationnel

Théorème CAP

Cohérence
Disponibilité
Tolérance au partitionnement

MongoDB

Consistency

Availability

Partition Tolerance

fail

Replication & Sharding

Redondance des nœuds d'instance
Duplication des données sur plusieurs nœuds
- En cas d'indisponibilité du nœud principal, la redondance assure la disponibilité des données
Distribution des données
Répartition des documents selon une de leur caractéristique
- Répartition de la charge
- Localisation des données

Orientée document

Document <=> Objet JSON avec un champ "_id"

Limite de taille à 16Mo pour du BSON (format interne)
Sinon recourt au GridFS

{
    "_id" : ObjectId("5811bac48b0cf22ea39e16ec"),
    ...
}

{
    "_id" : "toto",
    ...
}

{
    "_id" : 42,
    ...
}

Pas de schéma

des objets

NoSQL Orientée document

=>

et aussi

Pas de transactionnel
(sauf au sein d'une unique requête)

Pas de relationnel
Pas de schéma
(en option)

Pas de schéma

Du coup on peut avoir plusieurs types d'objets qui cohabitent dans la même collection !

{
    "name": "Voiture",
    "plate": "AR-456-YI",
    "nextControlDate": ISODate("2017-10-01T00:00:00.000Z"),
    "nbSeats": 5
}

{
    "name": "Camion",
    "plate": "AD-123-PS",
    "nextControlDate": "none",
    "capacity": 20
}

Pas de schéma

Certes mais

on doit savoir ce qu'on manipule
les documents peuvent avoir des relations entre eux
c'est à l'utilisateur (code) de gérer
- les schémas
- les relations
- les cycles de vie

Relations entre objets

type, composition et agrégation

Stockage d'objets

C'est fait pour !
Pas besoin des complications de SQL

Quid du polymorphisme ?

Règles de bon sens

On met un seul type d'objet dans une collection
=> On sait a priori ce qui est stocké
On met une famille d'objets dans la collection
& on identifie le type de chaque objet
=> Pour savoir précisément ce qu'on manipule

Quel est le type de mon document ?

Il faut une caractéristique d'identification

on peut ajouter un champ "_type", "_class" ou autre

ainsi

on sait quel type on manipule
si absent => type générique de la collection

Comment on identifie le type ?

Quel est le type de mon document ?

Exemple

{
    "_type": "car",
    "name": "Voiture",
    "plate": "AR-456-YI",
    "nextControlDate": ISODate("2017-10-01T...Z"),
    "nbSeats": 5
}

{
    "_type": "truck",
    "name": "Camion",
    "plate": "AD-123-PS",
    "nextControlDate": "none",
    "capacity": 20
}

Pas de relationnel

Pourtant l’agrégation et l'association sont des concepts de base des relations entre objets

Pas de relationnel

Mais on peut avoir des objets composés

{
    _id: "564f36c87dcbd96cf6f3e2ea",
    name: "Tactilia",
    address: {
        city: "Saint Grégoire"
        ...
    },
    products: [
        "fidbe", ...
    ],
    ...
}

Pas de relationnel

Mais on peut mettre des références vers un objet

{
    _id: "564f36c87dcbd96cf6f3e2ea",
    name: "Tactilia",
    employees: [
        "/employees/564f36c87dcbd07cf6f3e2ea",
        ...
    ],
    logo: "564f36c87dcbd97cf6f3e2ea",
    ...
}

L'aggrégation est à

gérer à la main

Agrégation & relation

{
    _id: "5b50f8968656472a58970167",
    password: "xxx",
    userId: "bchanclo",
    ??? lien vers le tiers ???
}

{
    _id: "564f36c87dcbd97cf6f3e2ea",
    firstname: "Benoît",
    lastname: "Chanclou",
    birthdate: ...
}

Account

Tiers

Exemple un compte d'accès en lien avec un tiers

Un simple id

suppose qu'on sache où aller chercher la ressource
on sait faire
- un accès direct à la base
- ou via l'api du référentiel Tiers

{
    _id: "5b50f8968656472a58970167",
    password: "xxx",
    userId: "bchanclo",
    user: "564f36c87dcbd97cf6f3e2ea",
}

GET http://api.myapp.com/tiers/1/contacts/564f36c87dcbd97cf6f3e2ea

db.tiers.findOne({_id: "564f36c87dcbd97cf6f3e2ea"})

Une uri (c'est universel !)

ne présuppose rien sur la localisation de la ressource
on sait
- extraire l'id pour une requête directe à la base
- ou appeler l'url correspondant à l'uri

{
    user: "http://api.myapp.com/tiers/1/contacts/564f36c87dcbd97cf6f3e2ea",
}

Une référence enrichie

les objets de type "Tiers" sont dans une collection ou un référentiel connu
on sait
- récupérer la ressource
- que ce sera un objet de type Tiers

{
    user: {
        type: "Tiers",
        id: "564f36c87dcbd97cf6f3e2ea"
    },
}

Les doublons

C'est le mal !

Ben non, c'est même plutôt utile

Les doublons

un cache

=> il faut une référence

Pour les requêtes croisées
pas d'aggregate pour les requête croisées
Pour les données en lecture seule
pour les tableaux par exemple
Il faut un mode de synchronisation

Requêtes croisées

Trouver des livraisons faites par un "John"

Impossible en une seule étape

utilisation de deux requêtes ou d'un aggregate

{
    ...
    "deliveryMan": xxx,
    ...
}

{
    "_id": xxx,
    "firstname": "John",
    "lastname": "Doe",
    "phone": "+33123456789",
    ...
}

db.Deliveries.find(
  { deliveryMan: {$in : johnIdsList } }
)

db.Tiers.find(
  { firstname: "John" }
)

Tiers

Deliveries

Requêtes croisées

Impossible sauf en mettant

les champs nécessaires dans le cache

{
    ...
    "deliveryMan": xxx,
    ...
}

{
    "_id": xxx,
    "firstname": "John",
    "lastname": "Doe",
    "phone": "+33123456789",
    ...
}

{
    ...,
    "deliveryMan": {
        "_id": xxx,
        "firstname": "John",
        "lastname": "Doe",
        "phone": "+33123456789"
    },
    ...
}

db.Customers.find(
  { deliveryMan.firstname: "John" }
)

Tiers

Customers

Une référence avec cache

si on veut juste le nom et le prénom
- inutile d'aller charger la ressource secondaire
- on utilise le cache
sinon, on sait récupérer la ressource secondaire complète dans son référentiel

{
    "contact": {
        "_id": xxx,
        "firstname": "John",
        "lastname": "Doe",
        "phone": "+33123456789"
    },
}

Avantages et Contraintes du cache

+ Accès rapide

+ Recherches rapide possible sur les champs mis en cache

+ Lazy loading de la ressource référencée

- Gérer le cycle de vie du cache :

- Invalidation

- Mise à jour

Mise à jour du cache

Asynchrone/Passif :
Lorsque la ressource secondaire est chargée (en lazy loading), on en profite pour mettre à jour le cache si nécessaire

Synchrone/Actif :
Lorsque la ressource secondaire est mise à jour
- En local :
  Le cache est lui aussi mis à jour
- Dans un autre référentiel :
  Le secondaire appelle un webhook du principal pour mettre à jour le cache

Versionner

Pourquoi ?

Les objets sont vivants

Un objet a un cycle de vie

création
modification
destruction

destruction

delete

Archivage permettant la restauration
=>Ajout d'un champ _archive: true

find({ 
    ..., 
    $or: [ { _archive: { $exists: false } }, { _archive: false } ]
})

find({ 
    ..., 
    _archive: true
})

Les objets ont des champs

en plus
en moins
renommés
qui changent de type

En plus

si c'est un champ qui ne peut pas être nul
=> initialiser la valeur par défaut dans le constructeur/loader
au prochain enregistrement il apparaîtra

En moins

il suffit de ne plus l'utiliser !
au prochain enregistrement complet il disparaîtra
au pire utiliser $unset (cas d'une champs volumineux)

Renommage

garder les deux noms
ajouter accesseur et mutateur

utiliser un système de version de schémas

mettre à jour les objets de la base avec $rename

Changement de type

ajouter accesseur et mutateur
pour retourner le bon type

utiliser un système de version de schémas

mettre à jour les objets de la base

Un objet

change de nature
fusionne avec un autre
se scinde en deux

changement de nature

le nouveau format est dans une autre collection
grâce au UUIDs
- si l'objet est dans la nouvelle collection => ok
- sinon l'objet est dans l'ancienne
  => convertir l'objet

utiliser un système de version de schémas

on met à jour les objets de la base

fusion

utiliser un système de version de schéma
à la lecture l'objet principal agrège le second objet

mettre à jour les objets de la base

scission

l'objet principal reste dans sa collection
- à la lecture si encore agrégé scinder l'objet
le second objet est transféré dans une autre collection
- l'objet est dans la nouvelle collection => ok
- sinon l'objet est encore agrégé à l'objet principal
  => convertir la partie du second objet
  (mettre aussi à jour l'objet principal)
- problème de génération de l'id du second objet

on met à jour les objets de la base

Versionner les schémas

Pourquoi ?

Parce qu'il n'y a pas de schéma !
=> plusieurs versions différentes peuvent cohabiter
- pas la peine de mettre les documents à jour
  => pas de script de mise à jour
  (sauf énorme changement)
- mais on ne sait pas quelle version on manipule
  => ajouter un champ "_version"
  (si absent = version 0)

Comment ?

{
    "addressStreet": "rue d'Alembert",
    "addressZipCode": "35000",
    "addressCityName": "Rennes",
    ...
}

{
    "_version": 1
    "address": {
        "street": "rue de Gauss",
        "zipCode": "56230",
        "cityName": "Questembert"
    },
    ...
}

{
    "_version": 2
    "address": {
        "street": "rue du Rennes",
        "city" : {
            "zipCode": "35700",
            "name": "Saint Malo"
        }
    },
    ...
}

var CONVERTERS = [
  obj => { 
    obj.address = {
      street: obj.addressStreet,
      zipCode: obj.addressZipCode,
      cityName: obj.addressCityName
    };
    delete obj.addressStreet;
    delete obj.addressZipCode;
    delete obj.addressCityName;
    obj._version = 1;
  },
  obj => { 
    obj.address.city = {
      zipCode: obj.address.zipCode,
      name: obj.address.cityName
    };
    delete obj.address.zipCode;
    delete obj.address.cityName;
    obj._version = 2;
  }
];
while (obj._version < CONVERTERS.length) {
  CONVERTERS[obj._version](obj);
}

Avantages et Contraintes

+ le code ne manipule que des objets au dernier format

+ on n'est pas obligé de mettre à jour toute la collection

+ pas de migration =

pas d'interruption de service
conversion au fil de l'eau

- recherche complexifiées

- il faut rechercher dans toutes les versions

utile dans une grosse base où peu d'objets sont utilisés
(ex.: liste de commandes clients, au quotidien on ne manipule que les plus récentes)

Gérer l'historique

Différentes méthodes

Cas #1

Un document par version

{  "docId" : 174, "rev" : 1,  "attr1": 165 }   /*version 1 */
{  "docId" : 174, "rev" : 2,  "attr1": 165, "attr2": "A-1" } 
{  "docId" : 174, "rev" : 3,  "attr1": 184, "attr2": "A-1" }

db.docs.find({ "docId": 174 }).sort({ "rev": -1 }).limit(-1);

findone

db.docs.aggregate( [ 
    { "$sort": { "docId" : 1, "rev" : -1 } },
    { "$group" : { "_id" : "$docId",
                   "doc": { "$first" : "$$ROOT" }
    } },
    { "$match": { "doc.attr1": 184 } }
] );

find

Cas #1a

Un document par version avec current

{  "docId" : 174, "v" : 1,  "attr1": 165 }
{  "docId" : 174, "v" : 2,  "attr1": 165, "attr2": "A-1" } 
{  "docId" : 174, "v" : 3,  "attr1": 184, "attr2": "A-1", "current": true }

db.docs.findOne({ "docId": 174, "current": true }));

findone

db.docs.find({ "doc.attr1": 184, "current": true }));

find

Cas #2

un seul document contenant toutes les versions

{  
    "docId" : 174, 
    "current" : { "attr1": 184, "attr2": "A-1" },
    "prev": [ {  "attr1": 165 }, {  "attr1": 165, "attr2": "A-1" } ]
}

db.CurrentCollection.findone({ "docId": 174 }, { current: 1 });

findone

db.CurrentCollection.find(
    { "current.attr1": 184 }, 
    { current: 1 }
);

find

Cas #3

Deux collections

CurrentCollection:    
  { "docId" : 174, "rev": 3, "attr1": 184, "attr2": "A-1" }
PreviousCollection:
  { "docId" : 174, "rev": 1, "attr1": 165 }
  { "docId" : 174, "rev": 2, "attr1": 165, "attr2": "A-1" }
  { "docId" : 174, "rev": 3, "attr1": 184, "attr2": "A-1" }

db.CurrentCollection.findone({ "docId": 174 });

findone

db.CurrentCollection.find({ "attr1": 184 });

find

Cas #4

Un document par version mais on stocke les deltas

sous forme de JSONPatch

{ "_id": ..., "id": 174, "userId": "xxx", "date": ISODate(...), patch: [
    { "op": "add", "path": "/attr1", "value": 165 }
] }
{ "_id": ..., "id": 174, "userId": "yyy", "date": ISODate(...), patch: [
    {"op": "add", "path": "/attr2", "value": "A-1" }
] } 
{ "_id": ..., "id": 174, "userId": "zzz", "date": ISODate(...), patch: [
    { "op": "replace", "path": "/attr1", "value": 184 }
] }

chaque patch contient

id du document
date de modification
patch à appliquer

en option

id utilisateur
son rôle
id du tenant

find

Compliqué on doit procéder en deux étapes

créer une collection où on reconstruit les objets
puis effectuer la recherche

db.docs.aggregate( [ 
    { $match: { id: "174" } },    // recherche tous les patches sur l'entité
    { $sort: { "date" : 1 } },    // trie les résultats par date
    { $unwind : "$patch" },       // aplati tous les patchs
    { $group: { _id: "$id", patch: { $push:"$patch" } } } 
    // regroupe tous les patchs en un tableau
] );

findone

On agrège tous les patchs lié à l'id de l'objet puis on applique la liste de patchs sur un objet vide
On peut ajouter un filtre sur la date pour gérer les révisions

Cas #3+4

Deux collections

SnapshotCollection:    
  { "id" : 174,  "v": 3, "attr1": 184, "attr2": "A-1" }
PatchCollection:
  { "_id": ..., "id": 174, "userId": "xxx", "date": ISODate(...), patch: [...] }
  { "_id": ..., "id": 174, "userId": "yyy", "date": ISODate(...), patch: [...] } 
  { "_id": ..., "id": 174, "userId": "zzz", "date": ISODate(...), patch: [...] }

db.SnapshotCollection.findone({ "docId": 174 });

findone

db.SnapshotCollection.find({ "attr1": 184 });

find

Cas #5

oplog

Le but est d'utiliser les logs de mongo pour gérer l'historique des versions du document (voir ce blog)

Au final

S'adapter

au besoin

et

à la volumétrie

Indexation

Accélérer les recherches

Qu'est-ce qu'un index ?

Une structure de recherche

but :
réduire le temps de réponse de requêtes
inconvénient :
prend de la place
consommateur de ressources

Quand les utiliser ?

il faut les utiliser mais pas en abuser
les utiliser pour les requêtes identifiées comme
- lentes
- fréquentes

champ _id

indexé par défaut

Créer un index

Différents types d'index :
- simple, composé, multi-clé, géospatial, texte, hash
Propriétés
- unique, partiel, clairsemé, TTL,

db.xxx.createIndex( <key & index type specification>, <options> )

Indexation

Pour le geospatial c'est top
Pour le texte c'est bof mais ça s'améliore
il faut mieux utiliser une base d'indexation basée sur lucene
(comme solr ou elasticsearch, ou des services tout fait comme algolia)

MongoDB

Résumé

Nécessité d'un modèle

Connaître le contenu est indispensable
=> Spécifier le type de document

Sous types

=> utiliser le "_type"

{
    "_id": ...,
    "_type": "Sous type 1",
    "champSpecifiqueSousType1" : []
    ...
}

l'héritage c'est le mal,
l'agrégation c'est le bien

Agrégats

=> utiliser un tableau de "_tags"

{
    "_id": ...,
    "_tags": [ "Attribut_1", "Attribut_2", ...],
    "champSpecifiqueAttr1" : null,
    "champSpecifiqueAttr2" : ""
    ...
}

=> utiliser des sous-objets

{
    "_id": ...,
    "Attribut_1": { "champSpecifiqueAttr1" : null },
    "Attribut_2": { "champSpecifiqueAttr2" : ""	},
    ...
}

Champs dynamiques

=> utiliser un modèle

{
    "_id": ...,
    "_modId": [ 123 ],
    "aaa": 42
    ...
}

{
    "_id": 123,
    "fields": [ { 
        "name": "Champ quelconque", 
        "label": "aaa", 
        "type": "int", 
        .... }, 
    ... ]
}

Modèle

dans le nom de la collection

Les tenants

dans les documents

db.data_564f36c87dcbd97cf6f3e2ea.find()

Mettre un id de tenant

db.data.find({ownerId: "564f36c87dcbd97cf6f3e2ea"})

{
    ...,
    ownerId: "564f36c87dcbd97cf6f3e2ea",
    ...
}

Identifiant(s)

La plupart du temps on ne distingue pas les identifiants

technique (mongo _id)
de l'objet

On utilise le premier pour le second

Identifiant(s)

Cas où un objet est scindé en plusieurs documents mongo

trop gros (>limite de document de 16Mo)
en plusieurs parties

On distingue alors les identifiants

les identifiants techniques
un unique identifiant d'objet

pour récupérer l'objet on fusionne tous les documents mongo ayant cet identifiant d'objet

Liens

bibliographie

Documentations

Documentation mongo (la recherche marche bien)
Wikipédia : Bases de données orientées documents
Wikipédia : Théorème CAP
MongoDB et le Théorème CAP
Stack MEAN (on préfèrera remplacer Angular par React !)
Mongoose

Blogs & présentations

Utiliser un framework

certains frameworks savent gérer ce type de références
(au sein d'une même application, même db)

java : Spring
js : mongoose (populate)