Commençons par clarifier les choses, le NoSQL ce n’est ni un langage, ni un standard, ni de l’anti SQL, ni de l’anti base de données, ni “Not Only SQL”.
Lancé en juin 2009, le NoSQL est un mouvement dont le but est de proposer une alternative au langage SQL et au modèle relationnel des bases traditionnels.
Le NoSQL n’a pas pour vocation de remplacer le modèle relationnel mais plutôt de compléter ses fonctionnalités ou de s’adresser à des applications différentes.

Les bases relationnelles c’est robuste, elles ont fait leur preuve alors pourquoi le NoSQL ?

Le NoSQL est issu du travail des grands acteurs d’internet (Google, Amazon, Facebook, LinkedIn, …) en écho aux nouvelles architectures que sont le cloud computing et les sites communautaires.

Sa génèse est liée au théorème de CAP formulé par Eric Brewer (UC Berkeley) en 2000 (keynote) et démontré par  Seth Gilbert et Nancy Lynch (MIT) en 2002 (white paper).
Ce théorème énonce qu’il est impossible, sur un système informatique de calcul distribué, de garantir en même temps les trois contraintes suivantes :

• Coherence (Cohérence) : Tous les clients voient la même chose, même en présence de mises à jour.
• Availibility (Disponibilité) : Tous les clients obtiendront une réponse à leur requête.
• Partition Tolerance (Partitionabilité) : Les propriétés du système sont maintenues même lorsque celui-ci est partitionné.

En réponse à ce théorème les architectes en place décidèrent de sacrifier la cohérence au profit de la disponibilité et de l’évolutivité. Cette décision, motivée par des besoins croissant en terme de charge et de volumétrie, engendra  la mise au point de systèmes de bases de données non relationnels. Aucun d’entre eux ne supportant le langage SQL le terme « NoSQL » fût choisi pour les qualifier.

En se détachant du caractère ACID des transactions, les systèmes NoSQL se sont donc dégagées de deux entraves que connaissent les bases relationnelles :

• L’évolutivité horizontale : Le déploiement d’une base NoSQL sur de multiples machines ainsi que l’ajout d’une nouvelle machine au sein du réseau distribué sont facilités.
• La flexibilité : Une base NoSQL peut en effet croître sans contrainte, sa structure organisationnelle n’est pas liée à un schéma relationnel difficile à modifier.

Au sujet de l’évolutivité, Adam Wiggins (Heroku) explique clairement dans ce post en quoi il est ardu de la  mettre en oeuvre sur une base relationnelle.

Ok, c’est très bien tout ça mais concrètement les bases NoSQL ça se présente comment ?

Actuellement il existe ~= 122 solutions NoSQL. Le site nosql-database.org maintient une liste à jour.
Ces différentes alternatives au SQL sont regroupés selon 6 types :

• Associatif (clé-valeur) : Riak, Voldemort, Membase/Memcached
  Equivalent d’un gros HashMap ou Dictionary (cf Smalltalk pour les incultes :) ). Il n’y a pas de modèle de donnée et tout type de donnée peut-être associé à une clé.
• Hiérarchique : GT.M
  Organise les données dans une structure sous forme d’arbre.
• Orienté document : MongoDB, CouchDB, RavenDB, Lotus Notes
  Fonctionne comme le type Associatif sauf que la valeur est ici un objet structuré auto-décrit en XML ou Json. A partir d’une clé, de l’information très structurée peut donc être remontée simplement là où plusieurs jointures aurait été nécessaire dans le monde relationnel.
• Orienté colonne : Cassandra, Hadoop/HBase, SimpleDB
  Possède un modèle de donnée similaire à celui des bases relationnelles cependant le nombre de colonne est dynamique. Pour une même table 2 enregistrements peuvent avoir un nombre de colonnes différent ce qui limitent les colonnes à NULL.
• Orienté graphe : Neo4J, InfiniteGraph
  Utilise une structure de graphes comportant des noeuds, des arcs et des propriétés pour représenter et stocker l’information.
• Orienté objet : GemStone/S, db4o
  Stocke les données sous formes d’objets tel qu’utilisés au sein de la programmation orientée objet. Le concept n’est pas nouveau mais ces bases sont désormais etiquettées NoSQL.

Certaines solutions misent sur la facilité de prise en main. CouchDB, par exemple, représente la donnée en JSON, fournit des services de requêtage, propose un mécanisme de réplication simple et peut être utilisée comme serveur d’application.
D’autres sont fondamentalement tournées vers la performance. HBase, Cassandra et Riak pour ne citer qu’elles.
Les bases orienté graphes, quant à elle, permettent de mettre en place des modélisations complexes inconcevables dans les bases relationnelles. Et les performances ne sont pas en reste, Neo4J est capable de lire 1000 niveaux de noeuds aux alentours d’1 ms.

Quel avenir pour le NoSQL ?

A première vue, le principal désavantage du NoSQL est sa jeunesse. Comparé aux sytèmes matures et connus que sont les bases relationnelles, il ne fait pas le poids.
Les outils de supervision ne sont pas très développés pour le moment et cela peut constituer un frein à une mise en production sur des applications critiques.
Le NoSQL a aussi une image de système à déployer uniquement sur des applications nécessitant d’être très performante et travaillant sur de gros volumes. Sorte de Rolls-Royce des bases de données que seules de grosses compagnies peuvent s’offrir.

Malgré cela, le NoSQL reste une technologie attrayante. D’une part elle apporte de l’agilité  au niveau du  développement et de la maintenance. D’autre part, elle remet au goût du jour des solutions qui avaient été éclipsées par l’avènement des bases relationnelles.
Il ne s’agit pas non plus de tout basculer vers le NoSQL mais plutôt de s’orienter vers des solutions hybrides en couplant une base relationnelle avec une base NoSQL. Comprendre comment est manipulée la donnée au sein du SI redevient l’enjeu primordial et implique de se pencher sur de nouveaux paradigmes tel l’Eventual Consistency.
Certaines entreprises ont franchi le pas « The Guardian » (post, slides) ou Twitter (slides) et leur retour d’expérience est très intéressant.

Jusqu’à quel point le challenger NoSQL pourra inquiéter le règne du  champion Relationnel, là est la question :)

Références :
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
http://www.slideshare.net/thobe/nosqleu-graph-databases-and-neo4j
http://highscalability.com/neo4j-graph-database-kicks-buttox
http://nosql.mypopescu.com/
http://www.slideshare.net/ksankar/nosql-4559402