Bases de données relationnelles et leurs limites

Bases de données relationnelles et leurs limites

Le NOSQL

Introduction

Nous avons vu dans le chapitre précédent que le modèle relationnel a trouvé ses limites pour la gestion des données massives du Web qui a connu une révolution avec l’avènement des sites web à fort trafic tels que Facebook, Amazon et LinkedIn. Ces grands acteurs du web ont été rapidement limités par les dits systèmes pour deux raisons majeures :
– Les gros volumes de données.
– Les montées en charge.
N’ayant pas trouvé de solution sur le marché répondant à ces problèmes, ils décidèrent de développer chacun à l’interne leurs propres SGBD. Ces produits développés de manière distincte sont connus sous le nom de base de données NoSQL ou de base de données non relationnelle. Les besoins en performance, lors de traitement de gros volumes de données ainsi que d’augmentation de trafic, ne touchent pas seulement les fameux sites mentionnés ci-dessus, mais aussi de nombreuses entreprises de tous types d’industries confondues, c’est de ce constat qu’est né le mouvement NoSQL.
En 1998, le monde entend pour la première fois le terme NoSQL. Terme inventé et employé par Carlo Strozzi pour nommer son SGBD relationnel Open Source léger qui n’utilisait pas le langage SQL. Ironiquement, la trouvaille de M. Strozzi n’a rien à voir avec la mouvance NoSQL que l’on connaît aujourd’hui , vu que son SGBD est de type relationnel. En effet, c’est en 2009, lors d’un ras semblement de la communauté des développeurs des SGBD non-relationnels, que le terme NoSQL a été mis au goût du jour pour englober tous les SGBD de type non-relationnel [6].
La première partie de ce chapitre consistera à expliquer ce que sont les bases de données de type NoSQL, dans quel but que ce genre de base de données a vu le jour. Nous allons également voir de quelle manière ces type de base de données fonctionnent et sur quelles fondements elles s’appuient, ainsi que les avantages qu’une base de données de type NoSQL peut avoir en comparaison à une base de données relationnel standard.

La technologie NoSQL

NoSQL est une combinaison de deux mots : No et SQL. Qui pourrait être mal interprétée car l’on pourrait penser que cela signifie la fin du langage SQL et qu’on ne devrait donc plus l’utiliser. En fait, le « No » est un acronyme qui signifie « Not only », c’est-à-dire en français, « non seulement », c’est donc une manière de dire qu’il y a autre chose que les bases de données relationnelles [6].
NoSQL est un mouvement très récent, qui concerne esl 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étrimen de la cohérence. Alors que les bases de données relationnelles actuelles sont basées sur les propriétés ACID (Atomicité, Consistance ou Cohérence, Isolation etDurabilité).
En effet, 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 leur capacité à traiter de très grands volumes de données.

Pourquoi le NoSQL ?

C’est une évidence de dire qu’il convient de choisir la bonne technologie en fonction du besoin. Il existe cependant certains critères déterminants pour basculer sur du NoSQL :

Taille

Le NoSQL est conçu pour supporter un nombre importa nt d’opérations, de données, d’utilisateurs etc… C’est à cause de cette grande m asse de données que le système doit devenir distribué. Bien que tous les systèmes NoSQLne soient pas conçus pour cette problématique, il est possible de la résoudre sansproblème.

Performance en écriture

Celle-ci est l’intérêt principal du géant Google, acebook,F Twitter, gérant des masses des données qui augmentent considérablement chaqueannée exigeant un temps très important pour stocker ces données. En conséquence, l’écriture se doit être distribuée sur un cluster de machines, ce qui implique du MapReduce, la réplication, la tolérance aux pannes, et la cohérence.

Type de données flexibles

Les solutions NoSQL supportent de nouveaux types de données et c’est une innovation majeure. Les objets complexes peuvent être mappés ans trop de problèmes avec la bonne solution.

ACID

Bien que ce ne soit pas le but premier du NoSQL, il existe des solutions permettant de conserver certains (voire tous) aspects des propriétés ACID. Se référer au théorème CAP plus bas dans le manuscrit et aux propriétés BASE.

