EA2012-NoSQL

Introduction au monde du non-relationnel et du NoSQL.

Le non relationnel

- Rappel sur le relationnel

Avant d’expliquer ce qu’est le non-relationnel, un petit rappel sur ce qu’on appelle « relationnel », et surtout les bases de données relationnelles s’impose. Une base de données est dite relationnelle lorsqu’elle est en « Première forme normale ». Pour cela elle doit satisfaire deux conditions « d’atomicité ». La première étant que tous les attributs de cette relation contiennent une valeur scalaire ; cette valeur ne peut pas être divisée en plusieurs sous-valeurs dépendant de la même clé primaire (colonne qui permet d’identifier une ligne de façon unique). La seconde condition stipule que les valeurs sont non répétitives ; le cas contraire consisterait à mettre une liste dans un seul attribut. Il existe aussi une troisième contrainte cependant moins importante qui demande à ce que les attributs soient constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge).

Exemple de table relationnelle

- Le non-relationnel

Lorsque l’on construit une base de données non-relationnelle, on va perdre la contrainte des valeurs non répétitives ; notre table ne sera alors plus atomique. On pourra donc mettre une liste de valeurs dans un attribut.

Exemple de table non relationnelle

Lorsque l’on décide d’implémenter une base de données non-relationnelle, il faut faire attention à se poser les bonnes questions. En effet, cela engendre plusieurs « détails » dont nous n’avons pas à nous soucier dans une base de données relationnelle. Cela concerne par exemple, la gestion des clés primaires : lorsque nous sommes en non-relationnel, la question à se poser est si celles-ci doivent obligatoirement être atomiques ou peuvent être des listes (de valeurs). Il faut savoir que si c’est une liste, la collection de données qu’elle pointe peut grandir de façon exponentielle et peut ainsi engendrer des problèmes de tailles. Ce cas n’est cependant pas impossible. Notons que les bases de données non-relationnelles ne sont pas formalisées (contrairement aux bases de données relationnelles) ; la réponse aux différentes questions dépend donc totalement du cas d’utilisation et du développeur.

-Représentation

La différence entre relationnel et non-relationnel peut être perçu de la manière suivante : une base de données relationnelle peut être représentée grâce à une table, alors que la non-relationnelle est représentée par un arbre avec des nœuds de taille variable (puisqu’un nœud représente une liste de valeurs).

Exemple d’arbre représentant une base de données non-relationnelle

A noter qu’un arbre peut être implémenté en XML. Le format XML est un langage permettant de stoker des données de façon non-relationnelle. Donc, si vous avez fait du XML (par exemple du HTML) vous avez fait du non-relationnel. En faisant le lien Non-Relationnel -> XML, on voit très bien son avantage sur le relationnel : sa simplicité et sa souplesse.

Le NoSQL

Le SQL est le langage utilisé pour faire des requêtes sur les bases de données relationnelles. (Exemple : Pour récupérer toutes les personnes dont l’âge est inférieur à 25 ans « SELECT * FROM personne WHERE age < 25 »). Etant donné que les bases de données non-relationnelles existent aussi, il a fallu décrire le concept de NoSQL qui gère ces bases-là. NoSQL désigne une catégorie de systèmes de gestion de bases de données dont les architectures des relations ont été remplacées/modifiées. Le terme NoSQL, qu’on pourrait interpréter comme « pas de SQL », désignerait plutôt, d’après sa première utilisation en 1998, « pas de relation ». Comme le stipule Shashank Tiwari dans son livre Professional NoSQL, « les auteurs de ce néologisme ont probablement voulu signifier non-relationnel, mais ont préféré le mot NoSQL parce qu’il sonne mieux ». Il faut noter que c’est un concept, il n’existe donc, pour le moment, aucune norme dans ce domaine. Qu’apporte le NoSQL par rapport au SQL ? Avant le NoSQL, de nombreuses personnes ont travaillé sur des normes et des outils que, maintenant, la plupart des informaticiens connaissent (Oracle, SGBD, … ). Ces systèmes sont très performants dans leur domaine d’application qui se veut extrêmement large puisque les créateurs ont voulu inclure tous les cas possibles. Pour certifier ces domaines d’application, des propriétés ont été mises en place. Ce sont les propriétés ACID : Atomicité (lorsque l’on fait une requête, elle est soit complétement exécutée, soit pas du tout), Cohérence (tous les nœuds du système voient exactement les mêmes données au même moment), Isolation (lorsque deux transactions A et B sont exécutées en même temps, les modifications effectuées par A ne sont ni visibles par B, ni modifiables par B tant que la transaction A n'est pas terminée et validée), Durable (une fois validé, l'état de la base de données doit être permanent, et aucun incident technique, comme par exemple un crash, ne doit pouvoir engendrer une annulation des opérations effectuées durant la transaction). Pour pouvoir satisfaire ces propriétés, les bases de données possèdent des outils (souvent inconnus de l’utilisateur). Cependant, ces outils ont un prix : le temps. Une étude d’Harizopoulos et AL08 a montré que 35% du temps d’exécution d’une requête sert à la gestion du buffer de données (les données sont chargées en mémoire dans ce buffer), 21% pour le « locking » (le fait de « fermer » un accès à une personne tant qu’une autre et en cours de traitement), …

