lundi 31 août 2015

MongoDB c'est bien , mais ...


Depuis quelques temps j'utilise mongoDB, une base de donnés NoSQL pour un projet personnel. Je ne suis pas un expert en BD mais je voulais quand même partager mon avis sur cet outil, dans l'espoir d'en apprendre certainement un peu plus encore via des retours de lecteurs...

Pourquoi mongoDB?

Tout d'abord je tiens a préciser que même si j'adore manipuler des concepts abstraits, j'ai en général une approche très pragmatique des choses. Le choix de mongoDB pour mon projet c'est donc fait sur ces critères, c'est tout :
  • C'est du NoSQL (et je voulais voir l'intérêt du NoSQL)
  • C'est un projet "mature"
J'avoue n'avoir pas fait plus d'étude de marché que ça, car de toutes façon je pense que c'est en utilisant une techno' qu'on se rend vraiment compte de ses qualités et défauts...

Pour faire quoi ?

Sans rentrer dans les détails de mon projets, je collecte des données sur Twitter. Voici quelques éléments pour se faire une idée de l'ordre de grandeur des données, collectées en 3 semaines :
  • 5,4 Millions de Tweets
  • 770 milliers de profils Twitter (ainsi que leur liste d'abonnements, c'est à dire de quelques centaines à quelques milliers d'identifiants de comptes pour chaque profil.)
Ça tourne sur un serveur de chez Online sous Ubuntu. (~16€/mois, cliquez sur le lien pour voir les spécifications du serveur.)

Les "plus" de mongoDB

Voici ce que j'ai apprécié dans l'utilisation de mongoBD:
  • C'est un projet mature , ce qui veux dire qu'on trouve plein de "driver" (moyen de se connecter à la base pour y mettre ou récupérer des données.). J'ai même trouvé un driver en Lua,  ;) c'est dire ....
    On trouve aussi un tas d'aide sur stack overflow, ou ailleur.
    En plus d'utiliser une BD locale, j'utilise aussi les services de mongoLab (DBaaS), qui sont franchement bien, et l'équipe support est géniale (ils m'ont super bien aidé!!).
  • C'est souple on peut tout modifier en cours de route, et les collections de données peuvent stocker des éléments hétérogènes. C'est une base sans schéma, cela veux dire qu'on est pas obligé de déclarer à l'avance le format des données. On peut stocker des nombre, des chaînes de caractères, et des tableau pouvant eux aussi contenir des éléments de ce type. Vous pouvez composer ces types à l'infini pour stocker vos données. Bref ce que vous mettez dans un JSON se transpose directement en mongoDB. C'est très simple , et puissant à la fois.
    C'est très appréciable quand on fait de la recherche et qu'on ne peut pas tout prévoir à l'avance.
  •  

Mais il y a aussi des "moins"

Tout n'est pas rose, et j'ai aussi bien galéré sur certains points:
  • Il n'y a pas, a proprement parler, de tri-aléatoire.Il peut être assez courant, quand on manipule beaucoup de donnes, de ne parfois qu'en prendre une petite partie, aléatoirement, on appelle cela de l'échantillonnage... Et bien bizarrement mongoDB ne fait pas cela! Même simplement demander à la BD de "trier" aléatoirement les données extraites grâce à une requête, ça n'existe pas. Cette dernière opération peut etre faite ailleur, mais cela oblige alors de d'abord charger toutes les données pour les mélanger ensuite: ce n'est pas très efficace...
  • Il n'y a pas de moyen simple de contrôler la mémoire (RAM) que consomme mongoDB. Dans la pratique ça peut etre assez gênant. J'aurai bien aimé pouvoir limiter la RAM utilisé, en acceptant bien sur une baise de performance. Ce qui fait que en pratique, il est conseillé de dédier entièrement un serveur à mongoDB. Sinon les autres applications risquent d'être "à l'étroit"...
  • Certaines opérations ne se font pas , et sans message d'erreur!
    Certaines fonctionnalité ne marchent pas, ... comme dans toutes les techno', mais il aurait été appréciable surtout pour une base de données, d'avoir un message d'erreur indiquant que l'opération n'a pas été faite.
  • Il y parfois des choix difficilement explicable. Voici un exemple...
    Il y a moyen de filtrer une requête par son type de donné (nombre , chaîne de caractère, etc...), c'est très utile puisque c'est une base sans schéma par conséquent un même champ peut parfois contenir un nombre ou une chaîne de caractère.  Par contre pour les tableaux (pouvant eux aussi contenir des éléments hétérogènes), la logique est telle qu'il est impossible de savoir si le type d'un champs est un tableau ou pas !! Par contre on peut savoir si le tableau contient un nombre ou une chaîne de caractère...
Tout ceci est une vue personnelle issue d'une expérience spécifique sur mon projet.

Voilà, en espérant que ces informations vous soit utiles dans le choix de la BD que vous utiliserez pour vos projets. N'hésitez pas à commenter si vous voulez partager votre experience avec mongoDB ou d'autres types de bases de données.