I

Epigraphe
 II

DEDICACE
 III

REMERCIEMENTS
 IV

LISTE DES TABLEAUX

Tableau 1: Création utilisateur Mongo DB...............................................................................42

Tableau 2: Connexion à Mongo DB.........................................................................................42
Tableau 3: Commande principales de mongofiles....................................................................43
Tableau 4 Liste des bases de données disponibles....................................................................45
Tableau 5: Sélectionnez une base de données..........................................................................46
Tableau 6: Afficher toutes les collections.................................................................................46
Tableau 7: Création d'une collection.........................................................................................46
Tableau 8: insertion d'un seul enregistrement...........................................................................47
 V

LISTE DES FIGURES

Figure 1: Sous-systèmes d’un SGBD.........................................................................................9
Figure 2: Problème lié aux propriétés ACID en milieu distribué.............................................13
Figure 3: Limites liées au Théorème du CAP...........................................................................15
Figure 1: Les contraintes du NoSQL........................................................................................20
Figure 2: CA Cohérence + Disponibilité..................................................................................20
Figure 3: AP Disponibilité + Distribution................................................................................21
Figure 4: CP Cohérence + Distribution....................................................................................21
Figure 5: Transaction Big Data avec les interactions et les observations.................................23
Figure 6: Table d’une BDR.......................................................................................................28
Figure 7: Table d’une BD NoSQL orientée colonne................................................................29
Figure 8: Modèle clé-valeur......................................................................................................32
Figure 9: Structure de base d’une BD orientée graphe.............................................................33
Figure 1: Exemple Document dans une collection...................................................................36
Figure 2: Collection..................................................................................................................37
Figure 3: Schématisation d'un objet JSON...............................................................................39
Figure 4: Schématisation d'un tableau JSON............................................................................39
Figure 5: Schématisation des différents types de valeur contenue dans un document JSON...39
Figure 6: Indexe Mongo DB.....................................................................................................40
Figure 7: Vision des options disponibles de Compass..............................................................44
Figure 8: Illustration Mongo Shell............................................................................................48
 1

INTRODUCTION
Le terme « NoSQL » a été inventé en 2009 lors d’un événement sur les bases de
données distribuées. Le terme est vague, incorrect (certains moteurs NoSQL utilisent des
variantes du langage SQL, par exemple Cassandra), mais présente l’avantage d’avoir un effet
marketing et polémique certain. Dans ce projet, nous allons aborder les caractéristiques
générales des moteurs NoSQL, historiquement, conceptuellement et techniquement, en regard
des bases de données relationnelles, mais aussi indépendamment de cette référence.

Les défenseurs du mouvement NoSQL le présentent comme une évolution bienvenue

de l’antique modèle relationnel. Ses détracteurs le considèrent plutôt comme une régression.
Le modèle relationnel est apparu dans les années 1970, devenant rapidement le modèle
dominant, et jamais détrôné depuis, un peu comme les langages impératifs (comme C++ et
Java) dans le domaine de la programmation. Dans ce chapitre, nous allons présenter un bref
historique de l’évolution des bases de données informatiques, pour mieux comprendre d’où
viennent les modèles en présence, pourquoi ils ont vu le jour et ont ensuite évolué.

C’est l’apparition du Big Data et de ses enjeux en termes de systèmes de gestion de

bases de données. Comme nous pouvons le savoir, le Big Data est un terme émergent et
suscitant un certain engouement.

Nous avons donc souhaité porter notre intérêt sur cette thématique en tentant de
comprendre dans un premier temps à quoi renvoie ce terme qui semble englober de
nombreuses réalités différentes et qui est sujet à un certain engouement médiatique.

Pour ce projet nous voulons comprendre les bases de données susceptibles à gérer
ces big data dit NoSQL.

Ce projet s’ajoute aux différents travaux de recherche dans le domaine des bases de
données NoSQL. Ces nouveaux modèles proposent une nouvelle manière d’organisation et de
stockage de données conçue principalement pour remédier aux contraintes imposées par les
propriétés ACID sur les modèles relationnels. Le NoSQL apporte une nouvelle façon
d’appréhender la modélisation des données.

Dans l’actuel projet, nous allons essayer de brosser succinctement sur les bases
données NoSQL qui est devenu un mouvement dans le monde des bases des données, et
savoir de quoi s’agit-il réellement.
 2

Nous passerons en revue quelques bases des données NoSQL, le schéma utilisé, le
langage et le mode de fonctionnement.

De ce fait notre projet sera subdivisé en 3 chapitres comme suit :

 Chapitre 1 : Aperçu sur le BIG DATA

 Chapitre 2 : Notion sur Les bases des données NoSQL
 Chapitre 3 : Les solutions NoSQL étudiées
 3

CHAPITRE I. LES BASES DE DONNEES RELATIONNELLES

I.1. Introduction
Le modèle relationnel a été introduit pour la première fois par Ted Codd du centre de
recherche d’IBM en 1970 dans un papier désormais classique, et attira rapidement un intérêt
considérable en raison de sa simplicité et de ses fondations mathématiques.

Dans ce modèle, les données sont représentées par des tables, sans préjuger de la
façon dont les informations sont stockées dans la machine. Les tables constituent donc la
structure logique du modèle relationnel, d’autre part ces données sont gérées par un système
de gestion de bases de données relationnelle (Relational DataBase Management System,
RDBMS), qui représente un système intégré pour la gestion unifiée des bases de données
relationnelles, il est constitué d’un composant de stockage et d’un composant de gestion de
données.

L’interface standard pour une base de données relationnelle est le langage SQL
(Structured Query Language) considéré comme le langage de manipulation des données
relationnelles le plus utilisé aujourd’hui. Il possède des caractéristiques proches de l’algèbre
relationnelle (jointures, opérations ensemblistes) et d’autres proches du calcul des tuples
(variables sur les relations). SQL est un langage redondant qui permet souvent d'écrire les
requêtes de plusieurs façons différentes.

I.2. Principe de fonctionnement de SGBD relationnel

Le SGBD est un ensemble de logiciels informatiques qui sert à manipuler les bases
de données, à effectuer des opérations ordinaires telles que consulter, modifier, construire,
transformer, copier, sauvegarder ou restaurer des bases de données.

Le SGBD peut se décomposer en trois sous-systèmes :

 4

Figure 1: Sous-systèmes d’un SGBD

1. Le système de gestion de fichiers : permet de stocker les informations sur un support

physique.
2. Le SGBD interne : gère l’ordonnancement des informations.
3. Le SGBD externe : présente l’interface de l’utilisateur.

I.3. Propriétés ACID

Les propriétés ACID sont les quatre principaux attributs d'une transaction de données
sur lesquelles s'appuie ce type de base de données. Il s'agit là d'un des concepts les plus
anciens et les plus importants du fonctionnement des bases de données relationnelles, il
spécifie quatre buts à atteindre pour toute transaction :

I.3.1. Atomicity (Atomicité)

Lorsqu’une transaction est effectuée, toutes les opérations qu’elle comporte doivent
être menées à bien : en effet, en cas d’échec d’une seule des opérations, toutes les opérations
précédentes doivent être complètement annulées, peu importe le nombre d’opérations déjà
réussies. En résumé, une transaction doit s’effectuer complètement ou pas du tout. Voici un
exemple concret : une transaction qui comporte 3000 lignes qui doivent être modifiées, si la
modification d’une seule des lignes échoue, alors la transaction entière est annulée.
L’annulation de la transaction est toute à fait normale, car chaque ligne ayant été modifiée
peut dépendre du contexte de modification d’une autre, et toute rupture de ce contexte
pourrait engendrer une incohérence des données de la base.
 5

I.3.2. Consistency (Cohérence)

Chaque transaction doit préserver la cohérence de données ; Cela signifie que les
modifications apportées à la base doivent être valides, en accord avec l'ensemble de la base et
de ses contraintes d'intégrité. Si un changement enfreint l'intégrité des données, alors soit le
système doit modifier les données dépendantes, comme dans le cas classique d’une
suppression en cascade, soit la transaction doit être interdite.

