Les bases de données NoSQL

Dans cet article, je vais vous parler des bases de données NoSQL. Vous allez me dire mais qu’est-ce que c’est que ce truc ? Si je traduis littéralement NoSQL nous pourrions croire  que cela signifie « Non SQL » mais ne vous y trompez pas NoSQL signifie « Not only SQL », en français « pas seulement SQL ».

Dans le développement d’applications web comportant une base de données, il est souvent utilisé un système de gestion de base de données relationnelle (SGBDR). Les SGBDR possèdent des mécanismes permettant notamment de garantir la cohérence des données, la concurrence d’accès, la reprise sur panne. Ils utilisent le SQL qui permet d’assurer l’intégrité des données, de réaliser des requêtes complexes pouvant faire intervenir plusieurs tables par l’intermédiaire des jointures, et l’implémentation des transactions, qui permet de gérer les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité).

Dans la plupart des cas une base de données relationnelle avec un schéma relationnel correctement fait suffira pour répondre à vos besoins. Maintenant s’il faut stocker un énorme volume de données (Peta octets), avec beaucoup d’utilisateurs susceptibles de générer un fort trafic, une architecture distribuée devient nécessaire.

Pour faire simple, une architecture distribuée permet, sur un grand nombre de machines, de répartir les données (scaling des données) et également de distribuer les traitements (scaling des traitements). L’ajout de machines supplémentaires (scalabilité horizontale) est également plus simple.

Dans les environnements distribués est appliqué le théorème CAP (Eric BREWER, 2000) :

• Consistency (cohérence) : tous les nœuds du système voient exactement les mêmes données au même moment

• Availability (disponibilité) : la perte de nœuds n’empêche pas les survivants de continuer à fonctionner correctement, les données restent accessibles

• Partition tolérance (tolérance au partitionnement) : aucune panne moins importante qu’une coupure totale du réseau ne doit empêcher le système de répondre correctement, en cas de partitionnement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome.

Qui stipule qu’il est impossible d’avoir à un instant T les 3 propriétés, seulement 2 sont possibles :

AC (Availability/Consistency) ou AP (Availability/Partition tolérance) ou CP (Consistency /Partition tolérance).

Les SGBDR sont des systèmes AC. Les mécanismes qu’ils offrent, notamment les propriétés ACID des transactions, les jointures et intégrité référentielle sont difficiles à maintenir tout en conservant des performances correctes.

Pour pallier à ce problème de performance en environnement distribué, entre en jeu les SGBD NoSQL. Ceux sont des systèmes AP ou CP. Ces SGBD font un compromis sur les propriétés ACID des transactions et la notion de schéma relationnel n’existe plus.

Il existe 4 types de base de données NoSQL :

• Clé/valeur : Les données sont représentées par un couple clé/valeur. La valeur peut être une simple chaine de caractères ou un objet sérialisé. Cette structure très simple à un impact considérable sur les requêtes, toute l’intelligence qu’apporté auparavant les requêtes SQL devra être fait dans l’applicatif qui interroge la base de données.
  Quelques solutions de ce type : Riak, Redis, Voldemort

• Orienté colonne : c’est le modèle qui se rapproche le plus d’une table du modèle relationnel. La différence est que le nombre de colonne est dynamique, il peut varier d’un enregistrement à un autre ce qui évite d’avoir des colonnes avec valeur NULL.
  Quelques solutions de ce type : Hbase, Cassandra

• Orienté document : Ce modèle est un dérivé du modèle clé/valeur. La valeur sera un document de type JSON ou XML. L’avantage de ce modèle est de pouvoir récupérer par l’intermédiaire d’une clé une grande quantité d’information structurée de manière hiérarchique.
  Quelques solutions de ce type : MongoDB, CouchDB, RavenDB

• Orienté graphe : ce modèle se base sur la théorie des graphes, il s’appuie sur les notions de nœuds, de relations et de propriétés qui leur sont rattachées.
  Quelques solutions de ce type : Neo4j, OrientDB

Voilà pour la présentation des bases NoSQL.
Ce type de base est vraiment utilisé dans des cas bien spécifiques, donc avant de vous lancer dans le développement d’une application avec une base NoSQL réfléchissez bien.
Il existe beaucoup d’autres bases NoSQL, vous pourrez en trouver une liste sur le site NoSQL Databases.

Si vous avez des questions n’hésitez pas à laisser un commentaire.