Publié par
Il y a 7 années · 5 minutes · Data

NoSQL Europe : Bases de données orientées documents et MongoDB


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 :


   org.mongodb
   mongo-java-driver
   1.4

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.

Michaël Figuière
Michaël est consultant chez Xebia où il intervient notamment sur des sites Web à fort trafic. A son aise tant avec les environnements JEE qu'avec les technologies de plus bas niveau, il est spécialisé dans les architectures distribuées et les technologies innovantes telles que NoSQL, les moteurs de recherche, ou encore le data mining.

5 réflexions au sujet de « NoSQL Europe : Bases de données orientées documents et MongoDB »

  1. Publié par Philippe Gauthier, Il y a 7 années

    @Xebia : J’aurais bien aimé en apprendre un peu plus sur les bases de données XML dans cet article.
    Le XML étant un format d’échange très répandu, ce genre de base de donnée semble idéal pour une db orienté document.
    Les performences sont-elles si désastreuses que ce genre de solution à été écarté?
    Tout avis est le bien venu.

  2. Publié par guillaume holler, Il y a 7 années

    par aillieurs, il existe un framework de mapping objet mongo a la hibernate annotations: morphia

    c est un projet google code et le couple morphia mongo est fantastique

  3. Publié par Michael Figuiere, Il y a 7 années

    @Philippe Gauthier : Désolé pour cette réponse tardive.
    En effet, si le concept de base de données XML était populaire au début des années 2000, lors de l’âge d’or du XML, l’expérience a montré que ce type de persistance souffrait de mauvaises performances et de lourdeurs à l’usage.
    Les bases de données orientées documents dont il est question ici partent d’un ensemble de principes d’ingénierie raisonnables qui laissent présager d’une meilleur longévité de cette technologie, mais comme toujours, seul l’avenir nous le dira :)

    @Guillaume Holler : Merci pour cette précision ! Cette solution de mapping présente en effet l’intérêt d’éviter d’avoir recours à la parfois verbeuse API du drivers de MongoDB.

    Michael Figuière (Xebia)

  4. Publié par joseph, Il y a 7 années

    Salut

    je viens de traduire un petit retour d’expérience sur mongoDb, plus par là: http://josephonit.wordpress.com/2010/07/02/hot-potato-infrastructure-mongodb/

    de façon plus générale, nous sommes en train d’utiliser mongo + morphia pour un projet et le couple est sympa. Toutefois morphia est clairement encore en élaboration et bouge beaucoup. Amateurs de stabilité et de build qui compilent, passez votre chemin ;)

    Sur le fond, l’impression est vraiment celle de développements plus aisés et d’un grand soulagement au niveau du mapping object/persistence. morphia est réellement POJO et pose peut de contraintes de ce coté là.

    Par contre, il faut remettre en cause ses habitudes de base de données normalisées et réfléchir aux documents qui conviennent le mieux, ce qui n’est pas toujours simple.

    au plaisir de vous lire à nouveau !
    ++
    joseph

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *