Cour 9.

BASE DE DONNEES NoSQL

Les bases de données relationnelles ont été développées comme une technologie pour
stocker des données structurées et organisées sous forme de tableaux. Aux cours des
années, elles sont devenues l’élément essentiel des organisations et le modèle de
référence pour la gestion des données des systèmes d’informations. Cependant, avec
l'augmentation continue des données stockées et analysées, les bases de données
relationnelles commencent à présenter une variété de limitations. C’est dans ce contexte
que les bases de données NoSQL étaient développées pour fournir un ensemble de
nouvelles fonctionnalités de gestion des données tout en surmontant certaines limites
de bases de données relationnelles.

1. DEFINITION NoSQL
NoSQL est l’acronyme de « Not only SQL » qui signifie « non seulement SQL » en
français.
C’est donc une manière de dire qu’il y a autre chose que les bases de données
relationnelles.
NoSQL est un mouvement très récent, qui concerne les bases de données. L’idée du
mouvement est simple : proposer des alternatives aux bases de données relationnelles
pour coller aux nouvelles tendances et architectures du moment, notamment le Cloud
Computing. Les axes principaux du NoSQL sont une haute disponibilité et un
partitionnement horizontal des données, au détriment de la cohérence. Les bases de
données relationnelles actuelles sont basées sur les propriétés ACID
Par conséquent, NoSQL ne vient pas remplacer les BD relationnelles mais proposer une
alternative ou compléter les fonctionnalités des SGBDR pour donner des solutions plus
intéressantes dans certains contextes.
Le NoSQL regroupe de nombreuses bases de données, récentes pour la plupart, qui se
différencient du modèle SQL par une logique de représentation de données non
relationnelle. Leurs principaux avantages sont leurs performances et leurs capacités à
traiter de très grands volumes de données.

Les bases de données NoSQL sont sujettes au théorème CAP (Consistency Availability
Partition Tolerance) et ne sont pas conformes aux propriétés ACID, contrairement aux
bases de données relationnelles. Les réseaux sociaux appliquent fortement l’utilisation
des bases de données NoSQL, vu leurs besoins compatibles avec CAP.
La consistance (Consistency) : tous les nœuds du système voient exactement les
mêmes donnéesau même moment.
La disponibilité (Availability) :garantit que toutes les requêtes reçoivent une réponse.
La persistance au partitionnement (Partition Tolerance) : aucune panne moins
importante autre que la 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).
2. FONDEMENTS DES SYSTEMES NoSQL
2.1. Sharding
Le terme dérivé sharding décrit l’éclatement des données en partitions distribuées sur
plusieurs machines, de façon aussi automatique que possible par le moteur NoSQL. Il
est utilisé dans beaucoup de moteurs et est parfois disponible par des additions aux
moteurs qui ne le supportent pas nativement.
Par exemple, au moins trois extensions sont disponibles pour effectuer du sharding sur
CouchDB, BigCouch, Lounge et Pillow.
Le sharding consiste donc en un partitionnement des données ou clustering (à ce niveau,
les concepts ont tendance à se chevaucher). Il désigne une forme de partitionnement
présentant des caractéristiques particulières.
L’éclatement est géré automatiquement par le système. Il n’y a apriori et autant que
possible aucun besoin de le gérer manuellement.
L’éclatement est par nature distribué. Cela n’a pas de sens de créer plusieurs shards
sur la même machine, en tout cas pas en production.
La répartition de charge est possible.
Le concept de sharding n’est pas limité aux bases NoSQL. Il s’agit en définitive d’un
partitionnement de données effectué sur une clé. Ce qui ne pose pas de problème majeur
pour un SGBDR.