La notion de cohérence est importante, et c’est l’un des éléments les plus sensibles
entre le monde du relationnel et le monde NoSQL (qu’on va voir par la suite). Les SGBDR
imposent une règle stricte : d’un point de vue transactionnel, les lectures de données se feront
toujours sur des données cohérentes. Les modifications en cours sont donc cachées, un peu
comme sur la scène d’un théâtre : chaque acte d’une pièce de théâtre se déroule intégralement
sous l’oeil des spectateurs. Si le décor va être changé, le rideau se baisse, les spectateurs
doivent attendre, les changements s’effectuent derrière le rideau et lorsque le rideau se lève, la
scène est de nouveau dans un état totalement cohérent. Les spectateurs n’ont jamais eu accès à
l’état intermédiaire. Néanmoins, cet état intermédiaire peut durer longtemps, pour deux
raisons : plusieurs instructions de modifications de données peuvent être regroupées dans une
unité transactionnelle, qui peut être complexe. Ensuite, un SGBDR fonctionnant de façon
ensembliste, une seule instruction de mise à jour, qui est naturellement et automatiquement
transactionnelle, peut très bien déclencher la mise à jour de milliers de ligne de table. Cette
modification en masse conservera des verrous d’écriture sur les ressources et écrira dans le
journal de transaction ligne par ligne. Tout ceci prend, bien évidemment, du temps.

Ce respect strict de la cohérence est concevable si nous restons sur le même serveur,
mais dès que nous adoptons une distribution de données, il commence à poser de sérieux
problèmes. La modification des données qui résident sur plusieurs serveurs n’est aujourd’hui
possible qu’à partir d’un mécanisme nommée transaction distribuée.
 6

I.3.3. Isolation (Isolation)

Chaque transaction voit l’état du système comme si elle était la seule à manipuler la base de
données, c'est-à-dire si les transactions sont lancées en même temps, on n’aura jamais des
interférences entre elles. Par exemple si pendant la transaction T1, une transaction T2 est
exécutée en même temps, T1 ne doit pas la voir, tout comme T2 ne doit pas voir T1.

Une transaction isole les données accédées pour éviter une corruption de donnée qui peut être
causée par une modification simultanée de la même donnée par plusieurs utilisateurs
concurrents.

Ce verrouillage provoque des attentes dans certains moteurs relationnels, comme Microsoft
SQL Server. D’autres moteurs comme Oracle utilisent des techniques qui diminuent le
verrouillage en maintenant la dernière version transactionnellement cohérente antérieure à la
modification afin de permettre des lectures même en cas de modifications.

En revanche, deux tentatives d’écriture simultanée sont interdites. Cette isolation est
maintenue par la pose de verrous sur les ressources accédées. La gestion des verrous est la
responsabilité de moteurs de stockage. Les problématiques de verrouillage sont relativement
complexes.

I.3.4. Durability (Durabilité)

Toutes les transactions sont lancées de manière définitive. Une base de données ne
doit pas afficher le succès d’une transaction pour ensuite remettre les données modifiées dans
leur état initial. Pour ce faire, toute transaction est sauvegardée dans un fichier journal afin
que, dans le cas où un problème survient empêchant sa validation complète, elle puisse être
correctement terminée lors de la disponibilité du système.
 7

I.4. Limites des bases de données relationnelles

Les bases de données existent maintenant depuis environ 56 ans et le modèle

relationnel depuis environ 46 ans, pendant plusieurs décennies, ce modèle bien très puissant,
représentait la solution parfaite pour les différents acteurs dans le domaine de gestion des
données, néanmoins ces architectures ont atteints leurs limites pour certains services ou sites
manipulant de grandes masses de données, tels que Google, Facebook, etc. En effet ce genre
de sites possède plusieurs millions voire des milliards d’entrées dans leurs bases de données et
tout autant de visites journalières, en conséquence les données sont distribuées sur plusieurs
machines, de plus pour des raisons de fiabilité ces bases de données sont dupliquées pour que
le service ne soit pas interrompu en cas de panne.

Malheureusement le modèle relationnel présente quelques problèmes liés à ce

passage à l’échelle tel que :

I.4.1. Problème lié à l’application des propriétés ACID en milieu distribué

Une base de données relationnelle est construite en respectant les propriétés ACID
(Atomicité, Cohérence, Isolation, Durabilité). Ces propriétés bien que nécessaires à la logique
du relationnel nuisent fortement aux performances de cohérence.

En effet, la cohérence est très difficile à mettre en place dans le cadre de plusieurs
serveurs (environnement distribué), car pour que ceux doivent être des miroirs les uns des
autres. Deux problèmes qui émergent :

• Le coût en stockage est énorme car chaque donnée est présente sur chaque serveur.

• Le coût d’insertion/modification/suppression est très grand, car on ne peut valider une

transaction que si on est certain qu’elle a été effectuée sur tous les serveurs, du coup le
système fait patienter l’utilisateur durant ce temps.
 8

Figure 2: Problème lié aux propriétés ACID en milieu distribué

I.4.2. Problème de requête non optimale dû à l’utilisation des jointures

Imaginons une table contenant toutes les personnes ayant un compte sur Facebook,
soit plus de 800 millions, les données dans une base de données relationnel classique sont
stockées par lignes, ainsi si on effectue une requête pour extraire tous les amis d’un utilisateur
donné, il faudra effectuer la jointure entre la table des usagers (800 millions) et celle des
amitiés (soit au moins 800 millions chaque usager ayant au moins un ami) puis parcourir le
produit cartésien de ces deux tables. De ce fait, on perd en performances car il faut du temps
pour stocker et parcourir une telle quantité de données. A cause de ces limitations, de
nouvelles technologies ont vues le jour pour répondre à ces besoins, c’est ainsi qu’a été
inventé d’autres architectures, celles-ci se nomment dans leur ensemble les bases NoSQL qui
seront abordées plus loin. Malgré l’appellation NoSQL, ce n’est pas tant le langage SQL en
lui-même qui est inadapté mais les grands principes sur lesquels sont construits le modèle
relationnel et transactionnel. En effet, les bases de données relationnelles mettent à la
disposition des développeurs un certain nombre d’opérations en d’opérations en fonction des
relations entre les tables :
 9

• un système de jointure entre les tables permettant de construire des requêtes

