Le NoSQL, pour « not only SQL », désigne les bases de données qui ne sont pas fondées sur l’architecture classique des bases de données relationnelles. Développé à l’origine pour gérer du big data, l’utilisation de base de données NoSQL a explosée depuis quelques années. Mais qu’est-ce que réellement le NoSQL ?

Plusieurs espèces de NoSQL

Lorsque l’on parle de NoSQL, on regroupe des systèmes de base de données qui ne sont pas relationnels, mais il faut savoir qu’il existe plusieurs types de bases de données « NoSQL ».

• Les bases clef/valeur, permettent de stocker des informations sous forme d’un couple clef/valeur où la valeur peut être une chaine de caractère, un entier ou un objet sérialisé. Une base de données Redis. Ce type de base de données offre de très bonne performances par sa simplicité et peut même être utilisé pour stocker les sessions utilisateur ou le cache de votre site par exemple.
• Les bases orientées colonnes, ressemble aux bases de données relationnelles, car les données sont sauvegardées sous forme de ligne avec des colonnes, mais se distingue par le fait que le nombre de colonnes peut varier d’une ligne à l’autre. Les solutions les plus connues sont HBase ou Cassandra.
• Les bases orientées document, représente les informations sous forme d’objet XML ou JSON. L’avantage est de pouvoir récupérer simplement des informations structurées de manière hiérarchique. Les solutions les plus connues sont CouchDB, RavenDB et MongoDB.
• Les bases orientées graphe, présentent les données sous forme de noeud et de relation. Cette structure permet de récupérer simplement des relations complexes. Un exemple de base graphe est Neo4J.

Les performances

On lit assez souvent que les bases de données non relationnelles sont plus « performantes » et plus « scalable ».

Le problème des bases de données relationnelles est qu’elles sont difficiles à distribuer sur plusieurs serveurs forçant souvent à faire du « vertical scaling ». On augmente la puissance du serveur qui accueille la base de données afin d’obtenir de meilleures performances et mieux tenir la charge. Les bases de données NoSQL supportent « l’horizontal scaling », une base de données peut être distribuée sur une « pool » de serveurs ce qui permet de mutualiser les performances. L’avantage de cette méthode est qu’elle permet d’adapter l’architecture en fonction de la charge en distribuant sur plus ou moins de serveurs suivant les cas.

NoSQL > SQL ?

En lisant quelques benchmarks, on peut alors se demander : pourquoi continuer à utiliser des bases de données relationnelles si le NoSQL est plus performant et plus scalable ?

Afin d’obtenir de meilleures performances, les bases de données NoSQL ont abandonné certaines fonctionnalités proposées par défaut par les bases relationnelles comme les transactions ou encore les vérifications d’intégrités. On peut ici faire la même analogie que Dare Obasanjo avec les boites de vitesses. Le NoSQL est l’équivalent d’une boîte de vitesse manuelle, elle permet d’obtenir de meilleure performance à condition de savoir quand et comment passer les vitesses. Les bases de données relationnelles, comme les boites automatiques permettent de ne pas avoir à se soucier de ce qui se passe derrière en automatisant les choses.

Vous n’êtes pas Google / Facebook

Lorsque l’on parle de technologies web, cette affirmation revient souvent.

Le problème avec cette affirmation c’est que l’on oublie un fait important vous n’êtes pas Facebook, vous n’avez pas des milliers de serveurs pour gérer votre base de données, vous n’avez pas des millions de pages vues à la seconde. Dans la plupart des cas, notre base de données ne tournera que sur un seul serveur et nous ne bénéficierons pas des avantages de l’horizontal scaling.

Il est tentant d’utiliser une base de données NoSQL pour sauvegarder rapidement des données sans avoir à réfléchir au préalable à la structure des données. C’est ce qui justifie en grande partie le succès de base comme MongoDB. Mais cette simplicité est à double tranchant, car si les données sont sauvegardées de manière trop anarchique il sera très difficile de manipuler et organiser nos données par la suite. Par exemple si on décide de stocker les commentaires de nos articles au sein d’un objet.

{
 "title": "Madame Messieurs",
    "note": 4,
    "reviews": [{
        "username": "Mitoumba",
        "content": "Pourquoi l'Argent est un Membre de Ta Famille ?"
    },{
        "username": "Mr Barga",
        "content": "L'Homme Fort !"
    }]
}

Cela peut être pratique dans un premier temps, car ça permet d’obtenir et stocker simplement les commentaires, sans avoir à faire des liaisons complexes. Par contre, si dans le futur nous souhaitons récupérer les derniers commentaires de tous les livres notre organisation va être handicapante nous obligeant alors à repenser notre base ou créer des requêtes plus complexes et ainsi moins performantes

Il est important de choisir une technologie par rapport aux besoins du projet que l’on développe et non pas en fonction d’une éventuelle « hype » faite autour d’une technologie particulière. La base de données constitue en général la fondation d’une application, et un mauvais choix technique peut s’avérer fatal pour l’évolution du projet.