2.2. MapReduce
MapReduce n’est pas en soi un élément de bases de données. Il s’agit d’une approche
de traitement de l’information distribuée qui prend une liste en entrée et en produit, une
en retour.
MapReduce a été défini en 2004 dans un article rédigé par Google. Le principe est
simple: pour distribuer un traitement, Google a imaginé une opération en deux étapes,
tout d’abord, une attribution des opérations sur chaque machine (Map), suivie après
traitement d’un rassemblement des résultats (Reduce).
En soi, le raisonnement n’est pas révolutionnaire. Encore fallait-il en décrire
l’implémentation technique, de façon suffisamment intelligente, pour éviter les écueils
propres à un environnement distribué ? Le traitement distribué génère des défis comme:
que faire en cas de défaillance d’une unité de traitement ? Comment s’assurer d’une
bonne distribution du travail? Comment synchroniser de façon efficiente les résultats?
Le modèle MapReduce offre des réponses à ces défis avec la volonté de simplifier et
de contourner les problèmes pour aboutir à des solutions pragmatiques.
Les besoins de Google qui ont donné naissance à MapReduce sont de deux ordres :
comment traiter des volumes gigantesques de données déstructurées (des pages web à
analyser pour nourrir le moteur de recherche de Google ou l’analyse des logs produits
par le travail de ses moteurs d’indexation, par exemple), pour en tirer des résultats de
calculs, des agrégats, des résumés et de l’analyse.
La diminution du coût du matériel ouvre la voie à la résolution du problème de l’analyse
du BigData. Créer une architecture logicielle qui permet une montée en charge
horizontale simple est la réponse la moins coûteuse au problème de la montée en charge.
Optimiser les performances d’un système de gestion de données sur une seule machine
demande beaucoup d’énergie et de compétences, pour aboutir à des résultats fragiles
qui ne peuvent supporter une multiplication soudaine de la demande. En revanche,
s’assurer que le modèle de traitement des données est bien distribué de la façon la plus
élégante possible sur des machines séparées, qui peuvent être multipliées à l’infini. Il
permet de répondre à des augmentations foudroyantes de la demande de façon très
simple: par l’achat et l’installation rapide de nouvelles machines, qu’elles soient
puissantes ou non, et en s’assurant que toute défaillance d’une machine ne se traduise
pas par une perte de données. Il faut donc vérifier que le modèle déployé est capable de
distribuer au mieux les données et le travail, même sur des dizaines de milliers de
nœuds, en offrant un système de réplication suffisant pour éliminer statistiquement les
risques de pertes de données. Ce sont ces critères que le modèle MapReduce permet de
respecter. Il offre un modèle qui simplifie au minimum les complexités de
l’informatique distribuée, en vue de fournir des outils aux développeurs.
L’implémentation en Java donne par ailleurs la possibilité de s’abstraire de
l’architecture matérielle, afin qu’un framework MapReduce puisse fonctionner et
interagir sur des machines hétérogènes.
Les opérations de map et reduce imaginées par Google ont été inspirées par les
primitives du même nom du langage LISP (LISt Processing). Il est important de
comprendre le modèle de programmation qui a donné naissance à MapReduce.

3. DIFFERENTS TYPES DE BASE DE DONNEES NoSQL

Il existe plusieurs types de base de données qui permettent de stocker les informations
de la façon la mieux adaptée à la représentation, ils seront triés selon leur type de
modélisation de données.
3.1. Base de données orientée clé / valeur
Ces bases de données sont idéales pour accéder aux données par le biais d’une clé. La
spécificité est que les données peuvent être stockées sans définir de schéma spécifique.
Ces bases de données sont très efficaces pour la lecture et l’écriture, et conçues pour
s’adapter massivement et proposer un temps de réaction extrêmement rapide.
Les bases de données clé-valeurs sont les bases de données NoSQL les plus simples.
Elles sont constituées d’une clé unique et d’un pointeur renvoyant à un certain type de
données, créant des paires clé-valeur regroupées en une table de hachage. Ce type de
base de données est utile pour des données analytiques. Elle ne possède aucune capacité
de base de données, donc pour cela, l’utilisateur devra uniquement se baser sur
l’application. Les requêtes sont limitées à la valeur de la clé, ce qui permet d’offrir une
grande vitesse de réponse, mais ce qui complique les mises à jour.
Les références dans cette catégorie de bases de données sont Redis, Riak, Oracle
NoSQL et Microsoft Azure Table Storage.