complexes faisant intervenir plusieurs entités (les tables en l'occurrence).

• un système d’intégrité référentielle permettant de s’assurer que les liens entre les
entités sont valides.

La mise en œuvre de tels mécanismes a un coût considérable dès lors que l’on se
trouve dans le contexte d’un système distribué ou avec de gros volumes de données. Sur la
plupart des SGBD relationnels, il convient de s’assurer en permanence que les données liées
entre elles sont placées sur le même nœud du serveur. Lorsque le nombre de relations au sein
d’une base augmente, il devient de plus en plus difficile de placer les données sur des nœuds
différents du système. Nous verrons que les systèmes NoSQL règlent de différentes manières
ce problème selon les besoins.

I.4.3. Problème lié au Théorème du CAP

Il existe par ailleurs, une limitation plus théorique à ce que peuvent réaliser les bases
de données relationnelles distribuées qui est décrite par le théorème de CAP (Consistency,
Availibility and Partition tolerence). Celui-ci énonce trois grandes propriétés pour les
systèmes distribués à savoir: La Cohérence ou Consistency qui demande que tous les nœuds
du système voient exactement les mêmes données au même moment ; La Disponibilité ou
Availability qui requiert que la perte de nœuds n'empêche pas les survivants de continuer à
fonctionner correctement ;La Résistance au partitionnement ou partition tolérance qui veut
qu’aucune panne moins importante qu’une coupure totale du réseau ne doit empêcher le
système de répondre correctement, c’est-à-dire qu’en cas de morcellement en sous-réseaux,
chacun doit pouvoir fonctionner de manière autonome.

Le théorème de CAP stipule qu’il est impossible d’obtenir ces trois propriétés en
même temps dans un système distribué et qu'il faut donc en choisir deux parmi les trois types
de systèmes à savoir: AC, AP, CP. S’agissant des systèmes AC, il s’agit des bases de données
relationnelles implémentant les propriétés de cohérence et de Disponibilité (ce sont des
systèmes AC). Les bases de données NoSQL sont généralement des systèmes CP (Cohérent et
Résistant au partitionnement) ou AP (Disponible et Résistant au partitionnement).
 10

Figure 3: Limites liées au Théorème du CAP

Dans cette dernière catégorie, les utilisateurs n'ont pas forcément tous la même vue à
un moment donné, mais est-ce vraiment une nécessité ? Dans certains cas oui mais souvent
non. Si vous faites une recherche sur Google ou Facebook et que vous n'avez pas exactement
la même réponse qu'un autre utilisateur cela parait moins important que de ne pas avoir de
résultats de recherche du tout (pas de haute disponibilité)! Souvent, si la consistance est
importante pour certaines données, il est d'usage de les isoler dans des bases relationnelles et
de placer les autres données dans des bases dites NoSQL. Certaines données nous paraissent
logiques d'être consistantes mais cela est souvent du à notre inertie d’esprit. Prenons le cas
d'une valeur indiquant le stock d'un article. Si deux serveurs ont des valeurs non consistantes,
il peut arriver qu'un serveur considère qu'il en reste un alors qu'un autre qui a été mis à jour,
sait qu'il n'en reste plus. Lorsque vous faites un achat et si par malchance vous achetez un
livre qui n'est plus en stock, le site marchand à deux possibilités : vous rembourser ou
réapprovisionner. Dans cet exemple comme pour la réservation des billets d’avion, vous
pouvez avoir des désagréments mais cela arrive d’ailleurs très rarement. Il ne vous reste plus
qu’à choisir entre :

• Acheter sur un site très lent (disons quelques dizaine de secondes de latence
par page) mais où le stock est mis à jour en temps réel entre les milliers de
serveurs pour tous les produits du site.
 11

• Et une éventualité de stock non cohérente mais une haute disponibilité, les
sites ont fait leur choix

La société Amazon a d'ailleurs constaté qu'un dixième de seconde de latence lui fait
diminuer les ventes de 1%, et Google a remarqué qu'une demi seconde de latence fait chuter
le trafic d'un cinquième. Le fait d'accepter des données inconsistantes est connu sous le nom
de BASE (Basically Available, Soft-state, Eventually consistent) qui est en fait, l'opposé des
propriétés ACID. Le fait d'accepter que seuls deux des trois principes du théorème de CAP
peuvent être satisfaits en même temps montre à suffisance que les bases de données
relationnelles connaissent une limite théorique car elles ne couvrent qu’un cas (ce sont les
systèmes AC) parmi les trois types de systèmes à savoir : AC, AP et PC.

I.4.4. Problème lié à la gestion des objets hétérogènes

« Le stockage distribué n’est pas la seule contrainte qui pèse à ce jour sur les
systèmes relationnels » disait Carl STROZZI. Au fur et à mesure du temps, les structures de
données manipulées par les systèmes sont devenues de plus en plus complexes avec en
contrepartie des moteurs de stockage évoluant peu. Le principal point faible des modèles
relationnels est l’absence de gestion d’objets hétérogènes ainsi que le besoin de déclarer au
préalable l’ensemble des champs représentant un objet. Pour répondre au besoin des objets
hétérogènes non pré déclarés, on a vu apparaître des modélisations complexes sur le plan
algorithmique comme le modèle Entity-Attribute-Value permettant de séparer un objet et ses
champs. Ces modèles, quoique répondant au besoin de flexibilité des applications modernes,
présentent un inconvénient majeur qui est leur très faible niveau de performance. La majeure
partie des outils développés dans le cadre de la mouvance NoSQL permettent l’utilisation
d’objets hétérogènes apportant comparativement une bien plus grande flexibilité dans les
modèles de données ainsi qu’une simplification de la modélisation.
 12

I.5. Conclusion
Les technologies de bases de données relationnelles et transactionnelles, qu’on
pourrait nommer par « Technologies SQL », sont devenues au fil du temps une référence
absolue pour l’industrie des bases de données.

On peut considérer SQL comme un standard de fait pour toute problématique ayant
trait au stockage et à la manipulation de données. Pourtant, un certain nombre de limitations
importantes sont apparues au fil des années et l’absolu est devenu obsolète.

Dans le scénario de l'Internet actuel, où d'importants volumes de données structurées

de façon variable doivent être traités rapidement, de nouvelles méthodes ont été élaborées
pour pallier les insuffisances des bases de données SQL et surtout en termes d’évolutivité.
 13

CHAPITRE II. LES BASES DE DONNEES NoSQL

II.1. Introduction
Comme vu précédemment, 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.

NoSQL est un mouvement très récent, ce n’est qu’en 2009, lors d’un rassemblement
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. 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 et
le Big Data. Les axes principaux du NoSQL sont une haute disponibilité et un partitionnement
horizontal des données, au détriment 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 et Durabilité).

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. Leurs principaux avantages sont leurs performances et
leur capacité à traiter de très grands volumes de données.
 14

II.2. Théorème de CAP

Avant d'aborder les différents types de base de données NoSQL, il est important
d'expliquer le théorème CAP. Alors que le modèle relationnel obéit aux formes normales et
aux règles ACID, les bases de données NoSQL suivent le théorème CAP. Le théorème de
CAP est l’acronyme de « Coherence », « Availability » et « Partition tolerance », aussi connu
sous le nom de théorème de Brewer. Ce théorème, formulé par Eric Brewer en 2000 et
démontré par Seth Gilbert et Nancy Lych en 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
Tous les nœuds (serveurs) du système voient exactement les mêmes données au
même moment.
 Disponibilité
Garantie que toute requête reçoive une réponse même si elle n’est pas actualisée.
 Résistance au partitionnement
Le système doit être en mesure de répondre de manière correcte à toutes requêtes
dans toutes les circonstances sauf en cas d’une panne générale du réseau. Dans le cas d’un
partitionnement en sous-réseaux, chacun de ces sous-réseaux doit pouvoir fonctionner de
manière autonome.
Dans un système distribué, il est impossible d’obtenir ces 3 propriétés en même
temps, il faut en choisir 2 parmi 3.
Les bases de données relationnelles implémentent les propriétés de Cohérence et de
Disponibilité (système AC). Les bases de données NoSQL sont généralement des systèmes
CP (Cohérent et Résistant au partitionnement) ou AP (Disponible et Résistant au
Partitionnement). De ce fait, le NoSQL concentrent plus sur la résistance au morcellement,
afin de garantir une disponibilité en tout temps et par conséquent abandonnent la cohérence.
 15

Figure 4: Les contraintes du NoSQL

Les trois options qui peuvent exister sont :

1. Marginaliser la tolérance à la distribution (CA) : le système ne prend pas en
considération la distribution des données sur un réseau. C’est le cas typique des
SGBDRs.

Figure 5: CA Cohérence + Disponibilité

Dans la Figure ci-haut, les deux requêtes de lecture concurrente sur une même
donnée, retournent le même nouveau résultat et sans délai d’attente.
 16

2. Marginaliser la cohérence (AP): Dans le cas de la distribution, les données peuvent

être sollicitées, mais à cause de la rupture des nœuds, la cohérence n’est pas garantie,
parce que les mises à jour sont asynchrones sur le réseau.
Cette option s’intéresse à fournir un temps de réponse rapide.

Figure 6: AP Disponibilité + Distribution

Sur la figure, la lecture1 retourne v2 alors que la lecture2 retourne v1.

Cassandra utilise cette option, avec des temps de réponse très appréciables mais avec
des résultats non garantis à 100%.
3. Marginaliser la disponibilité (CP) : Les données ne peuvent être utilisées que si leur
cohérence est garantie. Une donnée mise à jour sur un nœud, doit être bloquée sur les
autres nœuds jusqu’à la propagation de la nouvelle version sur tout le réseau. Dans un
environnement distribué, une base de données prend un temps considérable pour avoir
un état cohérent, ce qui rend la disponibilité relative.

Figure 7: CP Cohérence + Distribution

 17

Les requêtes Lecture1 et Lecture2 attendent la synchronisation pour avoir le résultat

v2. Le résultat est cohérent mais avec un délai de latence. MongoDB utilise cette option des
BD NoSQL.
L’option de marginaliser la distribution n’est pas réaliste, car de nos jours, il n’est
pas pratique, voire inimaginable de travailler dans un environnement non distribué.

II.3. BASE
D’après la conclusion du paragraphe précèdent, il reste le choix entre la cohérence
représentée par ACID et la disponibilité représentée par BASE (Basically Available Softstate

Eventually consistent), le terme inventé par Brewer et ses successeurs pour désigner
le cas d’une cohérence éventuelle.
 Basically Available (la disponibilité): Une réponse est garantie pour chaque requête,
que ce soit avec succès ou avec échec, quelle que soit la charge de la base de données.
 Soft-state : L’état du système peut se changer lors des mises à jour, la base n’est pas
forcement cohérente à tout instant.
 Eventually consistent : La base de données peut être incohérente temporairement mais
elle doit être cohérente à un terme.

D’après Brewer, le choix n’est pas binaire, on peut avoir un mélange proportionnel
des niveaux de cohérence et de disponibilité pour avoir de meilleurs résultats.

En 2005, Google fut le plus grand site sur le web, et les SGBDs relationnels ont
montré une insuffisance flagrante pour faire face à la montée de la vitesse et aux volumes des
données. Les défis de Big Data que les entreprises font face aujourd’hui, Google les a déjà
rencontrés il y a presque 20 ans.

II.4. Big Data

Le volume de données stockées sur les ordinateurs est estimé à 300 exabyte (300
billion gigabyte), ce chiffre augmente 28% chaque année, ce qui a donné naissance à une
nouvelle génération de ressources de stockage de données ; le Big Data.

