Modélisation d’un schéma d’une base de données NoSQL

Cet article a pour objectif d’aider à concevoir le schéma d’une base de données NoSQL, ici orientée Document. Nous verrons à quel point les cas d’usages peuvent être déterminants dans l’obtention de hautes performances.

Scalabilité horizontale et verticale

Avec l’explosion de la taille des données à gérer que connaissent certaines sociétés, les bases de données traditionnelles n’arrivent pas à fournir un temps de réponse satisfaisant. Deux solutions sont envisageables :

  • Augmenter les ressources de la machine (la puissance du processeur, la mémoire, etc.) : c’est ce qu’on appelle une scalabilité verticale. Cette solution a cependant ses limites : en effet, on ne peut pas augmenter la puissance du processeur à l’infini par exemple, d’autant plus que l’augmentation des performances des composants est suivie d’une augmentation du prix encore plus importante.
  • Utiliser un cluster de machines ce qui, en théorie, permet une augmentation illimitée des capacités avec un coût de revient moindre, car il suffit d’ajouter d’autres machines au cluster : c’est ce qu’on appelle une scalabilité horizontale.

Attention : au delà d’une certaine taille de données, il n y a que la deuxième solution qui demeure plausible.

Le problème, c’est que dans un cluster, les points forts des bases de données relationnelles, transaction, jointure et propriétés ACID handicapent les temps de réponse. Et c’est suite à ce constat que les bases de données NoSQL ont émergé, ces bases se caractérisant par l’abondant des jointures et des transactions au profit d’un temps de réponse court. La question qui se pose est donc de savoir comment concevoir son schéma de données dans un tel contexte ? La solution réside dans la dé-normalisation des données.

Qu’est ce que la dé-normalisation ?

NosqlDans une relation entre deux tables A et B, la dé-normalisation consiste à dupliquer certaines données de la table B dans la table A afin d’optimiser les requêtes qui pourront se contenter d’interroger la table A sans avoir à faire la jointure entre A et B. Pour la suite de l’article, prenons comme exemple les bases de données NoSQL orientées Document (telles que MongoDB ou CouchBD, mais les mêmes principes s’appliquent aussi sur les autres types de bases NoSQL).

Dans une base NoSQL orienté Document, une ligne d’une table relationnelle correspond un document structuré (ex. un objet JSON ou un document XML) et une table à une collection de documents. La collection peut contenir des documents de structures différentes et les documents peuvent contenir eux même d’autres documents imbriqués. Il existe trois grandes stratégies de dé-normalisation des données :

1. Imbrication de documents

Pour une relation entre deux documents A et B, cela consiste à avoir le document B  imbriqué dans le document A. Il existe deux cas d’utilisation pour cette stratégie :

  • On peut se passer de la collection des documents imbriqués. Ainsi, toutes les requêtes concernant le document parent concerneront aussi les données du document imbriqué.
    Exemple :  imbrication de l’adresse dans le document du client.
{
    'id': 10,
    'nom': 'dupont',
    'prenom': 'david',
    'email':'me@palo-it.com',
    'adresse':
        {
        'pseudo':'10 rue du test',
        'ville':'paris',
        'pays':'France',
        'code postal':75009
        }
}
  • On peut modifier les documents parents et enfants d’une manière atomique. En effet, les bases de données NoSQL permettent souvent la modification atomique d’un document. Cependant, l’imbrication de document n’est pas possible si on veut créer le document enfant avant le document parent.

2. Duplication d’un sous ensemble de champs

L’idée est de dupliquer le minimum de données du document B dans A et de préférence, celles qui ne changent pas ou pas souvent, car lors de leur mise à jour, nous devrions faire un update sur l’ensemble des documents qui les contiennent, plutôt qu’à un seul endroit dans une base de données normalisée. N’oublions pas que ces modifications augmenteront le temps d’écriture.

Exemple : en visitant la page d’un de ses amis, un utilisateur Facebook n’a souvent besoin que de voir s’afficher dans un premier temps son pseudo et sa photographie. C’est seulement en cliquant sur son profil qu’il accédera à des informations complémentaires.

3. Duplication de la clé primaire

Cette fois, on ne duplique que la clé primaire du document B  dans le document A. Pour récupérer les données, l’application doit faire deux requêtes : une première requête pour récupérer la clé primaire,  puis une seconde pour récupérer les données de l’autre coté de la relation.

Exemple : prenons la relation N-N entre livres et auteurs. Le document de l’auteur contient la liste des clés primaires de ses livres et le livre contient les clés primaires de ses auteurs. On commence par récupérer les identifiants des auteurs puis on interroge la collection des livres pour récupérer le reste des données.

Auteur
{
    "id": 10,
    "nom": "dupont",
    "prenom": "david",
    "livres": [
        101,503,339,342
    ]

}
Livre
{
    "id": 342,
    "titre": "NoSQL schema",
    "genre": "informatique",

    "tags":["informatique","bigdata","nosql"]
    "auteurs": [
        10,234
    ]

}

À effectuer si l’on veut avoir un compromis entre les temps d’écriture et de lecture.

En conclusion

Dans cet article, nous venons d’aborder le changement de paradigme qu’il faut opérer lors de la modélisation du schéma d’une base de données NoSQL. La norme n’est plus de partir des structures de données qu’on normalise (pour éviter les duplications de l’information) puis de construire les requêtes. Désormais, c’est plutôt l’inverse : ce sont les requêtes, les cas d’utilisation et les besoins en temps de réponse qui nous dictent la construction des structures de données. Encore une fois, vous l’aurez remarqué, on vient d’assister à un bel exemple de retour vers le passé comme l’informatique sait si bien le faire.

Share
Salaheddine BABOUCHE
Salaheddine BABOUCHE

8826

Comments

  1. Bonjour,

    Merci pour cet article court mais précis qui illustre bien les différences entre les 2 philosophies.
    Juste deux petites coquilles linguistiques dans le texte : écrire plutôt “d’abandon” et non “d’abondant”, “une ligne d’une table relationnelle correspond un” : ici il manque un “à”

    J’aurai une question, utilisez-vous un logiciel de modélisation spécifique au NoSQL ? Si oui, lequel ?
    Merci d’avance

    Cordialement,
    Stéphane

    • “J’aurai une question, utilisez-vous un logiciel de modélisation spécifique au NoSQL ? Si oui, lequel ?”
      j’ai entrain d’utiliser comme SGBD le mongodb et comme shell robomongo

  2. Salaheddine BABOUCHE Salaheddine BABOUCHE Says: February 22, 2016 at 10:10 am

    A ma connaissance, il n’existe pas de logiciel gratuit assez poussé pour modéliser une base MongoDB. Vous pouvez trouver une partie des outils payants sur la page de Référencement MongoDB.

  3. Dans le premier exemple, ‘pseudo’:’10 rue du test’ , le nom du champ est “rue” et non “pseudo”.

  4. Bonsoir,

    Quel est l’équivalent de ON DELETE/UPDATE CASCADE en MongoDB pour des relations de type 1:N et N:N ?

Leave a Reply

Your email address will not be published. Required fields are marked *