Bases NoSQL et MongoDB

Apparu dans les années 1970, le modèle relationnel des bases de données est aujourd’hui le plus commun. Après l’échec des SGBD objets dans les années 90 – 2000, un autre type de base de données émerge et est de plus en plus utilisé notamment par des sociétés qui doivent gérer de très gros volumes de données (Google, Facebook …). Il s’agit des bases de données NoSQL.

Cet article commence par décrire le modèle NoSQL pour ensuite le comparer au modèle relationnel. Enfin, le Système de Gestion de Bases de Données (SGBD) NoSQL MongoDB[1] sera présenté.

Quelques mots sur le NoSQL

Le terme NoSQL (acronyme de Not Only SQL) désigne une famille de SGBD fonctionnant sur un modèle particulier. Ces logiciels sont indépendants du langage SQL et sont donc foncièrement différents des logiciels de bases relationnelles. Ce terme a été utilisé pour la première fois en 1998. C’est à ce moment là que de grands acteurs informatiques se sont rendu compte que les SGBD relationnels classiques n’étaient pas adaptés pour un très gros volume de données. Les temps de réponses étaient trop élevés et la distribution des données trop lourde et trop complexe.

Avec l’apparition de nouveaux principes de stockage, de nouveaux modèles ont été développés. On retrouve principalement les quatre modèles suivants :

Le modèle « Clé/valeur »

Le principe de ce modèle est d’associer un identifiant unique à chaque valeur dans la base de données. Une valeur peut aussi bien être de type simple qu’être un objet sérialisé.

Les SGBD qui fonctionnent de cette manière fournissent en général uniquement les quatre opérations basiques : création, lecture, modification, suppression. Toute l’intelligence dans la récupération des données se situe donc dans l’applicatif client.

Le modèle Base Documentaire

Dans ce modèle, chaque entrée est appelée « document ». Un document est un ensemble de champs qui possèdent chacun une valeur. Parmi ces champs se trouve un identifiant unique rajouté par le SGBD. Il est intéressant de noter que la valeur d’un champ peut, à son tour, être un document. Un ensemble de documents est appelé une collection (équivalent des tables en relationnel). Voici quelques exemples de documents écrit en JSON (JavaScript Object Notation) :

 {id : « 1 », nom : « Guitare », materiau : « Bois »}
{id : « 2 », nom : « Batterie », categorie : « Bruyant », accessoire : « Baguettes »}

1 2	{id : « 1 », nom : « Guitare », materiau : « Bois »} {id : « 2 », nom : « Batterie », categorie : « Bruyant », accessoire : « Baguettes »}

Ces documents peuvent tout deux appartenir à la même collection. En effet, le modèle de base documentaire n’impose pas aux documents d’une collection d’avoir une structure stricte à respecter. Il s’agit même de l’inverse puisque la collection est créée après insertion du premier document. Cela rend les modifications dites « de structure » plus simples à réaliser.

Le modèle Base Orientée Colonnes

Alors que le modèle relationnel stocke les informations sous forme de lignes, ce modèle-ci stocke les informations sous forme de colonnes. Voici quelques tuples que l’on peut retrouver dans une base de modèle relationnel classique :

1, Guitare, Flamenco
2, Piano, Classique
3, Flute, Irlandais

1, Guitare, Flamenco

2, Piano, Classique

3, Flute, Irlandais

Ces tuples seraient agencés de la manière suivante dans une base orientée colonnes :

 1, 2, 3
Guitare, Piano, Flute
Flamenco, Classique, Irlandais

1, 2, 3

Guitare, Piano, Flute

Flamenco, Classique, Irlandais

Ce modèle permet donc d’ajouter très facilement des informations et limite les valeurs nulles.

Le modèle Graphes

Ce dernier modèle est le moins connu et sans doute le plus complexe des quatre. Il se base sur un modèle mathématique appelé « Théorie des Graphes ». Dans ce modèle, les données sont modélisées sous forme de « Nœud » dont la structure est sensiblement identique à celle des documents vus précédemment. Ces données sont reliées entre elles par des « Arc » orientés et nommés. La figure suivante montre un exemple de données stockées dans une base sur le modèle des graphes :

Figure 1 : exemple de stockage avec le modèle Graphes

Après cette présentation des principes de fonctionnement des systèmes NoSQL, nous allons nous intéresser aux différences entre les SGBD NoSQL et les SGBD relationnels.

Comparaison NoSQL / SGBDR

Pour chaque type de système, une liste de points forts et de points faibles est présentée.

Tout d’abord, intéressons-nous aux SGBD de type relationnel :

Les points forts :

Beaucoup de fonctionnalités et de règles pour garantir des bases cohérentes et complètes : mécanisme de verrous pour la gestion des accès concurrentiels, respect des propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité).
Utilisation des outils spécialisés comme le modèle entité-relation qui est le Modèle Conceptuel de Données (MCD) utilisé pour modéliser la structure de la base.

Les points faibles :

Performances qui déclinent avec l’augmentation du volume de données
Problématique de distribution des données d’une base.

