Langages de manipulation des données relationnelles

Bases de données NoSQL

Face à l’évolution informatique dans la dernière décennie et notamment les grandes volumes de données échangés, les SGBDR classiques ont montré de très grandes faiblesses en matière de scalabilité et en montée en charge, ce qui a obligé les grands acteurs du web à chercher d’autre solutions. Les systèmes NoSQL viennent, justement, pour accomplir cette mission. Dans ce chapitre nous exposons les solutions NoSQL, leur émergence, les différents types, leurs avantages et leurs limites ainsi qu’un bref aperçu des solutions NoSQL les plus répandus dans le marché.

Les bases de données relationnelles se prêtent mal aux exigences des applications massivement parallèles exploitant de grandes quantités de données. Les bases de données NoSQL (Not Only SQL) marquent une rupture assez brutale avec la manière de concevoir les schémas de données que l’on pratiquait depuis déjà quelques décennies. Spécifiquement dédiées aux applications orientées Internet, les bases de données NoSQL pallient ainsi aux difficultés de la gestion de bases de données relationnelles un peu trop conséquentes et réparties sur plusieurs machines [9]. 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 [10]. Le terme NoSQL est pour la première fois proposé par Carlo Strozzi en 1998, lors de la présentation de son système de gestion de bases de données relationnelles open source. Il l’a appelé ainsi à cause de l’absence d’interface SQL pour interagir avec les bases de données. Les bases NoSQL peuvent bien entendu être utilisées avec du SQL, c’est pourquoi Strozzi précise qu’il est plus pertinent d’utiliser le terme « NoREL » car ces dernières s’abstraient du côté relationnel des données. Le mot réapparu en 2009 lorsqu’Eric Evans l’utilisa pour caractériser le nombre grandissant de bases de données non-relationnelles lors d’une présentation sur les bases de données distribuées open source [11].

Emergence du NoSQL

Le langage SQL, en tant que langage d’interrogation standardisé, règne en maître sur les bases de données relationnelles depuis quelques décennies.SQL est un langage d’interrogation dit de 4ème génération standardisé. Les bases de données relationnelles, étroitement associées au langage SQL, comportent intrinsèquement un certain nombre de règles d’organisation : les formes normales par exemple, pour garantir la robustesse du schéma relationnel. Ces règles sont particulièrement efficaces pour un mode de gestion de données classique, mais elles s’avèrent être un véritable obstacle pour le déploiement, le stockage et l’analyse des bases de données redondantes de grande envergure, comme le nécessite le Big Data. Il faut donc adopter un autre mode de gestion des données pour faciliter les analyses massives [9]. En effet, Il existe cependant certains critères déterminants pour basculer vers le NoSQL :

Bases de données orientée documents

Les systèmes de type documentaire sont composés de collections de documents. La représentation en document est une sorte d’extension du concept clé/valeur. La valeur est représentée sous forme de document contenant des données. Des champs et des valeurs associées composent le document. Ces valeurs associées peuvent soit être de type simple (integer, string, date, …), soit de type composé, c’est-à-dire de plusieurs couples clé/valeur. Bien que les documents soient organisés de manière hiérarchique à l’image de ce que permettent les fichiers de type XML ou JSON, ces bases sont dites «Schémaless», ce qui signifie sans schéma défini. Cela veut tout simplement dire qu’il n’est pas nécessaire de définir au préalable les champs dans le document : on peut très bien en rajouter en cours de développement. Les documents peuvent être très différents les uns des autres au sein de la base [10].

Evaluation globale des tests

Les résultats expérimentaux des différents tests effectués sous forme de charges de travail, ont permis d’évaluer et comparer les deux types de SGBD NoSQL (MongoDB) et SQL (MySQL) en s’appuyant sur le temps d’exécution des différents Workloads, en variant à chaque fois le nombre d’enregistrements chargés et le nombre d’opérations à exécuter. Sur le premier test de chargement de données, MongoDB a été très performante en inscrivant de grands écarts par rapport à MySQL. Le plus grand écart a été inscrit dans le chargement le plus lourd à savoir 600 milles enregistrements avec 147 secondes pour MongoDB contre 11 heures pour MySQL. Cette contre-performance de MySQL est expliquée par le fait que ce système n’est pas conçu pour faire des importations ou des insertions de grands volumes de données, contrairement à MongoDB. Les différents résultats obtenus après exécution des Workloads, ont montré que MongoDB est très performante par rapport à MySQL dans toutes les charges de travail qui contiennent des opérations d’écriture dans la base de données à savoir : A (50% mise à jour), F (50% lecturemodification- écriture), G(95% lecture-modification-écriture) et H (100% lecturemodification- écriture). De grands écarts ont été inscrits entre les deux bases de données en faveur de MongoDB, particulièrement, lorsqu’on a exécuté 1000 opérations, ou MySQL a réalisé jusqu’à 48 fois le temps réalisé par MongoDB (69,47 sec contre 1,45 sec). Nous pouvons justifier cette performance de MongoDB ainsi que la lenteur de MySQL par les exigences relatives aux propriétés ACID imposées par les SGBD relationnels (verrou de la table en cas d’écriture en empêchant les opérations de lecture), contrairement aux systèmes NoSQL qui se sont libérés de ces contraintes.

