Ch’mongoDB

Eh ouais, hier soir, c’était chtijug sur MongoDB avec Tugdual Grall.

Mais avant, minute copinage …

Le chtijug a la chance d’avoir un nouveau sponsor, et ça, c’est cool (d’autant plus que ce sont mes voisins de bureau jusqu’à ce soir) :

IMG_20141217_185256[1]

Le représentant d’Onyme a peut-être un moins chouette polo que certains précédents sponsors, mais un sacrément chouette discours

Et je me suis laissé dire qu’ils recrutaient

Bref, merci les gens !

Revenons-en donc à Tugdual

IMG_20141217_185548[1]

Oracle, eXo, Couchbase, MongoDB … clairement, le développeur un peu âgé a souvent touché à plein de trucs

Même fatigué, c’est un speaker sacrément rodé qui nous a fait une présentation intéressante, bourrée de live-coding, sur MongoDB.

Alors MongoDB, qu’est-ce que c’est ?

IMG_20141217_190640[1]

Mongo, une base agile, flexible, intituive et stockant les données dans un format facile à exploiter

En gros, c’est une espèce de gros système de stockage de BSON (un format binaire adaptant le JSON) disposant d’interfaces dans les différents langages … mais ça n’est pas ce que racontait vraiment ce slide moche.

Non. Ce que voulait expliquer Tugdual, c’est que les bases de données relationelles datent de 40 ans, à une époque où l’esapce disque coûtait vraiment cher. Et donc à cette époque, l’optimisation la plus importante concernait l’utilisation du disque. D’où les bases relationenlles où la donnée est forcément unique, et en troisième forme normale.

C’est pratique pour les DBA, parce que la donnée est bien structurée.

C’est en revanche infernal pour le développeur, puisque la donnée n’est pas accessible facilement. Ce qui explique, par exemple, l’intérêt pour les outils de mapping objet-relationnel.

Un autre inconvénient du fait qu’une écriture se fasse à de multiples endroits, c’est que l’écriture nécessite d’être encapsulée dans une transaction, qui est lourde en termes de ressources pour le serveur (et donc impactant l’ensemble des clients).

A l’opposé, MongoDB cherche à être une base de stockage agréable pour les développeurs.

Ca veut dire quoi ?

  • MongoDB stocke des documents en JSON, qui peuvent contenir des champs simples ou des tableaux de tableaux de tableaux (avec toutefois des limites … qui me semblent assez difficiles à atteindre à première vue).
  • Si deux documents doivent contenir chacun la même donnée, il peut être plus simple de dupliquer cette donnée … ou de la référencer (mais dans ce cas, c’est le développeur qui gèrera l’unicité du lien)
  • Du coup, comme le document est complet, il n’y a pas vraiment besoin de transactions : soit il est écrit, soit il ne l’est pas, mais le développeur le sait tout de suite. Donc MongoDB est non transactionnel, et ça n’est pas grave.

Et paf, Tugdual enchaîne sur une démonstration de la « convivialité » du shell mongo.

insertion d'un document dans la collection "customers", et récupération de la liste des "customers"

insertion d’un document dans la collection « customers », et récupération de la liste des « customers »

Et là, c’est le drame : comme le shell Mongo n’offre ni complétion, ni mise en valeur de la syntaxe, et que Tugdual était un peu fatigué (mais ça, je comprends, parce que coder à l’heure de l’apéro, c’est loin d’être facile), les accolades oubliées s’enchaînent en rafale

Ami lecteur, trouve l'accolade manquante ... Ouaip, c'est lioin d'être facile

Ami lecteur, trouve l’accolade manquante … Ouaip, c’est lioin d’être facile

Notez que je ne critique pas Tugdual, mais le shell mongo. Peut-être qu’un outil comme Robomongo, mongodb-shell ou même l’un des innombrables plugins Eclipse aurait pu lui faciliter la vie. Mais je comprend qu’en tant qu’évangéliste Mongo, ça lui soit un peu difficile d’utiliser des outils tiers.

Bref. Après l’insertion, une autre chose intéressante : la seule chose que doivent avoir les documents Mongo, c’est un attribut « _id » qui peut être soit généré (à partir de l’adresse Mac, du numéro de process, et du timestamp unix), soit écrit manuellement. Et il se passe quoi quand un utilisateur essayé de créer un nouveau document avec un _id déja utilisé ?

Si j'essaye d'avoir deux documents avec le même _id, j'ai droit à une jolie erreur

Si j’essaye d’avoir deux documents avec le même _id, j’ai droit à une jolie erreur

Bon, maintenant que j’ai bourré la base, il est temps d’y chercher des trucs.

Et là, franchement, pour moi, c’est le moment du malaise.

