Bien le bonsoir ! En cette belle journée où il pleut je vais vous parler du NoSQL (Not Only SQL). Alors, d’abord le NoSQL est une catégorie de systèmes de gestion de base de données. (Vous êtes encore là ?)

Une base de données, c’est comme une grande bibliothèque qui contient des tables (les différentes étagères de la bibliothèque) et des éléments dans ces tables (les livres sur les étagères). Ce que je viens de vous décrire est une base données relationnelles, c’est-à-dire que y’a des relations entre les étagères. (Par exemple grâce à une relation on peut lister tous les gens qui ont emprunté un livre de Stephen King).

Et ben le NoSQL ne fonctionne absolument pas comme ça ! Et c’est tout l’intérêt. Le NoSQL utilise d’autre moyen pour gérer et organiser les bases. Le gros avantage des bases NoSQL est la rapidité de réponse pour de très gros volume. Par exemple Facebook et Twitter utilise une base NoSQL. Mais à l’origine c’est Google et Amazon qui ont lancé les prototypes du NoSQL.

Soyons clair, le NoSQL ne va pas tuer les bases relationnelles classiques. Il permet d’offrir des alternatives et de mieux répondre à certains besoins.

C’est bon je n’ai perdu personne ? Vous êtes trop fort !

Je ne vais pas parler du fait que le NoSQL renonce au capacités ACID des bases relationnelles pour suivre le théorème CAP. Simplement parce que on s’en fout un peu. Pour ceux que ça intéresse, regardez les liens et fendez vous la gueule !

Par contre je vais vous parler des grandes familles du NoSQL :

• Clé/Valeur : La plus simple, c’est un grand tableau associatif où à chaque clé unique correspond valeur. Les solutions les plus connues : Redis et Riak.
• Document : Même principe que la précédente sauf qu’ici la valeur est un document JSON ou XML. Ce qui permet d’avoir un peu plus de structure. Les solutions les plus connues : MongoDB, CouchDB et RavenDB.
• Colonne : C’est le type qui se rapproche le plus des bases de données relationnelles. On y retrouve un équivalent des schémas (Keyspace), des lignes qui représentent des entités (ex : un livre) et des colonnes qui représentent un ou plusieurs attributs (ex : le titre, l’auteur, etc). On peut regrouper les lignes dans des familles de colonnes (oui je trouve ça très logique aussi). Et chaque ligne d’une même famille non pas toujours le même nombres de colonnes. Les solutions les plus connues : HBase et Cassandra.

• Et enfin  La base de données orientée graphe ! (Ouch ça pique !)

Attardons nous sur cette dernière :

Pour ce qui on pas fait beaucoup de mathématix, un graphe ça ressemble à ça :

 

En gros, y’a des nœuds et des arcs. Tous les nœuds ne sont pas forcement reliés. Certains peuvent ne pas avoir d’arcs.

Donc avec une base de données orientée graphe, il n’y a plus d’étagères, juste des livres, représentés par les nœuds. Et les relations deviennent des arcs. Et comme on parle de graphe on peut utiliser des algorithmes de la Théorie des graphes, comme l’algorithme de Dijkstra. Et grâce à tous ces algos mathématiques on gagne beaucoup en performance. Pour reprendre notre métaphore filée (oui c’est la classe). La base en NoSQL ira plus vite pour lister tous les gens qui ont emprunté un livre de Stephen King, qu’une base traditionnelle.

Par contre, pour des recherches plus simples, qui utilisent moins les relations, une base de données relationnelle sera plus adaptée.

L’acteur principal est Neo4J.

En conclusion je dirais que c’est une techno intéressante. Encore un peu jeune et en cours de maturation mais, elle est puissante et robuste. Et aussi pas mal à la mode, il faut l’avouer. Les solutions NoSQL sont à privilégiées en cas de gros volume de données ou pour des données avec peu de structure. Mais rien ne vous empêche de les utiliser dans d’autres cas. Vu l’évolution des bases relationnelles et du SQL depuis sa naissance, j’attends de voir la progression du NoSQL.

 

---

Article rédigé par Garett pour aryo, le 14/05/2013. | Lien Permanent | 1 Commentaire
Tags : base de données, NoSQL