Cependant, de nouvelles problématiques non envisagées par les créateurs sont apparues. Par exemple lorsque l’on va chercher à avoir une information le plus rapidement possible, dans de très grands volumes de données, quitte à perdre en cohérence : l’exemple représentatif de ce problème est Google. Si l’on fait deux fois la même requête sur Google on n’est pas sûr d’avoir les mêmes informations. Cependant, cet outil est tout de même très performant car il nous permet d’avoir des milliers de réponses en moins d’une seconde. Le NoSQL englobe donc des systèmes de gestion de données tels que le système clé/valeur ou encore un système de table (comme les bases de données) mais sur lesquelles les jointures (entre deux tables) seront interdites.

Exemple de système NoSQL

Etant donné que le NoSQL n’est pas normalisé et que les choix de développement d’une base de données non relationnelle sont au cas par cas, il existe de nombreux systèmes de données non relationnels. L’un des plus connu est MongoBD. MongoBD est un système de gestion de bases de données orientées documents, ne nécessitant pas de schéma prédéfini de données.

Exemple de données MongoBD

Liste des autres systèmes non relationnels existants : BigTable (google) / Dynamo (Amazon) / Projet Voldemort (LinkedIn) / Cassandra - HBase (Facebook)

Conclusion

En considérant le théorème de Brewer (ou théorème CAP) qui stipule, qu’il est impossible d’avoir les trois caractéristiques suivantes en même temps dans une base de données :

- Cohérence : tous les nœuds du système voient exactement les mêmes données au même moment.

- Disponibilité : Garantit que toutes les requêtes reçoivent une réponse

- Résistance au morcellement : aucune panne moins importante qu’une coupure du réseau ne doit empêcher le système de répondre correctement.

on peut conclure qu’une base de données relationnelle favorise la cohérence (et peut en plus en fonction des cas être disponible ou résistante aux pannes) alors qu’une base de données non relationnelle va favoriser la disponibilité et la résistance au morcellement. Ce sont donc deux concepts fondamentalement différents.

Résumé

Une base de données non relationnelle, comme son nom l’indique, désigne toute base qui n’est pas relationnelle. Cela signifie qu’elle n’est pas en première forme normale : toutes les entrées sont atomiques (pour une case de la table, une seule valeur est associée et non une liste). De nombreux systèmes ont vu le jour sur le principe des bases de données relationnelles (Oracle, SGBD … ). Cependant, ces systèmes ne correspondent plus au problème actuel comme notamment la recherche sur des bases de données extrêmement grosse en un minimum de temps quitte à sacrifier la cohérence (exemple : Google). Les systèmes non-relationnels se veulent plus simples et plus faciles d’utilisation (comme le XML) mais peuvent parfois devenir plus compliqués (comme les bases de données orientées objets) que les systèmes traditionnels. Les systèmes qui gèrent le non-relationnel sont appelés « systèmes NoSQL » (qu’il faut comprendre comme « Not ONLY SQL »). Le plus connu étant MongoBD, un système de gestion de bases de données orientées documents, ne nécessitant pas de schéma prédéfini de données.

Summary

A non-relational database, as its name suggests, refers to any base that is not relational. This means that it is not in first normal form: all entries are atomic (for a box of the table, a single value is assigned and not a list). Many systems have been developed on the principle of relational databases (Oracle, DBMS ...). However, these systems do not correspond to the new problematics as including research on very large databases in a short time even sacrificing consistency (eg Google). Non-relational systems want to be more simple and easier to use (such as XML), but sometimes can become more complicated (such as object-oriented databases) than traditional systems. Systems that manage the non-relational are called "NoSQL systems" (to be understood as "Not ONLY SQL"). The most famous are MongoBD, a management system document-oriented databases, does not require predefined datas schema.

Bibliographie

http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_CAP

http://en.wikipedia.org/wiki/NoSQL

http://www.college-de-france.fr/media/serge-abiteboul/UPL5219443991792265458_Abiteboul21mars.pdf

Auteur

FOURURE Florian

Elève à Polytech Grenoble

Filière Réseaux Informatiques et Communication Multimédia

ffourure@free.fr