.
I. 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, alors deux solutions sont envisageables.
- Soit augmenter les ressources de la machine (la puissance du processeur, la mémoire, etc.) : c'est ce que l'on appelle une scalabilité verticale, mais cette solution a 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.
- Soit 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 que l'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, transactions, jointures et propriétés ACID handicapent les temps de réponse. C'est suite à ce constat que les bases de données NoSQL ont émergé, ces bases se caractérisant par l'abandon 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.
II. Qu'est-ce que la dénormalisation ?▲
Dans 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 de jointures 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) sachant que les mêmes principes s'appliquent aussi sur les autres types de bases NoSQL.
Dans une base NoSQL orientée 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êmes d'autres documents imbriqués.
Il existe trois grandes stratégies de dénormalisation des données.
II-A. 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 et l'on a toutes les requêtes qui concernent le document parent et les données du document imbriqué (ex. imbrication de l'adresse dans le document du client).
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
{
'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 veut pouvoir modifier des documents parents et enfants d'une manière atomique, souvent les bases de données NoSQL permettent la modification atomique d'un document. Cependant, l'imbrication de document n'est pas possible si l'on veut créer le document enfant avant le document parent.
II-B. 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 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 pseudonyme et sa photographie. C'est seulement en cliquant sur son profil qu'il accédera à des informations complémentaires.
II-C. 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 côté 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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
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.
III. 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.
IV. Remerciements▲
Cet article a été publié avec l'aimable autorisation de la société PaloITPaloIT.
Nous tenons à remercier milkoseck pour sa relecture orthographique attentive de cet article et Mickaël Baron pour la mise au gabarit.