Simplicité de développement

L’accès aux données est simple. Bien que le modèle relationnel soit simple pour les utilisateurs finaux, il n’est pas très intuitif pour les développeurs puisque les données sont restituées selon la structure de la base [13] .

Scalabilité

La scalabilité est le terme utilisé pour définir aptitudel’ d’un système à maintenir un même niveau de performance face à l’augmentation de charge ou de volumétrie de données, par augmentation des ressources matérielles.
Il y a deux façons de rendre un système extensible : la scalabilité horizontale (externe) ainsi que la scalabilité verticale (interne).

Figur e II-1 : Scalabilité horizontale et verticale

Scalabilitéhorizontale

Le principe de la scalab ilité horizontale consiste à simplement rajouter des serveurs en parallèle, c’est la raison pour laquelle on parle de croissance externe. On part d’un serveur basique et on rajoute des nouveaux serveurs identiques afin de répondre à l’augmentation de la charge.

Scalabilitéverticale

Le principe de la scalabilité verticale consiste à modifier les ressources d’un seul serveur, comme par exemple le remplacement du CPU par un modèle plus puissant ou par l’augmentation de la mémoire RAM.La croissance interne consi ste au fait d’évoluer une machine dans le temps.
Le but des systèmes NoSQL est de renforcer la scalabilité horizontale, les SGBD NoSQL sont basés sur des sytè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 d données.

Théorème de C A

Le théorème de CAP est l’acronyme de « Coherence »,« Availability » et « Partition tolerance », aussi connu sous le nom de théorème deBrewer. Ce thé orème, formulé pa Eric Brewer en 2000 et démontré par S h Gilbert et Nancy Lych e n 2002, énonce une conjecture qui définit qu’il est impossible, sur un système informatique de calcul distribué, de garantir en même temps les trois contraintes suivantes :

Cohérence Cons(istency)

Tous les nœuds (serveurs) du système voient exactement les mêmes données au mê moment.

Disponibilité Av(ailability)

Garantie que toute requ ête reçoive uneréponse même si elle n’est pas actualisée.

Résistance au pa rtitionnemen (Partition tolerance)

Le système doit être en mesure de répondre de manière correcte à toutes requêtes dans toutes circonstances sauf en cas d’une panne générale du réseau . Dans le c s d’un partitionnement en sous -réseaux, chacun de ces sous-réseaux doit pouvoir fonctionner de manière autonome.
Figure II.2 : Théorème CAP
Dans un système distrib ué, il est impossible ʼobtenir ces 3 propriétés en ême temps, il faut en choisir 2 parmi les 3 :
– Les SGBDR assurent l es propriétés de Cohéren et de Disponibilité (Availability) => système AC
– Les SGBD « NoSQL » sont des systèmes CP (Cohére nt et Résistant a partitionnement) ou AP (Disponible et Résistant au partitionnement).
CP : Les données sont consistantes entre tous les nœuds et le système possède une tolérance aux pannes, mais il peut aussi subir des problèmes de latence ou plus généralement, de disponibilité.
AP : Le système répond de façon performante en plus d’être tolérant aux pannes.
Cependant rien ne garantit la consistance des données entre les nœuds.
CA : Les données sont consistantes entre tous les nœud s (tant que les nœuds sont en ligne). Toutes les lectures/écritures les nœuds con cernent les mêmes données. Mais si un problème de réseau apparait, certains nœuds seront désynchronisés au niveau des données (et perdront donc la consistance).
Nous ne pouvons en respecter seulement deux à la fois. Dans la majorité des systèmes se sont les propriétés A et P qui sont respectées.

Les propriétés BASE

Dans le premier chapitre consacré aux bases de données relationnelles, nous avons rappelé les propriétés ACID auxquelles doivent répondre les SGBD de type relationnel. Les SGBD NoSQL qui, selon le théorème CAP, privilégient la disponibilité ainsi que la tolérance à la partition plutôt que la cohérence, répondent aux propriétés de BASE.
Le principe de BASE est le fruit d’une réflexion menée par Eric Brewer Les caractéristiques de BASE sont fondées sur les limites que montrent les SGBD relationnelles. Voici sa description :