Le BigData désigne « des ensembles de données devenus si volumineux qu’ils

dépassent l’intuition et les capacités humaines d’analyse et même celles des outils
informatiques classiques de gestion de base de données ou de l’information ».
 18

Il est caractérisé par les 3 V : le Volume, une grande quantité de données ; la Variété,
différents types de données, et la Vitesse, l’accumulation des données.
Big Data = Transactions + Interactions + Observations

Figure 8: Transaction Big Data avec les interactions et les observations

Les données hautement structurées telles qu’ERP (Enterprise Resource Planning) ou

CRM (Customer Relationship Management) sont stockées dans des bases de données SQL
classiques. Elles sont basées essentiellement sur la notion des transactions.

Une interaction est un échange entre humain et machine ; les journaux du web, les
clicks des utilisateurs, les interactions et les flux sociaux sont tous des interactions de
données.

Les observations sont une notion de l’ l’« internet of things », toutes les données
issues des capteurs de chaleur, de pression, des coordonnées GPS sont des sources de données
d’observation.

Toutes ces données ont poussé les SGBDR à leurs limites, ce qui a mené au
développement des bases de données distribuées, évolutives horizontale et non relationnelles.
 19

En 2003, Google a révélé des détails sur sa structure de bases des données
distribuées: le BigTable. Son implémentation était le HBase. Plus tard en Octobre 2007,

Yahoo a lancé son produit, le Hadoop, qui est à la base le projet HBase le plus
maturé. Dans la même année 2007, le géant de la vente électronique, Amazon, publie un
article qui annonçait la naissance officielle du NoSQL, il présentait son SGBD NoSQL
Dynamo.

II.5. Cloud Computing

En termes simples, l’informatique en nuage (Cloud Computing) est la fourniture de
services informatiques: serveurs, stockage, bases de données, mise en réseau, logiciels,
analyses et plus via Internet.
II.5.1. L’utilisation
Aujourd’hui, vous utilisez probablement le Cloud Computing dès maintenant, même
si vous ne le réalisez pas. Si vous utilisez un service en ligne pour envoyer des e-mails,
modifier des documents, regarder des films ou des émissions télévisées, écouter de la
musique, jouer à des jeux ou stocker des images et autres fichiers, vous êtes en train d’utiliser
un service Cloud. Voici quelques exemples de ce que vous pouvez faire avec le Cloud :
 Créer de nouvelles applications et services
 Stocker, sauvegarder et récupérer des données
 Sites web et blogs hôtes
 Stream audio et vidéo
 Livrer des logiciels à la demande
 Analyser les données pour les modèles et faire des prédictions

II.5.2. Les types des services

Les services de Cloud se répartissent en trois grandes catégories: infrastructure en

tant que service (IaaS), plate-forme en tant que service (PaaS) et logiciel en tant que service
(Saas).
 Infrastructure en tant que service (IaaS)
La catégorie la plus élémentaire des services de Cloud, avec IaaS, vous louez une
infrastructure informatique, des serveurs et des machines virtuelles (VM), des systèmes de
stockage, des réseaux et des systèmes d’exploitation, à partir d’un fournisseur de Cloud.
 20

 Plateforme en tant que service (PaaS)

La plate-forme en tant que service (PaaS) fait référence aux services de Cloud qui
fournissent un environnement à la demande pour développer, tester, fournir et gérer des
applications logicielles. Le PaaS est conçu pour faciliter la création rapide d’applications

Web ou mobiles par les développeurs, sans se soucier de la configuration ou de la

gestion de l’infrastructure sous-jacente des serveurs, du stockage, du réseau et des bases de
données nécessaires au développement.

 Logiciel en tant que service (SaaS)

Le logiciel en tant que service (SaaS) est une méthode permettant de fournir des
applications logicielles sur Internet, à la demande et généralement sous forme d’abonnement.

Avec SaaS, les fournisseurs de Cloud hébergent et gèrent l’application logicielle et

l’infrastructure sous-jacente, et gèrent toute la maintenance, comme les mises à niveau
logicielles et les correctifs de sécurité. Les utilisateurs se connectent à l’application via
Internet, généralement avec un navigateur Web.

II.5.3. Les types de déploiement

 Cloud public

Les Clouds publics sont détenus et exploités par un fournisseur de services Cloud
tiers, qui fournit leurs ressources informatiques tels que les serveurs et le stockage via

Internet. Microsoft Azure est un exemple de Cloud public. Avec un Cloud public,
l’ensemble du matériel, logiciels et autres infrastructures de support sont détenus et gérés par
le fournisseur de Cloud. Vous accédez à ces services et gérez votre compte à l’aide d’un
navigateur Web.

Ce modèle est caractérisé par :

 Requiert de lourds investissements pour le fournisseur de services

 Offre un maximum de flexibilité.
 N’est pas sécurisé.
 21

 Cloud privé
Un Cloud privé fait référence aux ressources de Cloud utilisées exclusivement par
une seule entreprise ou organisation. Un Cloud privé peut être physiquement situé sur le
centre de données sur site de l’entreprise. Certaines entreprises paient également des
fournisseurs de services tiers pour héberger leur Cloud privé. Un Cloud privé est un Cloud
dans lequel les services et l’infrastructure sont gérés sur un réseau privé.
 Cloud hybride
Les Clouds hybrides combinent des Clouds publics et privés, liés par une technologie
permettant de partager des données et des applications entre eux. En permettant aux données
et aux applications de se déplacer entre des Clouds privés et publics, le Cloud hybride offre
aux entreprises une plus grande flexibilité et davantage d’options de déploiement.

II.6. Le NoSQL
NoSQL désigne une famille de systèmes de gestion de base de données (SGBD) qui
s’écarte du paradigme classique des bases relationnelles. L’explicitation du terme la plus
populaire de l’acronyme est « Not only SQL » en anglais, « pas seulement SQL ». Les
données ne sont pas relationnelles et le langage SQL n’est pas utilisé pour la définition et la
manipulation des données.

C’est l’impact du fait que tout le monde a commencé à se concentrer sur la création
de bases de données à l’échelle du Web, c.à.d. répondre aux besoins croissants de centaines de
millions d’utilisateurs et maintenant de plus en plus à des milliards de dispositifs connectés, y
compris mais non limité aux mobiles, Smartphones, internet TV, et beaucoup plus.

De nos jours, le NoSQL est le terme désigné pour classer les BDs qui ne se basent
pas sur le modèle du SGBD relationnel classique de nature ACID, et qui est le NoSQL
inventé spécialement pour gérer la vitesse et l’extension des données web comme les sites
Google, Facebook, Yahoo, Twitter et autres.

Les SGBD NoSQL essaient de trouver des solutions aux problèmes de passage à
l’échelle et de la disponibilité des données en dépit de l’atomicité et la cohérence impliqués
par les SGBD relationnels avec leurs transactions ACID.
 22

Au contraire du SGBD relationnel, les unités des données ne sont pas bien définies
en termes de type, taille et d’autres contraintes. Il n’y a pas de notion de colonnes et de lignes
ou les colonnes ont des relations, et il n y a pas des transactions ACID.

Imaginons un utilisateur qui veut acheter un livre du site Amazon et la transaction est
atomique, ce qui signifie que d’autres utilisateurs doivent attendre jusqu’à la fin de la
transaction pour pouvoir lancer leurs commandes pour des raisons d’inventaire ; ce qui est
impossible vu le nombre des commandes passant instantanément.

Amazon utilise les données en cache et même des enregistrements débloqués ce qui
influence directement la cohérence.

Il convient de noter que dans le cas des transactions bancaires, il est impossible de
travailler avec des données en cache ou avec un état temporaire vu la criticité (la nature
critique) de la situation. Simplement, le NoSQL n’est pas toujours une solution.
II.6.1. Caractéristiques
Le NoSQL n’est pas juste pour faire face au problème de l’extensibilité, mais il a
proposé aussi d’autres solutions :
 Une représentation de données sans-schéma : Un nouveau technicien recruté au sein
d’une compagnie doit connaitre d’abord tout le modèle d’une BD relationnelle
existante à savoir les entités, leurs relations et le code pour pouvoir la maintenir. Par
contre, avec une BD NoSQL, la représentation est plus flexible, nous ne sommes pas
obligé à penser à la structure rigide de la BD, elle peut évoluer au cours de son
développement, y compris l’ajout de nouveau champs et la fusion des données (JSON)
et même une éventuelle intégration avec d’autre plateformes hétérogènes.
 Plus de requêtes complexes : Pas de requêtes SQL longues et des jointures complexes,
