Le 2 décembre s’est tenu dans les locaux de l’IUT A de Lille une session du Ch’ti JUG sur les technologie NoSQL animé par Olivier Mallassi.

L’intervenant a commencé la conférence par un bref historique de la manière dont les données on été stockées dans le monde de l’informatique:

• Au commencement été les fichiers plats
• Puis vinrent les fichiers plats indexé (gain de performance grâce à l’index) encore couramment utilisés (et surtout en COBOL).
• Ensuite apparurent les base de données relationnelle (les SGBDR – Système de Gestion de Base de Données Relationnel) et le langage SQL, nous étions dans les année 1970!

Pendant prêt de 40 ans, les SGBDR régnèrent en maître sur les technologies de stockage de données … puis au détour des années 2000 un outsider est apparut, poussé par les besoins spécifique des géants du web.

En effet, de par l’accroissement de la fréquentation du web, certaines société telle que Google ou Amazon ont eu a traiter un nombre de données tellement important avec une nécessité de sécurisation des données tellement grande (leur business model étant basé dessus) que les SGBDR montrèrent leur limite et ces société commencèrent à développer des bases de données non relationnelle : le NoSQL été né.

Revenons sur les contraintes de ces géants du web:

• Performance malgré tout (même en cas où une partie des serveurs tombe)
• Disponibilité > 99,99%
• Résilience (capacité à supporter les pannes)
• Scallabilité horizontale

Pour pallier à ces contraintes, chaque société développa ses technologies. Aujourd’hui on peut les ranger en 4 catégories distinctes.

Les bases de données orientées colonne

Références : BigTable (Google), HBase (Apache) et Cassandra (Facebook)

Principales fonctionnalités:

• Stockage des données en colonne et non en lignes
• 1 ligne = une HashMap et 1 valeur = une HashMap, on manipule donc des HashMap de HashMap via l’API.
• Données stockée en tableau de byte : donnée non structurée
• Implémentation de l’algorithme MapReduce au plus proche des données (Job directement dans la base de données) pour le requêtage de données
• Existence de DSL (Domain Specific Language) au dessus de MapReduce pour en simplifier l’utilisation telle que Hive et Pig permettant l’utilisation de JDBC et d’une sémantique plus proche du SQL.

Les bases de données Key/Value

Référence : Dynamo (Amazon) et Project Voldemor (LinkedIn)

Principales fonctionnalités:

• Données stockée sous forme de key/value dans des HashMap : on manipule donc directement des HashMap via l’API
• But : accepter une demande quelle que soit l’état de la base
• Modèle distribué, élastique, ajout d’un serveur dans l’infrastructure à la demande
• Modèle clé/valeur distribué sur l’ensemble des serveurs : clé = localisation
• Scalabilité horizontale
• Tolérance à la panne grâce à une synchronisation asynchrone et synchrone des différents serveurs : mode Master/Master et mise à jour concurrente (transaction non ACID)
  • gossip protocol : les serveurs se parlent entre eux au sujet de leur disponibilité
  • hinted handoff : capacité à servir la requête d’un autre serveur si celui-ci ne répond pas
• Read Repair : modèle « eventually concistent« , ce qui veut dire consistant à la fin : plusieurs versions différentes sur les différent serveur selon leur degré de synchronisation, mais la réponse est toujours consistante.

Les bases de données orientées document

Référence: MongoDB

Principales fonctionnalités:

• Modèle de donnée en Key/Valeur dont la valeur est une donnée structurée et indexable
• Requêtage possible à l’intérieur de la valeur (dans sa structure)

Les bases de données Graph

Référence: neo4j

Principales fonctionnalités:

• Données représentée en graphe
• Implémentation d’un algorithme de parcours de graphe pour le requêtage
• Principales notions : node, relation, property

Autres types de bases de données NoSQL

Base de données XML, Base de données Objet, Base de données géographique, …

Force et faiblesse du NoSQL

Attention, dans certain cas les forces et faiblesses peuvent être vue comme des faiblesse ou des forces. En effet par exemple le fait que la modélisation soi faible est un avantage quand on ne veut pas s’embarrasser d’une modélisation complexe.

Ces forces et faiblesses s’appliquent principalement aux base de type orientée colonnes, orientée document ou Key/Value.

Forces	Faiblesses
Performance Stockage de gros volume Disponibilité et tolérance aux pannes Élasticité du stockage Souplesse de modélisation : pas de structure, on stocke ce que l’on veut.	Transaction non ACID Faible modélisation Pas de contrainte d’intégrité Changement d’outillage d’administration (le plus souvent, bases de données en Java => JMX) Peu de contraintes d’accès (GRANT) Pas de standard Difficile d’intégrer à un Système d’Information existant

Pour autant, il ne faut pas perdre à l’esprit que les bases de données NoSQL ne veulent pas remplacer les bases de données relationnelle mais bien offrir une alternative permettant de répondre à des besoins que n’adressent pas les SGBDR classique. C’est une réelle innovation qui nous oblige à penser différemment la notion de stockage de base de données et vient bouleverser 40 années de SGBDR.