Panorama des Bases de Données NoSQL

Cet article s'inscrit dans une logique de continuité avec l'article " [Paradigme des Systèmes NoSQL]urlblank : http://www.decideo.fr/Paradigmes-des-systemes-NoSQL_a8486.html " qui présente le contexte technologique et les fondements conceptuels des systèmes NoSQL.
Avant toute plongée en eau profonde, il faut savoir qu'est qualifié de "NoSQL", tout système de gestion de base de données qui ne se fonde pas sur l'approche relationnelle. L'objectif des moteurs NoSQL est d'assurer la distribution du stockage et du requêtage des données sur un nombre théoriquement illimité de nœuds d'un cluster. Pour atteindre cet objectif, les moteurs NoSQL changent de paradigme en matière de stockage de données : dans les moteurs relationnels, l'unité de stockage c'est la relation (ou table), mais celle-ci n'est pas adaptée dans un contexte Big Data. En réponse à cette limite, les éditeurs de moteurs NoSQL vont penser à des approches de stockage plus souples qui favorisent la distribution des données. Ces approches ont donné naissance à 6 catégories de moteurs NoSQL connues à ce jour : les moteurs orientés-clé/valeur, les moteurs orientés-colonnes, les moteurs orientés-documents, les moteurs orientés-graphes, les moteurs orientés-plein texte et les moteurs Natifs XML.

1) Les moteurs orientés clé-valeur
Ce sont des systèmes d'indexation des objets stockés sur le disque à l'aide d'un mécanisme de clé. Ces moteurs fonctionnent exactement comme une table de hashage ou comme un dictionnaire dans lequel à chaque objet stocké sur le disque dur est associé un pointeur (une clé). A la différence des tables de hashage classiques, les clés des bases orientés clé-valeur sont persistées sur le disque dur.
Les utilisateurs n'accèdent pas aux données qui sont stockées sur le disque, ils y pointent à l'aide de leur clé. De ce fait, ces moteurs n'ont pas besoin d'un langage d'interrogation de données.
Étant donné que ce ne sont que les clés qui sont manipulées, 3 opérations peuvent y être effectuées : le PUT (ajout d'un pointeur), le GET (obtention d'un objet à partir de son pointeur) et le DELETE (suppression d'un pointeur et de l'objet associé).
La simplicité de ce système permet au moteur de monter en charge de façon linéaire. Un cas d’usage de ce type de moteur est le stockage des pages web. Les moteurs de recherche tels que Google utilisent ces moteurs pour stocker simplement des sites web entiers sous forme de clés-valeur. Amazon, dans son offre Cloud Amazon S3 utilise ce type de système pour gérer le stockage des données médias tels que les images et les vidéos.
Quelques exemples de moteurs orienté clé-valeur : Redis et Riak.

2) Les moteurs orientés-colonne
A ne pas confondre avec les moteurs In-Memory colonne, tels que HP Vertica, Teradata, MonetDB, SybaseIQ qui sont des moteurs de traitement Analytique de type OLAP dans lesquels les données des colonnes d'une table sont persistées dans la même position sur le disque dur. Les moteurs In-Memory Colonne sont contraires aux moteurs relationnels où ce sont plutôt les lignes qui sont persistées dans la même position sur le disque dur. L'approche In-Memory colonne est très utilisée dans les systèmes OLAP, car la localisation des colonnes dans la même position sur le disque facilite les opérations d'agrégation de données.
Les moteurs orientés-colonne quant à eux sont plus des entrepôts que des moteurs de Base de Données. Ils sont conçus pour stocker les données éparses ou les données qui ont les mêmes caractéristiques que les matrices creuses, c'est-à-dire des données qui ont beaucoup de valeurs nulles. Ils stockent les données sous forme de grille similaire à un tableur, dans laquelle la ligne et la colonne sont utilisées comme clé pour identifier et récupérer les données. Ils sont considérés comme des entrepôts car ils ne typent pas les données, ne les indexent pas et ne fournissent pas de langage de requête pour l'extraction des données. Grâce à ces caractéristiques, ils passent facilement à l'échelle et peuvent s'appuyer sur des modèles de calculs externes tels que le MapReduce pour l'exploitation des données qui y sont persistées. Ils sont particulièrement bien adaptés pour le stockage de fortes volumétries de données. Un cas d’usage des moteurs orientés-colonne est le stockage des données géo-spatiales (prenez par exemple le service Google Earth, qui pour chaque centimètre carré de la planète est capable de fournir ses coordonnées géographiques).
Exemples de moteur orienté-colonne : HBase, Google BigTable

3) Les moteurs orientés-documents
Ce sont des moteurs clé/valeurs, à la différence que les valeurs sur lesquels pointent les clés sont ici des documents. L'avantage d'utiliser un moteur orienté-document est que tout le contenu du document peut être indexé, et selon la structure du document, des requêtes de recherche (le Search) peuvent être adressées au moteur pour récupérer les contenus ayant la ou les mêmes propriétés. Par contre, cet avantage peut rapidement s'avérer un problème, car puisque tout le contenu des documents peut être indexé, d'une part les indexs peuvent rapidement devenir très volumineux, posant ainsi des questions en matière d'architecture, d'autre part, en fonction de la structure (ou format) des documents, la recherche de contenu peut être plus ou moins compliquée. Mais dans ces moteurs, ce sont les documents de format JSON qui sont généralement utilisés. Ces moteurs passent à l'échelle sans aucune difficulté particulière.
Exemple de moteur orienté-document : MongoDB