ce qui réduit sensiblement le temps de développement et optimise l’utilisation des
ressources.
 Vitesse : Gain de confiance des utilisateurs grâce à la vitesse de réponse (on parle de
millisecondes au lieu de centaines de millisecondes)
 Mise à jour des données : Avec les SGBD relationnels, la mise à jour des données à
travers des tables liées ou croisées est un scénario complexe, surtout si la table
concernée ne fait pas partie de la transaction en cours, cela laisse la transaction ouverte
pour une longue durée et ralentit la performance. Par contre, le NoSQL avec le
 23

principe de «Eventualy Consistant» permet des mises à jour concurrentes à travers

plusieurs Datacenters avec la gestion des conflits et dans un temps très acceptable.
 Extensibilité (passage à l’échelle) planifiée : Nous n’avons pas à nous occuper de la
taille de l’application ni du volume des données ni de leur schéma dès la conception.
Par exemple, la prise en charge de dizaines de commandes en même temps sur un
même produit par des clients distribués géographiquement ne peut être satisfaite par
un SGBD classique.
II.6.2. Types
Les BD NoSQL sont classées selon le modèle de stockage de données:
Orientées documents, orientées clé-valeur, orientées colonnes, orientées graphe.
II.6.2.1. Les BDs Orientées colonnes
Au contraire des SGBDR, elles sérialisent les valeurs d’une colonne ensemble, puis
les valeurs de la colonne suivante, etc. une BD relationnelle présente les données dans une
table bidimensionnelle composée de lignes et colonnes, mais les manipule ligne par ligne,
alors que le NoSQL orienté colonne stocke les données en tant que colonnes.
Dans une BDR, on stocke les données comme suit :

Figure 9: Table d’une BDR

Alors que dans une BD NoSQL orientée colonne, elles sont stockées comme suit :
 24

Figure 10: Table d’une BD NoSQL orientée colonne

Il est conseillé d’entamer la modélisation en NoSQL par l’orientée colonne, car il

permet une compréhension rapide du modèle et donne un avant-goût à ce nouveau domaine.
Si le travail nécessite des valeurs agrégées, vous n’avez pas le choix à l’utiliser.
 Avantages :

 Permet l’insertion facile de nouvelles colonnes à n’importe quel moment sans

s’inquiéter des valeurs par défaut. Ceci assure une meilleure flexibilité au model et
facilite le passage à l’échelle.
 La performance de ce modèle apparait clairement dans le calcul des valeurs maximale,
minimale, moyenne et la somme.
 Si de nouvelles valeurs sont à appliquer sur l’ensemble des lignes ou sur un sous
ensemble de colonne, ce modèle permet un accès partiel aux données sans effet sur les
données non concernées, ce qui accélère l’exécution.
 Optimisation de l’espace de stockage grâce aux types uniformes des colonnes, qui sont
dans la plus part du temps des chaines de caractères de mêmes tailles. Tel
caractéristique (ex : Chine comme pays pour 1 milliard d’utilisateurs) optimise la
compression des données.
 25

II.6.2.2. Les BDs orientées documents

Les enregistrements (les lignes du SGBDR) sont représentés par des documents ; ils
sont semi-structurés par rapport à la représentation rigide du relationnel et permettent
l’insertion, l’interrogation et la manipulation des données. Deux enregistrements peuvent
avoir différentes structures ou ensemble de colonnes. Les enregistrements peuvent ne pas
respecter un schéma spécifique ou une définition de table, ce que signifie qu’il n y a pas de
validation de documents par rapport à un schéma comme c’est le cas pour les SGBDR.

En bref, une BD orientée document fournit une flexibilité dynamique ou un schéma

modifiable ou complet des documents sans schéma.

Cet avantage a permis de rendre ce modèle plus répondu et plus utilisé parmi les
autres modèles de BDs NoSQL.

Avec JSON, qui est l’un des langages qui adopte l’orienté-document, un document
peut s’écrire comme suit :

{
"SupplierID" : "1",
"CompanyName" : "Exotic Liquids",
"ContactName" : "Charlotte Cooper",
}

Un autre document dans la même base peut s’écrire comme suit :