3.2. Base de données orientée colonne

Ce type de modèle de BD est une extension des bases de données clé-valeurs, avec des
colonnes et des caractéristiques des bases de données relationnelles. Elles sont peu
adaptées aux mises à jour fréquentes et préfèrent les ajouts. Les relations ne sont pas
supportées, ce qui implique la création d’une structure en réseau pour les données
connectées, ce qui n’est pas la solution la plus efficace. Elles sont utilisées quand une
grande quantité de données doit être stockée et qu’une grande disponibilité est
demandée. La plupart des systèmes de type orienté colonne peuvent supporter les
données géospatiales, mais surtout avec des données intégrées et des requêtes simples
avec une demande de réponse rapide HBase, Cassandra,Big Table, DynamoDB et
Accumulo sont des exemples de bases de données orientées colonnes qui sont utilisées
par Amazon, Google et Facebook.
3.3. Base de données orientée document
Les bases de données orientées documents consistent à gérer une grande quantité de
données. Une clé est assignée à un document qui peut lui-même posséder plusieurs
couples clé-document intégrés. Un document peut être importé sous différents formats
standards comme XML (Extensible Markup Language), JSON (JavaScript Option
Notation) ou BSON (Binary JSON). La différence aux bases de données clé-valeurs est
que les recherches peuvent être effectuées sur le contenu des documents et pas
uniquement leur clé. La présence des documents intégrés permet d’effectuer des
recherches avancées et ne requiert pas de schémas prédéfinis. Les BD orientées
documents permettent à un document d’être décrit par un grand nombre de valeurs et
peuvent supporter un schéma flexible. Elles peuvent accueillir une grande quantité de
données sous des formats fortement différents. La relation entre les documents est
représentée par l’intégration de ceux-ci, il n’existe pas de relations extérieures. Un
document est indépendant d’un autre qui ne lui est pas intégré. Ainsi, pour des requêtes
qui interrogent les documents d’une même collection (ensemble de document), la
réponse sera très rapide. L’utilisation de document XML peut améliorer les BD
orientées documents en offrant des fonctionnalités complémentaires (XQuery,
Xpath, XPointer) et en offrant le principe de relation qui n’existait pas sans le XML.
On retrouve principalement CouchDB et MongoDB comme solutions basées sur le
concept de base documentaire et Twitter est un d’utilisateur.

3.4. Base de données orientée graphe

La base de données orientée graphe est un type de base de données NoSQL utilisant la
théorie des graphes pour stocker, cartographier et effectuer des requêtes sur les relations
entre les données.
Les bases de données orientées graphes sont constituées de nœuds et de bords. Chaque
nœud représente une entité, et chaque bord représente une connexion entre les nœuds.
Les bases de données graphes gagnent en popularité dans le domaine des analyses
d’interconnexions. Ce modèle est capable de gérer des données relationnelles. Les BD
graphes sont utiles pour les données constituées en réseau comme les routes, les réseaux
sociaux.
Contrairement aux autres types de bases de données NoSQL, les BD orientées graphes
ne sont pas optimales pour les grandes quantités de données si celles si ne sont pas assez
connectées.
Oracle Graph, Neo4J, Arango et OrientDB sont des exemples de ce modèle. Elles sont
utilisées par Walmart et Ebay