Parce qu’autant je veux bien comprendre l’intérêt des documents en JSOn, des réponses du serveur en JSON mais quand Tugdual a fait ses query/update avec du JSON pour

  • rechercher les documents à mettre à jour
  • définir les opérations d’altération à effectuer (modification, suppression, insertion)

Je dois avouer que j’ai eu comme un malaise

Regardez donc :

Une opération simple de recherche et mise à jour, avec un paquet de JSON dedans

Une opération simple de recherche et mise à jour, avec un paquet de JSON dedans

Et si ça ne vous paraît pas assez clair il y a évidement de la doc sur internet.

Je vais quand même essayer de clarifier mon malaise : il me semble que tous les paramètres de toutes les opérations sur une base MongoDB sont passés sous forme de JSON. Et c’est quelque part assez bien.

Toutefois, tenter d’exprimer une recherche et une mise à jour sous cette forme paraît assez bizarre, surtout vu quelques choix faits (et présentés ici)

  • Les opérations de MongoDB sont définis dans les paramètres sous forme d’attributs JSON préfixés par « $ » alors n’allez pas utiliser ce caractère magique dans vos données !
  • Si vous cherchez au fond d’un sous-document, il faudra passer votre chemin de recherche dans une chaîne (parce que « . » n’est pas accepté comme clé dans un hash JSON). Du coup vous aurez certaines clés avec des guillemets autour et d’autres sans. Et vous vous demanderez d’où vient l’inconsistence.
  • Si vous cherchez dans un tableau une valeur ayant plusieurs propriétés, ce sera … un peu plus compliqué.

Bref, je peux le reconnaître, je n’ai pas aimé cette syntaxe, bien qu’elle soit extrêmement déclarative.

Bon, une fois arrivés là, il est temps de sortir du shell et de passer au driver Java, qui se présente sous plusieurs formes (au passage, il y a des tonnes de drivers, listés dans une très belle page – dixit Tugdual) :

  • Un driver basique qui vous fait manipuler des DBObject qui sont en fait une vision javaisée et fluente des documents JSON. Au apssage, ce driver fournit un chouette outil de création de requête : QueryBuilder.
  • Morphia, qui est un ODM qu’on pourrait considérer comme un concurrent d’Hibernate OGM ou de Spring Data, mais spécifiquement conçu pour MongoDB.
  • MongoJack qui utilise les annotations de Jackson pour mapper les objets Java sur les documents JSON.

Petite parenthèse : le style Dracula d’Intellij ne m’a paru super lisible …

Et pourtant j'étais au deuxième rang ...

Et pourtant j’étais au deuxième rang …

Une fois ces différents outils présentés, Tugdual nous explique, à travers un exemple d’application web, comment utiliser tout ça au mieux.

D’après lui, et plus j’y pense, plus j’approuve, la meilleure solution et d’utiliser le driver basique pour les lectures, et les mappers pour les écritures. Et la raison est assez simple :

En lecture, on passe le JSON de Mongo jusqu’au client … typiquement écrit en Javascript, et donc parfaitement capable de lire ce Javascript.

En revanche, en écriture, pour contrôler ce qui est écrit dans la base, on a intérêt à passer par un mapper. MongoJack a ma préférence … surtout que, contrairement à Tugdual, je sais lui faire ignorer les propriétés inconnues (en utilisant par exemple la DeserializationConfig).

Une fois ce tour du dev fait, Tug est passé au clustering … Bon, là, c’est assez classique : il y a du sharding, de la haute disponibilité via l’élection automatique d’un master … La routine, en quelque sorte.

Et il était déja l’heure du …

Ouaip, Onyme sait toujours aussi bien recevoir !

Et alors, est-ce que je vais passer à MongoDB ?

Bon, j’ai failli il y a peu travailler sur une application utilisant massivement du MDM. Et MongoDB faisait partie des systèmes de stockage candidats.

Je dois bien reconnaître que cette présentation m’a appris pas mal de choses vraiment chouettes sur cette base. Et je comprend bien les cas d’utilisation présentés par Tugdual :

  • Vision 360° d’un client pour, par exemple, du support
  • Aggrégation de données provenant de façon assynchrone de plusieurs systèmes de gestion de données

Bref, la construction de rapports et leur utilisation dans des applications architecturés autour de concepts proches de CQRS paraît facile avec MongoDB.

En revanche, ce qui me paraît beaucoup plus compliqué, c’est la construction de données historisées « sans fin » (à cause par exemple de la limite dans la taille des documents).

Et puis, après avoir bossé sur des bases graphes, je dois bien reconnaître que je reste très attaché au graphe, c’est-à-dire à la création, et à la gestion de cohérence de ces liens par le système. Or c’est précisément le sujet que MongoDB ne veut pas adresser (et je les comprend, parce que ça simplifie bien des choses).

Cela étant, c’était une sacrément chouette session. Merci au chtijug !

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s