Concernant les SGBD de type NoSQL, les points forts et faibles sont globalement inversés :

Les points forts :

Bons temps de réponse malgré de très gros volumes de données
Facilement distribuable
Plus flexible en cas de panne (disponibilité partielle voire totale)

Les points faibles :

Moins de propriétés garantissant un état cohérent de la base. Conformément au théorème de Brewer (aussi appelé théorème du CAP), seules deux des trois propriétés suivantes peuvent êtres respectées par un SGBD NoSQL : Cohérence, Disponibilité et Résistance au morcellement
Pas de mécanismes de jointures, le côté client doit pallier à ce problème.
Il est rare qu’un SGBD de type NoSQL implémente un mécanisme de verrous pour garantir la cohérence pendant des accès concurrents.

Zoom sur un SGBD NoSQL : MongoDB

Historique

MongoDB est un SGBD NoSQL open source (licence AGPL V3.0) écrit en C++ qui stocke ses données en BSON (Binary JSON). Son développement à commencé en 2007 et a été initié par la société 10gen. Ce SGBD a été créé dans le but de fournir un compromis entre les bases de données clé/valeur qui sont très facilement distribuables et les bases relationnelles classiques. Aujourd’hui, 10gen est toujours le principal acteur dans le développement et la maintenance de MongoDB.

Présence sur le marché

En terme de marché, MongoDB est utilisé par des grands comptes comme MTV, Disney, Doodle ou encore le CERN (Organisation Européenne pour la Recherche Nucléaire) pour les données concernant l’accélérateur de particules.

Principes de fonctionnement

MongoDB utilise le modèle de base documentaire pour stocker les informations. Il présente des pilotes pour la plupart des langages communément utilisés aujourd’hui (C, C++, C#, PHP, Java, Python …).

La partie serveur de MongoDB se présente sous la forme d’un démon (ou service sous Windows). Pour le côté client, il existe un mode terminal mais aussi différentes surcouches graphiques (phpMoAdmin, MongoHub …).

Le requêtage se fait avec une syntaxe comparable au javascript et MongoDB renvoie les données en JSON.

Quelques exemples de requêtes

La syntaxe d’une commande est simple et se décompose de la manière suivante :

db.nomCollection.nomFonction()

1	db.nomCollection.nomFonction()

Par exemple, pour récupérer les éléments dans la collection « voitures », la ligne suivante est écrite :

db.voitures.find()

1	db.voitures.find()

L’exemple de requête suivant permet de récupérer le nom et le prénom des utilisateurs féminins dans une base de type relationnel :

SELECT nom, prenom FROM utilisateur WHERE genre = ‘F’;

1	SELECT nom, prenom FROM utilisateur WHERE genre = ‘F’;

Un équivalent de cette requête pour le SGBD MongoDB est :

db.utilisateur.find({genre : « F »}, {nom : 1, prenom : 1})

1	db.utilisateur.find({genre : « F »}, {nom : 1, prenom : 1})

La seconde liste en paramètre de l’appel de la méthode ‘find’ permet de définir les attributs qui doivent être affichés ou non. Le chiffre ‘0’ permet de bloquer l’affichage de l’attribut alors qu’un nombre positif (dans notre exemple ‘1’) permet d’autoriser l’affichage.

La requête suivante récupère les données de la voiture de monsieur « Jacques Dupont » :

SELECT V.* FROM utilisateur U, voiture V WHERE U.id = V.id_possesseur
 AND U.nom = ‘Dupont’ AND U.prenom = ‘Jacques’;

1 2	SELECT V.* FROM utilisateur U, voiture V WHERE U.id = V.id_possesseur AND U.nom = ‘Dupont’ AND U.prenom = ‘Jacques’;

Un équivalent de cette requête pour le SGBD MongoDB est :

utilisateur_temp = db.utilisateur.findOne({nom : « Dupont », prenom : « Jacques »})
voiture = db.voiture.find({id_possesseur : utilisateur_temp.id})

1 2	utilisateur_temp = db.utilisateur.findOne({nom : « Dupont », prenom : « Jacques »}) voiture = db.voiture.find({id_possesseur : utilisateur_temp.id})

Cette façon d’utiliser les clés étrangères en deux temps est la manière recommandée par le site officiel de MongoDB[2].

Conclusion

De part ces différences avec les traditionnels modèles relationnel et objet, le modèle NoSQL représente une nouvelle catégorie de SGBD. Il ne s’agit pas de remplacer entièrement les bases relationnelles en bases NoSQL, il s’agit plutôt de fournir une solution alternative là ou les modèles en place montrent leurs limites. Certains projets font d’ailleurs cohabiter les deux types de systèmes au sein d’une même application, permettant ainsi de bénéficier des avantages de chacun.

Il est possible de retrouver l’intégralité de cet article dans le numéro 154 du mois de Juillet 2012 du magazine « Programmez ».

Sources :
[1] Site officiel de MongoDB : http://www.mongodb.org/
[2] Page concernant les références sur le site de MongoDB : http://www.mongodb.org/display/DOCS/Database+References

Par Jorrit