La base de données orientée documents est une évolution de la base de données clé-valeur telle que précédemment présentée. Ici chaque clé n’est plus associée à une valeur sous forme de bloc binaire mais à un document dont la structure reste libre.
Les applications effectuent majoritairement des requêtes en lecture par identifiant ; ce constat a conduit au développement des bases de données clé-valeur. Les applications Web diffusent des pages entières résultant d’un ensemble de jointures en base : les bases de données orientées documents découlent de ce second constat.

Au-delà de ce cas d’utilisation, la modélisation des données sous forme de documents permet également de stocker de manière idéale toute forme de structure de données non plane, c’est-à-dire qui nécessiterait en ensemble de jointures en logique relationnelle. Malgré tout, il ne s’agit nullement d’un rejet des bases de données relationnelles : la modélisation en document ne permet pas la même flexibilité dans les requêtes et les chargements de données que la modélisation relationnelle.

Mathias Stearn a présenté ces concepts en action avec MongoDB, l’une des deux bases de données orientées documents actuelles, l’autre étant CouchDB. Mathias Stearn travaille actuellement pour 10gen, l’entreprise derrière MongoDB.

Les bases de données orientées documents

Du clé-valeur au document

Pour passer de la représentation clé-valeur à la représentation en document, il s’agit principalement de rendre la base de données consciente de la structure de la valeur qu’elle stocke. Elle sera ainsi à même d’offrir un certain nombre de fonctionnalités qui ne peuvent être accessibles avec une base de données clé-valeur :

• Ajout, modification, lecture ou suppression de seulement certains champs dans un document
• Indexation de champs de document permettant ainsi un accès rapide sans avoir recours uniquement à la clé
• Requêtes élaborées pouvant inclure des prédicats sur les champs

Ce sont ces possibilités supplémentaires qui seront déterminantes lors du choix entre ces deux technologies de persistance pour un projet.

Les cas d’utilisation courants

Par intention initiale ou par expérience à l’usage, plusieurs cas d’utilisation s’avèrent particulièrement adaptés au stockage dans une base de données orientée documents :

• Persistance de profils utilisateurs, de regroupement de contenus destinés à une même page, de données de sessions.
• Cache d’informations sous une forme structurée.
• Stockage de volumes très importants de données pour lesquelles la modélisation relationnelle aurait entraînée une limitation des possibilités de partitionnement et de réplication.

Modélisation des données

La modélisation de données sous forme de documents est familière des développeurs depuis de nombreuses années du fait du succès qu’a connu le format XML dans les entreprises.
L’intérêt qu’ils représente pour le stockage dans une base de donnée par rapport à de simples tables est que leur structure hiérarchique leur permet de représenter les relations one-to-one et one-to-many. Ainsi un document pourra être sauvegardé et chargé sans aucun traitement de jointure.

MongoDB

Tour d’horizon de MongoDB

MongoDB est une base de données orientée documents qui connaît un succès croissant depuis plusieurs mois. Ses spécificités face à CouchDB sont :

• Implémentation en C++ et utilisation de BSON (dérivé de JSON en binaire créé pour MongoDB) pour le transport et le stockage des documents.
• Performances remarquables, notamment lors d’insertions en masses grâce à un la présence d’un mode batch (on parle de 100.000 insertions/s sur un PC de bureau standard).
• Outre le gain de performance, l’utilisation de BSON pour le transport signifie qu’un protocole non standard est utilisé, un drivers est donc requis. Il en existe pour tous les langages courants.

Ainsi CouchDB présente une architecture baignée dans le monde du Web, avec une exposition des ressources de la base en REST, tandis que MongoDB a fait des choix de design résolument orientés vers la performance.

Enfin, MongoDB offre un certain nombre de fonctionnalités intéressantes :

• Possibilité d’écrire des scripts MapReduce en JavaScript afin d’effectuer des traitements sur un grand volume de données.
• Gestion des requêtes géographiques. 10gen souhaite positionner MongoDB face à PostGIS sur ce créneau, en mettant en avant une plus grande facilité d’utilisation que l’extension de PostgreSQL.
• Capacité de réplication et de partitionnement sur plusieurs instances.

Premiers pas avec MongoDB

Dans MongoDB les documents sont stockés dans une collection. Un ensemble de collections forme une database. Ce découpage permet l’organisation des données à l’image des tables et des schémas dans le monde relationnel.

Un moyen simple d’essayer MongoDB rapidement est le MongoDB Shell en ligne disponible à cette adresse : http://try.mongodb.org/. Pour aller plus loin il sera nécessaire de télécharger puis d’installer et de lancer une instance MongoDB.

Pour le développeur Java, les premiers pas se feront par l’intermédiaire du driver Java pour MongoDB. Ce driver peut être intégré au projet grâce à Maven depuis le repository central :

<dependency>
   <groupId>org.mongodb</groupId>
   <artifactId>mongo-java-driver</artifactId>
   <version>1.4</version>
</dependency>

Les interactions de base avec MongoDB sont triviales :

Mongo m = new Mongo("localhost", 27017);
DB db = m.getDB("mydb");
DBCollection coll = db.getCollection("testCollection")
BasicDBObject doc = new BasicDBObject();
doc.put("name", "NoSQL Europe");
doc.put("type", "Conference");
doc.put("attendees", 100);
coll.insert(doc);
// Affiche le nombre de documents dans la collection
System.out.println(coll.getCount());

Les requêtes peuvent alors se faire via l’API du driver en construisant des requêtes avec des BasicDBObject comme pour l’insertion de documents :

// Définition d'une requête portant sur tous les documents avec attendees > 80
BasicDBObject query = new BasicDBObject();
query.put("attendees", new BasicDBObject("$gt", 80));
DBCursor cur = coll.find(query);
while(cur.hasNext()) {
   System.out.println(cur.next());
}
// Une requête portant sur les documents avec 20 < attendees <= 100
query = new BasicDBObject();
query.put("attendees", new BasicDBObject("$gt", 20).append("$lte", 100));
DBCursor cur = coll.find(query);
while(cur.hasNext()) {
   System.out.println(cur.next());
}

Réplication et sharding avec MongoDB

La fonctionnalité de sharding sera production-ready dans MongoDB 1.6, prévu pour Juillet 2010. Le partitionnement et le redimensionnement des partitions seront pris en charge automatiquement.

La réplication est quant à elle dors et déjà disponible. L’architecture mise en œuvre et de type master-slave dans laquelle seul le master est responsable des écritures. Il ne s’agit donc pas d’une structure pair à pair comme offre Cassandra ou Riak.

Il est intéressant d’observer que MongoDB ne met pas particulièrement en avant son fonctionnement distribué, s’appuyant simplement sur la réplication pour assurer la haute disponibilité et la répartition de la charge. En effet, le projet affiche de bonnes performances et une bonne tenue à la montée en volume de données. Ainsi,
Mathias Stearn parle d’un déploiement MongoDB en production qui assurerait le stockage de quelques 12 To de données, il s’agirait toutefois de documents de grosse taille.

Conclusion

Malgré son jeune âge, MongoDB brille par ses fonctionnalités et ses performances. Dans la mesure où la modélisation en document est peu contraignante et correspond à de nombreux cas d’utilisation, il est probable que l’on voit les déploiements de cette base de données se multiplier dans les mois à venir, notamment dans le monde du Web. Le prochain article abordera une évolution différente, et moins naturelle, du paradigme clé-valeur que sont les bases de données orientées colonnes.