Les mêmes comportements des 2 bases de données lors des charges A, F, G et H sont réitérés pour les charges B et D, puisque les mêmes évolutions de performances sont soulignées. Notons que les charges B et D combinent entre des opérations de lecture et de mise à jour, ces dernières sont ralenties par le processus de vérification de l’intégrité et la cohérence de la base exigés dans les systèmes transactionnels comme MySQL. En revanche, MySQL a produit de bons résultats dans l’exécution des Workloads comportant des rapports d’opérations de lecture supérieurs à l’écriture, dans des bases de données qui ne contiennent pas plus de 10000 enregistrements, mais au-delà de ce volume, ses performances se dégradent, contrairement à MongoDB où les résultats ont préservés une certaine stabilité en gardant de bonnes performances, quel que soit le nombre d’enregistrements chargés, ceci peut être confirmé par les résultats obtenus en exécutant les charges de travail C et E. Après la lecture des résultats obtenus en exécutant les huit charges de travail, nous pouvons conclure que la solution SQL MySQL a été adéquate pour des opérations purement lecture dans des environnements de petites échelles, mais dans des environnements à grandes échelles ou pour des opérations de lecture/écriture, il est très intéressant d’adopter la solution NoSQL MongoDB.

Conclusion générale

L’explosion de la volumétrie des données, qui reflète le changement d’échelle des volumes, nombres et types, a imposé aux différents chercheurs depuis quelques années, de nouveaux défis et les a poussé à concevoir de nouvelles technologies et chercher les meilleures solutions pour contenir et traiter ces volumes énormes de données. Cette nouvelle ère informatique, avec ses nouvelles exigences, a conduit aux nouveaux concepts Big Data et Cloud Computing qui ont concouru à l’émergence du mouvement NoSQL. Beaucoup d’utilisateurs des SGBD relationnels classiques dits « SQL » veulent basculer vers ces nouvelles solutions « NoSQL » pour anticiper l’explosion de leurs données dans le futur. Pour justifier et motiver un tel basculement du SQL vers du NoSQL, nous avons développé, dans le cadre de notre PFE, une étude comparative des performances entre deux types de bases de données d’architectures et de générations différentes : MySQL en tant que modèle relationnel connu par SQL et MongoDB en tant que modèle non relationnel, représentant la nouvelle ère NoSQL.

Les différents tests effectués sous forme de charges de travail étaient basées sur le temps d’exécution pour évaluer les performances. Ces tests ont été soumis à plusieurs configurations et paramétrages : 1. Le premier critère concernait la nature des opérations à exécuter (lecture, mise à jour,…) 2. Le deuxième concernait le nombre de lignes insérés (1000, 5000, 10000 ou 600000) 3. Le troisième concernait le nombre d’opérations effectuées (100 ou 1000). Bien que les résultats expérimentaux obtenus dans notre étude, soient en faveur de la solution NoSQL MongoDB par rapport à la base de données relationnelle MySQL en termes de performance, la tendance vers une favorisation d’une solution NoSQL et l’abandon du relationnel est loin d’être indiscutable. On peut retenir aussi que le choix d’utilisation d’un SGBD dépend d’un ensemble de paramètres en relation avec l’environnement dans lequel les données sont exploitées. En effet le type de données et le type des traitements effectués sur ces données sont des indices importants pour définir la solution à adopter, ainsi que les besoins spécifiques qui peuvent varier d’une entreprise à une autre. Citons ces principaux indices :

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction Générale
Chapitre 1Bases de données relationnelles
Introduction
I.1 Généralités sur le modèle relationnel
I.1.1 Définitions
I.1.1.1Base de données
I.1.1.2Table (ou Relation) et Attribut
I.1.1.3Clés
I.1.2 Système de gestion de base de données (SGBD
I.1.2.1 Définition
I.1.2.2 Objectifs
I.1.2.3Quelques SGBD connus et utilisés
I.2 Langages de manipulation des données relationnelles
I.2.1 Calcul relationnel
I.2.2 Langages algébriques
I.2.3Langage SQL (Structured Query Language
I.3 Principe d’ACID
I.3.1 Atomicity (Atomicité
I.3.2 Consistency (Cohérence
I.3.3 Isolation
I.3.4 Durability (Durabilité
I.4 Limites des SGBD relationnels
Conclusion
Chapitre 2 Bases de données NoSQL
II.1.Généralités
II.2.Emergence du NoSQL
II.3.Défis et exigences
II.4.Théorème CAP
II.5.Propriétés B.A.S.E
II.6.Types de bases de données NoSQL
II.6.1 Bases de données orientée clé-valeur
II.6.2 Bases de données orientée colonnes
II.6.3 Bases de données orientée documents
II.6.4 Bases de données orientée graphes
II.7Avantages et inconvénients des bases de données NoSQL
II.7.1 Avantages
II.7.2 Inconvénients
Conclusion
Chapitre 3 Etude comparativeMySQL vs MongoDB
Introduction
III.1 Présentation du benchmark et les SGBD étudiés
III.1.1Outil de comparaison YCSB
III.1.2 MySQL
III.1.3 MongoDB
III.1.3.1 Modèle de données
III.1.3.2 Architecture
III.2 Installations et configurations
III.2.1 Pré-requis
III.2.2 Installation du benchmark YCSB
III.2.3 Installation et configuration de MySQL
III.2.2 Installation MongoDB
III.3Résultatsexpérimentaux
III.3.1Chargement des données
III.3.2Exécution des Workloads
III.3.2.1Workload A (50% Read 50% Update
III.3.2.2Workload B (95 % Read, 5% Update
III.3.2.3Workload C (100 % Read
III.3.2.4Workload D (95 % Read, 5% Insert
III.3.2.5 Workload E (95% Scan, 5% Insert
III.3.2.6Workload F (50 % Read, 50% R.M.W
III.3.2.7Workload G (5 % Read, 95 % R.M.W
III.3.2.8Workload H (100 % R.M.W
III.3.3 Evaluation globale des tests
Conclusion Générale
Références bibliographiques
Liste de figures