{
"SupplierID” : "2",
"CompanyName" : "New Orleans Cajun Delights",
"ContactName" : "Shelley Burke",
"Adress":{
"Line1" :" P.O. Box 78934",
"City" : "New Orleans",
"Region" : "LA"
},
"Phones":["(100) 555-4822" , "(100) 555-4888"]

Un troisième document contient les informations d’un produit :

 26

{
"ProductID" : "9",
"ProductName" : "Mishi Kobe Niku",
"QuantityPerUnit" : "18 - 500 g pkgs.",
"UnitPrice" : "97,00",
"UnitsInStock" : "29",
"UnitsOnOrder" : "0"

Nous constatons que les deux premiers documents sont presque similaires ; le
deuxième est plus détaillé avec l’ajout de l’adresse du fournisseur. Alors que le troisième
n’est pas en corrélation avec eux, ce sont des informations d’un produit.

Si nous devons travailler avec des agrégations à travers plusieurs entités, ce modèle
nous permet un contrôle efficace sur la manière d’interroger les données. Exemple, travailler
avec JSON à travers des données fusionnées ou avec XQuery en utilisant XML et obtenir des
vues personnalisées.

Les BDs les plus connues de ce modèle sont : MongoDB, CouchDB, Jackrabbit,
Lotus Notes, Terrastore, Redis et BaseX.
 Avantage :
 Le contenu est flexible sans schéma
 Une recherche à travers multiple entités est négligeable par rapport à une même
recherche dans un SGBDR classique.

II.6.2.3. Les BDs orientées clé-valeur

Ce modèle est proche du modèle orienté document, mais la création de la clé est
obligatoire lors de la création du couple, il permet le stockage des données dans des couples

clé-valeur. Absence de schéma ou de typage. La définition de la clé est obligatoire

tandis que la valeur est opaque, pour cela, une clé doit être connue pour trouver la valeur
associée.

Son avantage est l’efficacité de travailler dans une mémoire distribuée ou dans un
cache pour réduire les opérations d’E/S.
 27

L’accès à une valeur est direct et efficace, car une paire clé-valeur est unique ;. Les
clés peuvent être indexées pour plus de performance.

La différence par rapport à une BD orientée document est l’absence de requêtes par
rapport aux valeurs. L’interrogation des données se fait exclusivement par rapport aux clés.

Les pairs peuvent être imaginés comme une table à deux entrées :

Figure 11: Modèle clé-valeur

La plupart des BD orientées clé-valeur sont inspirées de Dynamo d’Amazon, qui

garantit une évolutivité et une disponibilité exceptionnelles. Voldemort et Riak sont
l’implémentation des bases de Dynamo.
 Avantage :

 La recherche est optimale en raison de l’utilisation des clés et du cache.

Par exemple, Redis en fonctionnant sur un micro-ordinateur de gamme ordinaire peut
scanner jusqu’à 1 million de clés dans moins de 40 milliseconde.
 Le type de données des valeurs n’est pas spécifié, on peut stocker n’importe quel type
de données.
Ce modèle n’est pas conçu pour les applications nécessitant l’indexation des valeurs.
I.6.3.4. Les BDs orientées graphe

Ce modèle est basé sur la théorie des graphes, c.à.d. les nœuds, les relations et les
propriétés. Il est relativement nouveau sur le marché des NoSQL.

Sa particularité est la facilité de définir les relations directement au niveau de la BD

au contraire des autres modèles ou les relations sont visibles au niveau de l’application.
 28

Il est très utile pour toutes les applications qui ont des relations complexes entre leurs
objets comme les réseaux sociaux.

Figure 12: Structure de base d’une BD orientée graphe

Il profite de tous les avantages de la théorie des graphes :

 Trouver le chemin le plus court
 Trouver les voisins d’un nœud qui ont des propriétés spécifiques
 Quelle est la ressemblance entre deux nœuds en prenant en compte leurs voisins, etc.

 Avantage :
 Ce modèle est idéal lorsque nous avons plusieurs objets liés les uns aux autres de
façon complexe, et ses objets ont des propriétés (frère de, sœur de, père de). Il permet
par une requête simple d’avoir les voisins d’un nœud, ou d’avoir tout un chemin par
des requêtes plus ou moins complexes.
 Il ne s’arrête pas sur le point de nous donner les relations entre les nœuds, mais aussi
des rapports détaillés sur la nature de ses relations.
 Comme toute modélisation basée sur une représentation graphique, l’avantage majeur
est la compréhension facile par les humains par rapport à une modélisation textuelle,
c’est une représentation du monde réel, des noms, des villes, workstations (postes-de-
travail) d’un réseau informatique; l’insertion et la suppression des relations entre
nœuds se fait par un simple clic de souris.
 29

II.7. Conclusion
Apres avoir découvert les SGBRs dans le premier chapitre, nous avons vu dans ce
chapitre l’alternative qui a dominé le domaine de gestion de bases de données, et surtout dans
les environnements distribués ; le NoSQL, qui a prouvé ses capacités dans la manipulation des
grands volumes de données (documents, sites Web à fort trafic, etc.) à travers les modèles de
données qu’il a proposé et les architectures qui assurent les critères demandés : la
disponibilité et l’évolutivité. Nous avons constaté que la majorité des grandes entreprises du
secteur informatique ont adopté ces nouvelles solutions pour répondre à leurs besoins
majeurs.
 30

CHAPITRE III. LES SOLUTIONS NOSQL ETUDIEES

III.1. Introduction
Utiliser MongoDB demande un changement de la vision d’une base de données.
Structurer les données d’une base de données NoSQL comme une base de données
relationnelles reviendrait à passer à côté de toutes les innovations et avantages de celles-ci.
Ainsi, avant de la mettre en place, il est important d’étudier toutes les particularités d’une base
de données MongoDB.

III.2. Schéma
La conception du schéma doit prendre en compte les particularités de l’application
elle-même. Il faut regarder le nombre de lectures et l’importance de chacune. Les requêtes et
la fréquence des mises à jour doivent également être étudiées bien avant la conception du
modèle.
III.2.1. Document

Le modèle de données de MongoDB est entièrement basé sur le document. Le

document est représenté par un fichier BSON. Les caractéristiques de ces fichiers permettent
d’introduire des documents intégrés, ce qui permet d’éviter les jointures ou transactions
lourdes. Les documents peuvent donc être comparés à plusieurs lignes d’une table d’une BD
relationnelle.

Des règles générales aussi bien structurées que pour le passage du modèle conceptuel
au modèle physique des SGBDR ne connaissent pas leur pareil dans ce cas-ci. Le schéma se
crée au cas par cas en fonction de l’application mise en place. La flexibilité des documents est
un grand avantage car il permet de rassembler tous les types de modèles de bases de données.
Elle permet également de revenir sur le schéma d’un document après sa création sans coût
trop important.

MongoDB assure la conformité ACID (atomicité, cohérence, isolation et durabilité)

au niveau du document. En effet, toutes les données comprises dans un document peuvent être
rassemblées en une seule opération. Ainsi, on peut stocker toutes les données dans un seul
document pour appliquer les caractéristiques ACID à l’ensemble de la base de données.

Cette structure rend la maintenance beaucoup plus facile et moins pénible. Elle
remplace la fonction assez lourde des SGBDR « Alter table », car un document peut être
rapidement modifié sans impacter sur les autres documents de la collection.
 31

Cette solution semble miraculeuse en rassemblant les caractéristiques du relationnel

et du NoSQL en un seul système, mais regrouper toutes les données dans un seul document
peut forcer à réaliser des compromis pour d’autres applications. Un certain modèle de
collection peut correspondre à une application et pas à une autre. Cette configuration peut
également amener le document à dépasser la limite de taille (16Mo). Le format document peut
aussi offrir des désavantages dus à son absence de structure, les requêtes peuvent s’avérer
compliquées car il faut savoir exactement quelle partie du document il faut interroger car
celles-ci varient dans toute la collection.

Figure 13: Exemple Document dans une collection

III.2.2. Collection

Une collection est l’ensemble des documents de la même famille. Il n’y a pas de
structure imposée pour les documents d’une même collection, ils peuvent tous varier entre
eux.

Il existe des collections typiques appelées « collections limitées », créées à l’avance

avec une limite de taille. Quand l’ajout de documents provoque le dépassement de la taille
limite, ce sont les plus vieux documents qui vont être supprimés. Cette configuration offre une
gestion particulière de la mémoire.
 32

Figure 14: Collection

Les relations un à un ou un à plusieurs correspondent parfaitement au type de

document intégré. Les documents ne doivent pas être intégrés dans trois cas :
 Si le document à intégrer demande beaucoup moins de lecture que le document
principal. Cela ne ferait qu’augmenter la mémoire nécessaire pour les opérations
fréquentes ;
 Si une partie du document est fréquemment mise à jour contrairement au reste du
document ;
 Si la taille totale du document dépasse la limite des 16 Mo imposée par MongoDB.

Le format en document de MongoDB permet d’accéder à l’ensemble des données

sans joint, ce qui augmente la rapidité de réponse. De plus, chacun des documents est donc
indépendant et peut être distribués horizontalement. S’il faut normaliser le modèle, le
référencement existe pour faire le lien entre deux documents. Pour des situations pouvant
trouver un avantage à une normalisation, MongoDB offre tout de même une fonction
d’agrégation (moins puissante que le joint des bases de données relationnelle).

Il apparait clairement que son utilisation diminuerait les performances, mais

MongoDB offre la possibilité d’un joint contrairement à la plupart des bases de données
NoSQL. Le référencement est le plus souvent appliqué sur le champ _id (par la commande
$lookup) dans le document de référence.
 33

L’usage du référencement est conseillé dans plusieurs cas :

 Si l’intégration n’a vraiment pas l’avantage sur le référencement

 Si l’objet est référencé de plusieurs sources
 Pour les relations plusieurs à plusieurs
 Pour les jeux de données volumineux et hiérarchiques

Il existe plusieurs outils appelés ETL (« extract, transform and load ») qui sont
capables d’assister la migration d’une base de données relationnelle vers MongoDB
(MongoDB, 2015). Ces assistants sont surtout utiles lors du déplacement de grandes quantités
de données et sont compris dans le package MongoDB Entreprise, qui lui, n’est pas open
source.

III.3. JSON
Le format JSON est un format de fichiers JavaScript léger. JSON est un format
lisible par l’homme, semblable au XML mais plus compact, vu l’absence de balises. Voici un
exemple de fichier JSON.
> db.test.find()
{ "_id" : ObjectId("5790c5cecae25b3d38c3c7ae"), "key" :
"value1", "key2" : "Val2
", "key3" : "val3" }
{ "_id" : ObjectId("5790c5d9cae25b3d38c3c7af"), "key" :
"value2", "key2" : "Val2
1", "key3" : "val31" }
{ "_id" : ObjectId("5790c5e9cae25b3d38c3c7b0"), "key" :
"value3", "key2" : "Val2
2", "key3" : "val33" }

Les différents éléments pouvant être présents dans un document JSON sont soit un
objet, soit un tableau qui eux-mêmes peuvent rassembler plusieurs types de valeurs. Voici la
schématisation de ces éléments.
 34

Figure 15: Schématisation d'un objet JSON

Figure 16: Schématisation d'un tableau JSON

Figure 17: Schématisation des différents types de valeur contenue dans un document JSON

L’importation peut être effectuée à partir de fichier JSON qui sera stocké dans la BD
sous format BSON. Le BSON est une extension au JSON, il permet l’utilisation d’autre type
de données comme les entiers, les types longs, les dates et les virgules flottantes.

Il faut souligner que l’utilisation de noms de champs trop longs diminue les
performances de la BDD étant donné que celui-ci est répété pour chaque document de la
collection.
 35

III.4. Modélisation
La modélisation n’est pas indispensable car le modèle ne connait pas de schémas
fixes, mais son utilisation offre une meilleure compréhension ainsi qu’une vision des
cardinalités.

III.5. Sélection de l’index

La sélection de l’indice se réalise une nouvelle fois en fonction du type et de la
fréquence des requêtes. La création des index consomme beaucoup de ressources, l’utilisation
de chaque index doit donc être justifiée.

Même si l’utilisation d’un index n’est pas utile pour le nombre de données
manipulées, il est toujours intéressant de prévoir l’utilisation de ceux-ci dans le cas d’une
croissance de la base de données.

L’index principal de MongoDB est un index B-Tree. Ce type d’index est déjà utilisé
dans les BD relationnelle. Voici une représentation de l’indexation des informations par
l’index B-Tree pour une meilleure compréhension.

Figure 18: Indexe Mongo DB

 36

D’autre index secondaires pouvant être introduits par l’utilisateur sont supportés
nativement par MongoDB. Les indexes de MongoDB correspondent pour la plupart à ceux
des BD relationnelles.

Les index secondaires spatiaux sont les seuls qui vont être utilisés dans le cadre de ce
travail. Ce sont des index Quadtree qui sont utilisés dans ce cas Voici d’autre index
secondaires pour information : index composé, index de durée de vie, index syntaxiques,
index haché, etc.

III.6. Validation de documents

Les schémas dynamiques de MongoDB ont beaucoup d’avantages, mais pour une
bonne qualité de données, il faut continuer à les contrôler. La validation de documents peut
être utile lorsqu’ils se trouvent des applications en aval qui ont des exigences particulières.
MongoDB offre la possibilité d’effectuer ces vérifications au sein même de la BDD. Par
exemple : vérifier la clé, si le type de valeur est correct, etc.

III.7. « Sharding » ou distribution horizontale

Contrairement aux bases de données relationnelles, la distribution horizontale est
installée automatiquement dans le système de gestion de base de données. Ce qui constitue
déjà une complexité en moins pour le développeur. Elle est totalement invisible pour
l’application, car elle n’a aucun impact sur celle-ci. C’est un routeur de requêtes qui va
rediriger les requêtes concernant les clés de partitionnement vers les bons « shards ».

Le « sharding » est également utilisé pour la réplication. MongoDB est capable de ce

qui est appelé « auto-guérision » en sauvegardant plusieurs copies des données. Les
opérations de lecture et d’écriture ont uniquement accès au premier réplica. Ainsi, si une
erreur a lieu, un des autres réplicas secondaires peut devenir le réplica principal. Cette
caractéristique lui permet également d’être capable de maintenir une forte cohérence en
dirigeant toutes les opérations de lectures vers les serveurs primaires.

Le « sharding » ne sera pas abordé dans ce travail, étant donné que l’objectif est la
création d’un prototype jetable mis en place sur une seule machine. Le partitionnement
horizontal concerne surtout les grandes quantités de données et ne fonctionne que quand le
système de gestion de la base de données a accès à plusieurs machines pour pouvoir distribuer
l’information.
 37

III.8. Sécurité
La sécurité est un point important à aborder pour les systèmes de gestion de bases de
données NoSQL, et cela concerne également MongoDB. En effet, un rapport du 13 janvier
2017 énonce les bonnes pratiques pour protéger ses données et cela en réaction à des attaques
sur des BD.

Une solution est offerte par MongoDB Enterprise Advanced qui est une version
payante de MongoDB. Ce package offre entre-autres de défendre, détecter et contrôler l’accès
aux données.

La documentation de MongoDB contient beaucoup d’informations sur les

précautions à prendre pour sécuriser ses données qui semblent devoir être suivies à la lettre
pour être entièrement efficaces, vu le rapport publié.

En ce qui concerne la simple authentification, voici la marche à suivre pour créer un

identifiant et un mot de passe pour l’utilisation d’un BD.

Tableau 1: Création utilisateur Mongo DB

use UPL
db.createUser(
{
user: "ELIE",
pwd: "abc123",
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

Et voici comment se connecter une fois l’identifiant créé :

Tableau 2: Connexion à Mongo DB

use admin
db.auth("ELIE", "abc123")
 38

III.9. GridFs
III.9.1. Définition

C’est un mécanisme qui permet de stocker des fichiers binaires importants jusqu’à
2GB par fichier GridFS divise la quantité de données dans plusieurs documents et collections
particuliers.

Il faut tout d’abord savoir que son utilisation présente des désavantages.
Premièrement, elle diminue les performances : aller chercher un fichier via MongoDB ne sera
pas aussi rapide que d’aller directement le chercher dans le système de fichiers. Ensuite, les
documents peuvent seulement être modifiés par la suppression ou la sauvegarde car ils sont
stockés à plusieurs endroits et MongoDB ne sait pas les bloquer tous ensembles pour
permettre une modification plus importante.

GridFS est surtout utile quand on utilise des fichiers larges qui demandent un accès
non fréquent. Son utilisation permet d’éviter l’utilisation d’un autre outil pour le stockage de
fichiers. GridFS a un avantage quand le système de fichiers limite le nombre de fichier dans le
répertoire,

GridFS lui n’a pas de nombres limites. De plus, si le but est d’accéder à uniquement
une petite partie du fichier sans en ouvrir l’entièreté, GridFS est un bon outil. C’est le principe
du streaming, c’est lire un fichier sans en télécharger l’entièreté. Enfin, si on veut que les
fichiers et méta-datas profitent automatiquement de l’auto-guérison et de la distribution
horizontale implémentés dans le système, GridFS doit être utilisé.
III.9.2. Mongofiles
Mongofiles est l’outil de commande le plus pratique pour utiliser GridFS. Il permet
de manipuler et effectuer des requêtes sur les fichiers contenus dans GridFS.

Voici les commandes principales :

Tableau 3: Commande principales de mongofiles

List Fait l’inventaire des fichiers stockés dans GridFS

Search Recherche un fichier avec une chaîne de caractères

Put Copie un fichier du système de fichier au stockage de GridFS

 39

Get Copier un fichier de GridFS vers le système de fichier par le nom de l’objet

Get_id Copier un fichier de GridFS vers le système de fichier par l’id de l’objet

Delete Supprime le fichier par son nom

Delete_id Supprime le fichier par son id

III.10. Installation et manipulation de MongoDB

III.10.1. Version

La version installée de MongoDB est la version 4.2, mais des mises à jour mineures
sont disponibles chaque mois. La dernière version en date est la version 4.2.1. mise en ligne
depuis le Mai 2021.

Plusieurs produits sont offerts par MongoDB et c’est le pack « Community Server »
qui sera téléchargé et installé. Il existe également une version d’entreprise et une version
professionnelle qui sont toutes les deux payantes et qui offrent des avantages par rapport à la
version de la communauté qui correspond uniquement à un but de développement.
III.10.2. MongoDB Compass
MongoDB est le GUI proposé par MongoDB. Cette interface est assez intuitive et ne
demande pas de connaissances préliminaires.

Elle possède plusieurs onglets permettant d’analyser une collection :

 40

Figure 19: Vision des options disponibles de Compass

 « Document » : cet onglet permet la visualisation des données sous le format BSON.
Il offre également comme chacun des onglets, un champ permettant d’insérer des
requêtes pour limiter l’affichage aux documents désirés. Sur cette page, apparait
également un onglet « insert document » qui consiste à l’ajout d’un seul document
BSON à compléter.
 « Schema » : Cet onglet permet l’étude en profondeur du schéma. Chacun des champs
présents sont étudiés un par un par la définition de leur type et par des exemples. C’est
dans cet onglet que les points sont visualisables. Les différents champs intégrés sont
également toujours présentés nichés les uns aux autres dans cette présentation.
 « Explain Plan » : Cette option offre une analyse des performances et l’explication de
celles-ci. Cet onglet représente l’équivalent de la fonction explain().
 « Indexes » : Rassemble les propriétés de chacun des index créés et de leur utilisation

 « Validation » : Permet d’imposer des règles et des avertissements sur des valeurs de
champs de documents pour certifier que ceux-ci répondent aux demandes de
l’application.
 41

III.11. Requêtes de base

Termes SQL Termes MongoDB

Base de données Base de données
Table Collection
Entité / Ligne Document
Colonne Clé / champ
Table Join Documents intégrés
Clé primaire Clé primaire (clé par défaut _id fournie par mongodb lui-
même)

 Afficher toutes les bases de données disponibles :

show dbs;
Tableau 4 Liste des bases de données disponibles

> show dbs;

Mongo_Test 0.000GB
UPL 0.000GB
admin 0.000GB
config 0.000GB
local 0.000GB
test 0.000GB
>

 Sélectionnez une base de données particulière à laquelle accéder, par exemple UPL.
Si la base de données n’existe pas Mongo la créera automatiquement.
Commande  : Use UPL;
Tableau 5: Sélectionnez une base de données

> use UPL;

switched to db UPL
>

 Afficher toutes les collections de la base de données

Commande : show collections;
Tableau 6: Afficher toutes les collections

> show collections

Enseignant
Etudiant
 42

 Pour vérifier la base de données sélectionnée

Commande  : db ;
> db;
UPL
>

III.11.1. Créer une collection

Commande  : db.createCollection(‘Nom de la collection’)
Tableau 7: Création d'une collection

> db.createCollection('Administration')
{ "ok" : 1 }
> show collections
Administration
Enseignant
Etudiant
>

Pour notre cas nous venons de créer la collection Administration ; nous pouvons le
remarque sur le tableau ci-haut en utilisation la commande show collections ;

Si nous souhaitons voir le document inséré, utilisez la commande find() ;

> db.Enseignant.find()
{ "_id" : ObjectId("60646c8013727eae0558a2fa"), "nom" :
"BLAISE", "postnom" : "FYAMA" }
>

Nous remarquons dans la collection Enseignant jusque-là il y a un seul document

enregistré.

 Drop(Supprimer) Collection
Commande  : db.nom de la collection.drop()

> db.Administration.drop()
true
> show collections
Enseignant
 43

Etudiant

Nous remarquons sur le graphique en utilisant la fonction drop() nous venons de

supprimer la collection Administration.

III.11.2. Opération CRUD

 Créer
La fonction insertOne pour insérer un seul enregistrement
Tableau 8: insertion d'un seul enregistrement

>db.Enseignant.insertOne({nom:'Katual',prenom:'Daniel',fonction:'Vice-
doyen'});
{
"acknowledged" : true,
"insertedId" : ObjectId("6152216b65457ae1e7e13753")
}
> db.Enseignant.find()
{ "_id" : ObjectId("60646c8013727eae0558a2fa"), "nom" : "BLAISE",
"postnom" : "FYAMA" }
{ "_id" : ObjectId("6152216b65457ae1e7e13753"), "nom" : "Katual",
"prenom" : "Daniel", "fonction" : "Vice-doyen" }
> db.Enseignant.find().pretty()
{
"_id" : ObjectId("60646c8013727eae0558a2fa"),
"nom" : "BLAISE",
"postnom" : "FYAMA"
}
{
"_id" : ObjectId("6152216b65457ae1e7e13753"),
"nom" : "Katual",
"prenom" : "Daniel",
"fonction" : "Vice-doyen"
}
>
 44

Figure 20: Illustration Mongo Shell

Nous venons de créer un nouveau document dans la collection UPL. Sur la figure
nous remarquons dans une même collection deux enregistrement avec les champs différents
c’est l’un des avantage de Mongo DB qui a la capacité de stocker différents type de données
dans une même collection.

Insertion multiple insertMany pour insérer plusieurs enregistrements

>db.Enseignant.insertMany([{nom:'PETU',prenom:'Acclamé',f
onction:'Assistant'},{nom:'Kadiata',prenom:'Freddy'},
{nom:'Kibembe',prenom:'Chadrack'}])
{
"acknowledged" : true,
"insertedIds" : [
ObjectId("6152259c65457ae1e7e13754"),
ObjectId("6152259c65457ae1e7e13755"),
ObjectId("6152259c65457ae1e7e13756")
]
}
>
 45

 Mettre à jour

Fonction  : update()

Commande  : db.Nom de la collection.update({document à modifié},

{Mise à jour apportée})

>db.Enseignant.update({nom:'Kadiata'},{fonction:'Assistant'})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" :
1 })

Si un document doit être remplacé : Fonction replaceOne()

>db.Enseignant.replaceOne({nom:'PETU'},
{nom:'SAIDI',prenom:'Arnauld'})
{ "acknowledged" : true, "matchedCount" : 1,
"modifiedCount" : 1 }
>

 Effacer
Fonction : remove(), delete()

> db.Enseignant.remove({nom:'Kibembe'})
WriteResult({ "nRemoved" : 1 })
> db.Enseignant.find()
{ "_id" : ObjectId("60646c8013727eae0558a2fa"), "nom" :
"BLAISE", "postnom" : "FYAMA" }
{ "_id" : ObjectId("6152216b65457ae1e7e13753"), "nom" :
"Katual", "prenom" : "Daniel", "fonction" : "Vice-doyen"
 46

}
{ "_id" : ObjectId("6152259c65457ae1e7e13754"), "nom" :
"SAIDI", "prenom" : "Arnauld" }
{ "_id" : ObjectId("6152283e65457ae1e7e13757"), "nom" :
"Kadiata", "prenom" : "Freddy", "fonction" : "Assistant"
}
 47

III.12. Conclusion
Dans ce chapitre nous avons mis le point sur la structure et le fonctionnement de
Mongo DB. Nous avons vu comment cette base de données de la famille NoSQL qui est
orientée Document la façon dont elle gère ses data, sa structure interne ainsi que ses
différentes fonctionnalités. Nous avons chuté par une petite démonstration des commandes de
cette dernières : La gestion des collections et des enregistrements qui sont les documents.
 48

CONCLUSION GENERALE

Tout au long de ce travail, nous avons mis le point sur le Big data et nous avons
montré comment les bases de données NoSQL pouvaient intervenir dans la gestion de ces
données qui sont immenses à gérer par les bases de données relationnelles.

Nous avons jeté un coup par la suite sur les Bases de données NoSQL, les différents
types, les différentes fonctionnalités qu’il s’agisse des Orientée document, Orientée Colonne,
Clé valeur, Orientée graphe.

Parmi ces types nous avons ressorti Mongo DB qui est de la famille Orientée et nous
avons chuté par quelques illustrations des commandes de base de cette dernière.

Ce travail nous a ouvert une vision sur le monde du Big data et des bases de données
NoSQL, tout n’a pas été parfait dans ce marathon mais nous avons sorti le nécessaire pour
comprendre ces néologismes.
 49

Bibliographie

[1] R. Bruchez, Les bases de données NoSQL et le Big Data : Comprendre et mettre en
oeuvre, Paris: Eyrolles.

[2] P. B. Bernard ESPINASSE, «Introduction au Big Data - Opportunités, stockage et analyse

des mégadonnées,» 10 février 2017.

[3] P. Senellart, «Limites des systèmes classiques de gestion de bases de données».

[4] «Statista.fr/Big Data,» [En ligne]. [Accès le 03 Septembre 2021].

[5] P. Rigaux, «Bases de données documentaires et distribuées,» sept. 25, 2018.

 50

Table des matières

Epigraphe...............................................................................................................................................I
DEDICACE..........................................................................................................................................II
REMERCIEMENTS...........................................................................................................................III
LISTE DES TABLEAUX...................................................................................................................IV
LISTE DES FIGURES........................................................................................................................V
INTRODUCTION................................................................................................................................6
CHAPITRE I. LES BASES DE DONNEES RELATIONNELLES.................................................8
I.1. Introduction................................................................................................................................8
I.2. Principe de fonctionnement de SGBD relationnel...................................................................8
I.3. Propriétés ACID........................................................................................................................9
I.3.1. Atomicity (Atomicité)..........................................................................................................9
I.3.2. Consistency (Cohérence)...................................................................................................10
I.3.3. Isolation (Isolation)...........................................................................................................11
I.3.4. Durability (Durabilité)......................................................................................................11
I.4. Limites des bases de données relationnelles...........................................................................12
I.4.1. Problème lié à l’application des propriétés ACID en milieu distribué..........................12
I.4.2. Problème de requête non optimale dû à l’utilisation des jointures................................13
I.4.3. Problème lié au Théorème du CAP..................................................................................14
I.4.4. Problème lié à la gestion des objets hétérogènes.............................................................16
I.5. Conclusion................................................................................................................................17
CHAPITRE II. LES BASES DE DONNEES NoSQL......................................................................18
II.1. Introduction............................................................................................................................18
II.2. Théorème de CAP..................................................................................................................19
II.3. BASE.......................................................................................................................................22
II.4. Big Data...................................................................................................................................22
II.5. Cloud Computing...................................................................................................................24
II.5.1. L’utilisation......................................................................................................................24
II.5.2. Les types des services......................................................................................................24
II.5.3. Les types de déploiement.................................................................................................25
II.6. Le NoSQL...............................................................................................................................26
II.6.1. Caractéristiques...............................................................................................................27
II.6.2. Types.................................................................................................................................28
II.7. Conclusion...............................................................................................................................34
CHAPITRE III. LES SOLUTIONS NOSQL ETUDIEES..............................................................35
 51

III.1. Introduction...........................................................................................................................35
III.2. Schéma...................................................................................................................................35
III.2.1. Document........................................................................................................................35
III.2.2. Collection........................................................................................................................36
III.3. JSON......................................................................................................................................38
III.4. Modélisation..........................................................................................................................40
III.5. Sélection de l’index...............................................................................................................40
III.6. Validation de documents......................................................................................................41
III.7. « Sharding » ou distribution horizontale.............................................................................41
III.8. Sécurité..................................................................................................................................41
III.9. GridFs....................................................................................................................................42
III.9.1. Définition.......................................................................................................................42
III.9.2. Mongofiles......................................................................................................................43
III.10. Installation et manipulation de MongoDB........................................................................44
III.10.1. Version..........................................................................................................................44
III.10.2. MongoDB Compass......................................................................................................44
III.11. Requêtes de base.................................................................................................................45
III.11.1. Créer une collection.....................................................................................................46
III.11.2. Opération CRUD..........................................................................................................47
III.12. Conclusion...........................................................................................................................51
CONCLUSION GENERALE............................................................................................................52
Bibliographie......................................................................................................................................53