4. REQUETAGE NoSQL
Dans le monde du NoSQL, il n’y a pas de langage standard comme SQL l’est dans le
monde des bases de données relationnelles. L’interrogation des bases de données
NoSQL se fait au niveau applicatif à travers principalement la technique dite de «
MapReduce ». Cette technique se décompose en deux grandes étapes.
4.1. Etape de mapping
Chaque item d’une liste d’objets clé-valeur passe par la fonction map qui va retourner
un nouvel élément clé-valeur. Exemple de la fonction map : A chaque couple (UserId,
User), on assigne le couple (Rôle, User). A l’issue de l’étape de mapping, on obtient
une liste contenant les utilisateurs groupés par rôle.
Une opération faisant appel à la fonction « map » permet donc de lancer une fonction
pour chaque élément dans une séquence afin d’obtenir en retour une séquence de taille
égale des valeurs résultantes.
4.2. Etape de Reduce
La fonction reduce est appelée sur le résultat de l’étape de mapping et permet
d’appliquer une opération sur la liste
Exemples de fonction reduce:
- Moyenne des valeurs contenues dans la liste
- Comptabilisation des différentes clés de la liste
- Comptabilisation du nombre d’entrées par clé dans la liste.
Une opération faisant appel à la fonction « reduce » permet donc d’accumuler le
contenu d’une séquence dans une seule valeur de retour, en utilisant une fonction qui
va combiner chaque élément dans la séquence avec la valeur de retour de l’itération
précédente.
L’étape de mapping peut être parallélisée en traitant l’application sur différents nœuds
du système pour chaque couple clé-valeur. L’étape de réduction n’est pas parallélisée
et ne peut être exécutée avant la fin de l’étape de mapping. Les bases de données
NoSQL proposent diverses implémentations de la technique MapReduce permettant le
plus souvent de développer les méthodes map et reduce en JavaScript ou en Java.

5. AVANTAGES DU NoSQL
Il peut être tentant de voir les bases de données NoSQL comme un remplacement pour
les bases de données relationnelles. Toutefois, en réalité, il peut y avoir de la place pour
ces deux types de technologies dans la plupart des entreprises. Les bases de données
SQL et NoSQL prennent en charge les informations d’une façon différente et prennent
en charge différents types de workloads.
Plutôt que de prendre la place des bases de données relationnelles, les bases de données
NoSQL permettent aux entreprises de viser de nouveaux objectifs, de relever de
nouveaux défis.

6. INCONVENIENTS DE LA BASE DE DONNEES NoSQL

Concernant la BD NoSQL, le langage de requêtes ne connait pas de standard, chacun
des systèmes de gestion de base de données possède son propre langage et son propre
système de gestion. Ceux-ci ne sont pas toujours performants et ne connaissent pas
encore toutes les capacités fonctionnelles des systèmes relationnels. Ces problèmes sont
souvent dus à la jeunesse du système. Il faut donc s’adapter à chacun des systèmes
utilisés. Dans ce cas-ci, la gestion de requêtes plus complexes devient plus difficile
qu’avec le SQL. De plus de nombreuses opérations de base de données relationnelles
ne sont pas encore disponibles. Il n’y a pas également d’intégrité de données, comme
déjà mentionné, et cela peut représenter un inconvénient pour beaucoup de types
d’applications.
Du point de vu de la sécurité, il n’existe pas de sécurité du serveur client lors des
communications et parfois pas d’authentifications. Certains systèmes ont un login et un
mot de passe qui sont stockés dans des fichiers internes donc offrent peu de sécurité.
Les systèmes NoSQL ne sont pas matures, et sont en constante évolution. Ce qui offre
une quantité de désavantages, du moins, actuellement.
Les bases NoSQL nécessitent beaucoup de stockage en espace disque. On peut le
comprendre du fait qu’il n’y ait pas de relation entre les tables, et que les documents
contiennent souvent l’intégralité des données à travailler. Une base NoSQL sera
susceptible de peser beaucoup plus lourd que les mêmes données stockées dans une
base relationnelle bien normalisée .Cela ne gêne pas les développeurs et utilisateurs des
bases NoSQL car l’absence de jointures leur paraît un immense pas en avant vers les
performances et la simplicité. De plus, le stockage de masse étant relativement
accessible, les tailles importantes de données ne sont plus gênantes, en tout cas sur le
papier. Le problème des performances en NoSQL diffère radicalement de ce qu’il est
dans un SGBDR. Un moteur relationnel tente d’offrir les meilleures performances
possibles dans son contexte, en assurant une intégrité des données et une cohérence
transactionnelle. Le point de focalisation des performances dans un moteur relationnel
se situe au niveau des entrées-sorties.
Manipuler des données ne change pas tant les CPU, mais principalement le système de
stockage.
C’est autour de ce problème que ce sont construits les moteurs relationnels, en offrant
un modèle qui permet d’éviter toute redondance de données, en maintenant un cache
des données en mémoire (le buffer pool) et parfois en offrant des fonctionnalités de
compression à la volée des pages de données.