4) les moteurs orientés-graphes
Les moteurs orientés-graphes sont des moteurs qui sont conçus pour gérer les problèmes dans lesquels les entités du problème entretiennent des relations complexes. C'est par exemple le cas dans les réseaux sociaux. Comparativement à tous les autres moteurs de base de données qui regroupent toutes les données autour d'une table ou d'un agrégat, les moteurs orientés graphes les éclatent autant que possible sous forme de nœuds interconnectés qui forment un graphe. Pour être formel, un graphe est un ensemble de sujets-prédicats-objets. Organiser les données sous cette forme permet d'activer des fonctionnalités intéressantes telles que l'inférence, le géo-spatial, le reverse query et la bi-temporalité. Ces fonctionnalités permettent de traverser le graphe de la façon la plus fine possible, de détecter les corrélations et les tendances.
Un exemple de graphe : Juvénal habite Garges Sarcelles, Garges Sarcelles appartient au Val d’Oise, Val d’Oise est un département de l'Ile de France, l'île de France est une région de la France. Dans la première instance de ce graphe (formellement appelé un triplet), Juvénal est le sujet, habite est le prédicat, et Garges Sarcelles est l'objet. Une requête de type inférence permet d'inférer que Juvénal habite dans le Val d'Oise. Ce type de relation peut être très complexe à modéliser dans une Base de Données Relationnelle.
L'inconvénient des moteurs orientés-graphe cependant est que la forte connectivité du graphe ne permet pas au moteur de pouvoir distribuer le parcours du graph sur plusieurs nœuds dans des clusters classiques ('shared-nothing'), tout le graph doit être monté en mémoire pour être traité. Cependant, des architectures de cluster de type "Shared-Memory" peuvent résoudre ce problème de passage à l'échelle jusqu'à un certain point.
Exemple de moteurs orientés-graphe : Neo4J, Infinite Graph, OrientDB

5) Les moteurs orientés plein texte ou Index Inversé
Nous avons dit précédemment que l'avantage d'utiliser les moteurs orientés-documents est leur capacité à indexer le contenu des documents. Cependant, indexer tout le contenu des documents fait accroître rapidement à la fois le volume et le temps de construction des index à mesure que les documents sont ajoutés à la base. Par exemple, un document de 20 pages contenant 5000 mots conduit à 5000 index ; ajouter 1000 documents dans la base contenant chacun 5000 mots conduit à approximativement 5 000 000 d'index à mettre à jour. Les moteurs orientés Plein-texte ou Index Inversé sont des moteurs spécialisés dans l'exploitation de ces index à des fins de recherche textuelle. Ils fournissent des algorithmes de recherche (par exemple Search ranking, Stemming, Entity Extraction, Proximity Search, ...) qui permettent par le biais d'index inversés de rechercher du contenu dans une base documentaire. Google par exemple, construit des index inversés à l'aide du MapReduce pour répondre aux recherches qui sont effectuées sur son moteur.
Exemples de moteur orientés-plein texte : Apache Solr et ElasticSearch.

6) Les moteurs natifs XML
"la valeur d'un standard est proportionnelle au carré du nombre de systèmes qui l'utilise". Cette paraphrase de la loi de Metcalfe justifie pourquoi j'ai décidé de rajouter les moteurs natifs XML dans cet article. L'inconvénient des précédents moteurs NoSQL est la non-portabilité des applications. En effet, le relâchement des contraintes relationnelles fait que le développeur d'application dans un moteur NoSQL doit lui-même coder à la fois la logique applicative et la couche "cohérence de données". Ceci empêche de déplacer l'application d'un moteur à un autre (de la même catégorie). Ce problème de portabilité est en partie dû à un manque de standard commun défini à la fois pour le stockage et les requêtes. C'est ce facteur qui a notamment permis aux bases de données relationnelles de s'étendre jusqu'à présent (la présence du SQL, un langage commun d'interrogation de SGBDR garantit la portabilité d'une application d'un SGBDR à un autre, ce qui n'est pas le cas avec les moteurs NoSQL).
Les moteurs natifs XML sont similaires aux moteurs orientés-documents, à la différence qu'ils gèrent les documents XML. Le XML empêche l'introduction dans le moteur d'un langage propriétaire pour la gestion et l'interrogation des données. Les requêtes sont faites sur les documents à l'aide du XQuery, un langage standard défini par le W3C pour l'interrogation des documents XML.
Exemple de moteurs XML : Berkely XML, existDB

Que dois-je retenir ?
- On n'évalue pas une technologie hors du contexte dans lequel elle a été créée ;
- Le contexte dans lequel une technologie a été créée détermine son but, et son but détermine ses caractéristiques ;
- Chaque catégorie de solution NoSQL représente une approche conceptuelle différente de résolution de la problématique de stockage de données en Big Data.