Basically Available (Disponibilité basique)

Même en cas de désynchronisation ou de panne d’un esd nœuds du cluster, le système reste disponible selon le théorème CAP.

Soft-state (Cohérence légère)

Cela indique que l’état du système risque de changer au cours du temps, sans pour autant que des données soient entrées dans le système.

Eventual consistancy (Cohérence à terme)

Cela indique que le système devient cohérent dans el temps, pour que pendant ce laps de temps, le système ne reçoive pas d’autres données [6].

Différents types de base dedonnées NoSQL

Les bases de données NoSQL ne sont plus fondées sur l’architecture classique des bases relationnelles. Quatre grandes catégorie se distinguent parmi celles- ci :

 Bases de données Orientées Clé / Vale

Les bases de données NoSQL de type clé / valeur s’articulent sur u ne architecture très basique. On peut les ap parenter à une sorte de HashMap, c’est-à-dire qu’une valeur, un nombre ou du texte est s tocké grâce à une clé, qui sera le seul moye n d’y accéde Leurs fonctionnalités sont to utautant basiques, car elles ne contiennent que les commandes élémentaires du CRUD.Cette approche permet d e conserver des performances élevées en lecture/écriture, car de simples accès disques sont effectués pour accéder aux données. Cela permet au données totalement hétérogènes entre elles d’être stockées. Comme les valeurs stockée sont de type simple (un entier, du texte, un tableau), c’est au développeur de gérer l façon dont elles sont sto ckées afin de pouvoir les récupéreLes base de type clé/va leur le plus utilisées sont Redis et Riak .

Bases de données Orientées Docume

Ces bases de donnéesso nt une évolution des bases de données de t ype cl-valeur. Ici les clés ne sont plus associées à des valeurs sous forme de bloc binaire mais à un document dont le format n’est pa s imposé. Il peut être de plusieurs types dif férents comme ar exemple du JSON ou du XML, pour autant que la base de donnée s soit en mesure de manipuler le format choisit afin de permettre des traitements sur les documents. Dans le cas contraire, cela équivaudrait à une base de données cl -valeur. Bien que les documents soient structurés, ce type de base est appelé « schemaless ». Il n’est donc pas nécessaire de définir les champs d’un document.
On retrouve principale ment MongoDB et CouchBase comme solutions basées sur le concept de base docume ntaire.

Bases de données OrientéeColonne

Les bases de données orientées colonn ont été conçues par les gé ants du web afin d faire face à la gestion et au traitement de gros vo lumes de donn ées. Elles intègren souvent un système de r equêtes minimalistes prochedu SQL.Bien qu’elles soient abondamment utilisées, il n’existe pas encore d e méthode officielle ni de règles définies p our qu’une ase de données orientée colo nn soit qualifiée de qualité ou non.Le principe d’une base de données colonne consiste dans leur stoc kage par colonne et non par ligne. C’est-à -dire que dans une base de données ori entée ligne (SGBD classique) on stocke les données de façon à favoris er les lignes en re groupant toutes les colonnes d’une même ligne ensemble. Les bases de données orientés colonne quant à elles vont stocker les données de façon à ce que to ute les données d ’une même colonne soient stockées ensemble. Ces bases peuvent évoluer avec le temps, que ce soit en nombre de lignes ou en nombre de colonnes. Autrement dit, et contrairement à une base de données relationnelle où les colonnes sont statiques et présentes pour chaque ligne, celles des bases de données orientées colonne sont dite dynamiques et présentes donc uniquement en cas de nécessité. De plus le stockage d’un « null » est 0[16]. Les bases les plus connues se basant sur ce concept sont HBase et Cassandra.

Table des matières

