Cela fait maintenant quelques temps que je donne plus de nouvelles, plus un signe de technologie, de recherche. Et pourtant, de la recherche, il y en a eu ! Après avoir passé une longue période à essayer les différents outils de QA dédiés au web, j’ai passé ces derniers mois à essayer – et exploiter – les NoSQL. La littérature est déjà bien large sur le sujet dans ses généralités. Cassandra, HBase, Voldemort, Redis… tout y passe, du plus ancien dépôt clé/valeur au plus évolué système orienté graphe ou document. Je vais parler ici finalement de MongoDB, que j’ai pu torturer en long, en large et en travers, et qui appartient justement à la catégorie des NoSQL orienté document.

Un NoSQL, pourquoi ?

Certainement pas par effet de mode. Une prise de décision basée sur ce critère ne serait que folie. Par besoin ? Il va être temps de définir ces besoins. Car on assiste à bon nombre de projets qui tendent à délaisser ces bons vieux SGBDR au profit de leurs cousins non-relationnels. Or, la plupart de ces projets ont – selon moi - surtout un problème de conception et non d’outils. Si ces projets reprochent à MySQL une certaine lenteur, ils feraient bien mieux d’apprendre à tirer profit d’une configuration optimale, et d’une conception sérieuse du modèle de données, avec une stratégie d’indexation adaptée. On ne le dira jamais assez : des bases comme MySQL, PostgreSQL ou autre ont perduré pendant des années. La réplication est fonctionelle. Le partitionnement est possible. Les plus gros l’ont utilisé et continuent à l’utiliser. Twitter avoue même rester sur MySQL après avoir essayé timidement de mettre en place Cassandra. Non, pour moi, une des raison qui peut pousser à envisager une solution NoSQL est ailleurs. La grosse plus value de ces solutions reste toujours leur très bonne disposition à « scaler ». Autrement dit, si on souhaite absorber un déluge de données croissant, on y trouvera un allié puissant pour rapidement doubler, quadrupler la puissance de stockage, sans se lancer dans une trop lourde configuration du partitionnement et/ou de la réplication.

Orienté document, pourquoi ?

Comme d’habitude, nuançons ce point de vue par un autre apport, mais celui-ci est propre au modèle de stockage choisi. On en dénombre 4 :

• dépôts clé/valeur (Voldemort, Redis…)
• orientés colonne (Cassandra, HBase…)
• orientés documents (CouchDB, MongoDB…)
• orientés graphes (Neo4J…)

Chaque modèle répond à des problématiques et stratégies de stockage différentes. MongoDB stocke des « documents ». Un document est un ensemble de paires clé/valeurs, ici décrites au format BSon. Ce format est largement comparable au JSon, modulo quelques types additionnels.

{
blog: http://www.zt.com,
authors: [adrien, robot],
comments:
[
{ author: robert, age: 42 },
{ author: johanna, age: 25 }
]
}


Voolà donc typiquement ce qui peut être stocké dans une collection (= table) MongoDB. Ce stockage est dit « schemaless », traduire par « sans schéma ». Les documents ne correspondent à aucune définition formelle qui aurait été préalablement définie. Ainsi, on pourrait très bien rajouter un autre document « blog » similaire à l’exemple, mais sans champs « authors » et avec une colonne « keywords ». le NewYorkTimes tire partie de ce modèle avec MongoDB en permettant à ses contributeurs d’ajouter des méta-données à la volée pour chaque photo soumise. En effet, on ne retrouve pas forcément les même méta-données entre une photo de lieu et celle d’une star. Certes, la chose reste largement faisable avec les outils actuels. Le modèle document est juste extrémement adapté à ce type de stockage, sans s’occuper d’un modèle relationnel et ses multiples contraintes. Je sais, je viens de donner un argument qui pourrait remettre en cause le premier : certains NoSQL ont un rôle qui dépasse de loin celui d’un entrepôt extensible et redondé.

MongoDB, pourquoi ?

Voyons maintenant le cas particulier de MongoDB. C’est un NoSQL orienté documents, qui se qualifie par l’acronyme « CP » du théorème de CAP.

1) Langage de requêtage intuitif

Tout naturellement, lorsqu’on essaye un système de stockage, nos premiers essais se tournent vers l’insertion et la récupération de données. Pour l’insertion, nous venons de voir qu’elle s’effectuait au format BSon. Concretement, après avoir lancé le shell MongoDB, la commande suivante effectuerait une insertion dans une collection  »test » :