7. CHOIX DU NoSQL
A l’heure de la révolution du Web 2.0 et vu l’usage actuel d’Internet, le nombre de
données disponibles sur la toile augmente d’année en année de manière exponentielle.
Voici quelques exemples d’acteurs concernés par ces gros volumes de données.
Le réseau social Facebook c’est:
En fait, pour chaque minute qui passe sur Facebook :
Il y a 500 nouveaux utilisateurs Facebook.
100.000 demande d’amis sont envoyées.
243.000 photos sont mises en ligne sur Facebook.
50.000 liens sont partagés sur Facebook.
La célèbre plateforme de réseautage Twitter c’est :
500 millions de tweets sont publiés chaque jour.
Les tweets comprenant des images reçoivent 18 % de clics en plus, 89 % de mentions
J'aime en plus et 150 % de retweets en plus.
Quand ils posent une question, 60 % des clients attendent des marques qu'elles leur
répondent dans l'heure qui suit mais le délai moyen de réponse est de 1h24.
La longueur idéale d'un tweet est de : 100 caractères.
Le taux de clic est plus élevé le mercredi.
Le terme usuel pour définir ce type de données est « Big Data » (en français gros volume
de données).
Pour manipuler et stocker ces données, les professionnels ont longtemps misé sur les
outils traditionnels que sont les SGBD relationnels.
Malgré l’optimisation poussée au maximum de ceux-ci, les limites sont atteintes,
surtout en termes de performances quant à la rapidité de lecture et d’écriture des
données. En effet, garantir la cohérence des données coûte cher en temps de réponse et
est souvent incompatible avec les performances.
Ces problèmes de performance liés à l’augmentation de charge et de volumétrie de
données ne sont pas le fruit du hasard. En effet, les SGBD relationnels doivent respecter
les principes ACID.
Donc, il devient très difficile de faire du « Scale out » dans leur cas. Pour cela, il faudrait
que les données soient simultanément présentes sur tous les serveurs.
Prenons un exemple concret : une base de données qui effectuerait par exemple 1000
transactions par minute, dont chacune d’elle correspondrait à environ 2 Ko de données.
Répartissons-la sur 10 serveurs. Cela fait environ 300 Ko/s de communications à
envoyer entre les différents serveurs.
De plus, il faut prendre en compte la gestion de l’intégrité, de la cohérence et de la
disponibilité des données. Face à un tel trafic de données le système est alors incapable
de gérer la situation et s’écroule très rapidement.
Nous pouvons donc constater que les SGBD relationnels ne peuvent que difficilement
reproduire les mécanismes de répartition de charge dont sont capables les serveurs Web.
Afin de rester performant malgré l’augmentation de charge et de volumétrie de données,
la seule solution est de faire du « Scale in », c'est-à-dire opter pour l’obtention d’un
serveur de base de données fortement évolutif. Mais à quel prix ? Et surtout est-ce que
cette machine super puissante qui réglera tous les problèmes
Les bases de données relationnelles ont fondamentalement été conçues pour gérer des
charges de travail stables ainsi que l’extraction de données complexes, ce qui n’est plus
si fréquent dans les applications modernes. Pour ces dernières, la capacité à gérer de
grands ensembles de données tout en maintenant la rapidité et l’extensibilité est
devenue primordiale. C’est de ce constat qu’est né le mouvement NoSQL. Les SGBD
NoSQL sont basés sur des systèmes innovants permettant la « scalabilité » horizontale
et dont la plupart d’entre eux sont Open Source, ils sont conçus pour répondre à des
besoins spécifiques et assurer une extensibilité extrême sur de très grands ensembles de
données.