Introduction Générale
Chapitre 1 : Bases de données relationnelles et leurs limites
I. Introduction
II. Bases de données relationnelles
III. Propriétés ACID
III.1 Atomicity (Atomicité)
III.2 Consistancy (Cohérence)
III.3 Isolation (Isolation)
III.4 Durability (Durabilité)
IV. Limites des bases de données relationnelles
IV.1 Problème lié à l’application des propriétés ACID en milieu distribué
IV.2 Problème de requête non optimale dû à l’utilisation des jointures
IV.3 Problème lié à la gestion des objets hétérogènes
IV.4 Surcharge sémantique
IV.5 Types de données
IV.6 Langage de manipulation
IV.7 Incompatibilités de types (“impedance mismatch”)
IV.8 La pauvreté sémantique
IV.9 Le partitionnement de données
V. Conclusion
Chapitre II : Le NoSQL
I. Introduction
II. La technologie NoSQL
III. Pourquoi le NoSQL ?
III.1 Taille
III.2 Performance en écriture
III.3 Type de données flexibles
III.4 ACID
III.5 Simplicité de développement
III.6 Scalabilité
III.6.1 Scalabilité horizontale
III.6.2 Scalabilité verticale ..
IV. Théorème de CAP
IV.1 Cohérence (Consistency)
IV.2 Disponibilité (Availability)
IV.3 Résistance au partitionnement (Partition tolerance)
V. Les propriétés BASE
V.1 Basically Available (Disponibilité basique)
V.2 Soft-state (Cohérence légère)
V.3 Eventual consistancy (Cohérence à terme)
VI. Différents types de base de données NoSQL
VI.1 Bases de données Orientées Clé / Valeur
VI.2 Bases de données Orientées Document
VI.3 Bases de données Orientées Colonne
VI.4 Base de données Orientées Graphe
VII. Le requêtageNoSQL
VII.1 Etape de mapping
VII.2 Etape de Reduce
VIII. Les avantages du NoSQL
VIII.1 Plus évolutif
VIII.2 Plus flexible
VIII.3 Plus économique
VIII.4 Plus simple
IX. Conclusion
Chapitre III : Les solutions NoSQL étudiées
I. Introduction
II. Panorama des solutions NoSQL étudiées
II.1 MongoDB
II.1.1 Description
II.1.2 Architecture
II.2 CouchBase
II.2.1 Description
II.2.2 Architecture
II.3 Cassandra
II.3.1 Description
II.3.2 Architecture
II.4 Hadoop
II.4.1 Description
II.4.2 HBase
II.5 Redis
II.5.1 Description
II.5.2 Architecture
II.6 OrientDB
II.6.1 Description
II.6.2 Multi modèle
III. Conclusion
Chapitre IV : L’étude comparative
I. Introduction
II. Présentation de l’outil de comparaison
III. Présentation des versions des solutions NoSQL
III.1 Mise en place d’YCSB
III.1.1 Java
III.1.2 Maven
III.1.3 Git
III.1.4 YCSB
III.2 MongoDB
III.3 CouchBase
III.4 Cassandra
III.5 Hadoop
III.5.1 Groupe et utilisateur Hadoop
III.5.2 Configuration SSH
III.5.3 Installation
III.5.4 Mise à jour des fichiers de configuration Hadoop
III.6 HBase
III.7 Redis
III.8 OrientDB
IV. Présentation et analyse des résultats expérimentaux
IV.1 Chargement de données (LoadProcess)
IV.1.1 MongoDB
IV.1.2 CouchBase
IV.1.3 Cassandra
IV.1.4 HBase
IV.1.5 Redis
IV.1.6 OrientDb
IV.2 Exécution des Workloads
IV.2.1 Workload A (50% Read /50% Update )
IV.2.2 Workload B (95% Read, 5% Update)
IV.2.3 Workload C (100% Read)
IV.2.4 Workload D (5% Insert, 95% Read)
IV.2.5 Workload E (95% Scan, 5% Insert)
IV.2.6 Workload F (50% Read, 50% Read-Modify-Write)
IV.2.7 Workload G (5% Read, 95% Update)
IV.2.8 Workload H (100% Update)
IV.3 Récapitulatif de performance de l’ensemble des Workloads
V. Evaluation globale de MongoDB, CouchBase, HBase, Cassandra, Redis, OrientDB
VI. Conclusion
Conclusion Générale
Perspectives
Liste D’abréviations
Liste des Figures
Liste des Tableaux
Références Bibliographiques

Télécharger le rapport complet