db.test.insert({« name »: « Adrien »});

Et pour requêter nos collections, cela s’effectue également tout naturellement au format BSon ! MongoDB fournit un certain nombre d’opérateurs classiques : >, <, =, >=, IN, NOT IN, etc. Quelques exemples :

# Tous les utilisateurs "toto"
db.test.find({"name": "toto"});

# Les 3 premiers "Adrien", ayant plus de 23 ans, triés
db.test.find({"name": "Adrien", "age": {$gt: 23}}.sort({"age": -1}).limit(3);

C’est en général le premier point qui ressort de MongoDB par rapport à la plupart de ses rivaux. Son système de requêtage séduisant permet une prise en main extrémement rapide.

2) Auto-sharding

Venons en maintenant à ce qui fait normalement tout l’attrait des NoSQL : leur forte extensibilité et leur mécanisme de réplication. MongoDB offre des possibilités de sharding (partitionnement) afin de distribuer les données au sein de plusieurs  »shards » (bloc venant constituer le cluster, et ne possédant qu’une partie des données). L’auto-sharding reste aujourd’hui (version 1.5.3) en version beta, mais il est possible tout de même de spécifier ses propres pattern de sharding. Par exemple, on peut décider que le champs « name » de nos exemple deviendra une clé de sharding. Il est possible, à l’instar des indexes, de spécifier des clés composées de plusieurs champs. MongoDB calculera un hash de ces clés pour déterminer sur quel shard envoyer tel ou tel document. La configuration du cluster et toutes ses méta-données sont stockées au sein de « serveurs de configuration ». En production, trois serveurs de ce type sont normalement configurés. Si un de ces serveurs tombe en rade, le système continue de fonctionner normalement. Si deux de ces 3 serveurs montrent un dysfonctionnement, le dernier serveur de configuration devient accessible en lecture seulement. Ceci n’empêche pas le cluster complet de fonctionner, mais empêche toute modification de la configuration, et tout déplacement de « chunks » (position des blocs de données, qui est elle aussi stockée dans ces serveurs de configuration).

3) Replica pair, replica sets

Chaque shard peut actuellement être redondé par ce qu’on appelle un système de  »replica pair » : le shard est constitué d’un master et d’un slave. À tout moment, si le master tombe en panne, le slave prend le relai. Les données peuvent être répliquées instantanément ou avec une certaines latence dans le cas d’un système dit « finalement consistant ». Cette paire est bien limitée actuellement en matière de fail-over et laissera place aux « replica sets » avec MongoDB 1.6, qui laissera la possibilité de plus de 2 serveurs de sauvegarde. Dans cette nouvelle situation, en cas de panne du master, l’élection du slave qui deviendra master se fera par la résolution d’un consensus basé sur la disponibilité de chaque noeud, le nombre de serveurs vus par chacun, etc…

4) Map/Reduce

L’algorithme Map/Reduce a le vent en poupe depuis les papiers Google et l’implémentation Hadoop. Et devinez quoi ? MongoDB, à l’instar de CouchDB, offre des possibilités d’interrogation en Map/Reduce. Dans un environnement « shardé », les requêtes sont en effet ciblées ou globales (parallèles ou séquentielles). Pour effecter un certain nombre de calculs efficacement, MongoDB permet l’écriture de fonctions map() et  reduce() – et finalize() – en javascript. Les résultats peuvent être stockées dans des collections temporaires pour conserver un cache des résultats.

5) Autres fonctionnalités

En fait, il y a trop de choses à raconter sur MongoDB. Je vais faire un bon petit lot de petits articles pour détailler chaque point, mais pour ce soir, il faudra se contenter d’une découverte rapide :

• Un moteur d’indexation géographique, que Foursquare utilise à outrance
• Une indexation en background
• Des capped-collections, collections de tailles fixes auto-gérées pour ne conserver que les X derniers éléments insérés (fonctionnement par TTL prévu pour les futures versions)
• Profiling des requêtes
• Interface REST

Conclusion

MongoDB est la solution qui actuellement suscite le plus ma curiosité, et surtout mon intérêt, tant pour ses performances que pour sa conception et ses fonctionnalités. Son plus gros défaut actuel est sa grande jeunesse. Gageons qu’une fois l’auto-sharding et les replica-sets 100% fonctionnels, 10 Gen Confluence arrivera à mettre en place une architecture composée de 1000 shards, son objectif actuel.