UNIVERSITE BADJI MOKHTAR – ANNABA

Faculté des Sciences de l’Ingénieur

Département Informatique

Support de cours

Les Bases de Données NoSQL

Promotion 1ème année Master

Option : Gestion et Analyse des Données Massives (GADM)

Cours présenté par : Pr. Halima BAHI

Année universitaire 2018/2019

Table des Matières

2
Avant - Propos

3
 Chapitre 0 :
Retour sur les bases de données relationnelles
0. 1. Introduction

Un modèle de données définit un mode de représentation de l’information selon trois

composantes :

1. Des structures de données.

2. Des contraintes qui permettent de spécifier les règles que doit respecter une base de données.

3. Des opérations pour manipuler les données, en interrogation et en mise à jour.

Les deux premières composantes relèvent du Langage de Définition de Données (DDL) dans un
SGBD. Le DDL est utilisé pour décrire le schéma d’une base de données. La troisième
composante (opérations) est la base du Langage de Manipulation de Données (DML) dont le
représentant le plus célèbre est SQL.

Dans le contexte des bases de données, la principale qualité d’un modèle de données est d’être
indépendant de la représentation physique. Cette indépendance permet de séparer totalement les
tâches respectives des administrateurs de la base, chargés de l’optimisation de ses performances,
et des développeurs d’application ou utilisateurs finaux qui n’ont pas à se soucier de la manière
dont le système satisfait leurs demandes. Le modèle relationnel, venant après les modèles
hiérarchique et réseau, offre une totale indépendance entre les représentations logique et physique.

0.2. Le schéma relationnel

Un des grands avantages du modèle relationnel est sa très grande simplicité. Il n’existe en effet
qu’une seule structure, la relation. Une relation peut simplement être représentée sous forme de
table, comme sur la figure suivante. Une relation a donc un nom (Film) et se compose d’un
ensemble de colonnes désignées par un nom d’attribut.

Dans chaque colonne on trouve des valeurs d’un certain domaine (chaînes de caractères,
nombres). Enfin on constate que chaque ligne (ou tuple) correspond à une entité (ici des films).

titre année genre

Alien 1979 Science-Fiction
Vertigo 1958 Suspence
Volte-face 1997 Thriller
Pulp Fiction 1995 Policier
Fig. 1. 1. Exemple d’une relation

4
Un schéma de relation est simplement un nom suivi de la liste des attributs, chaque attribut étant
associé à son domaine. La syntaxe est donc : R(A1:D1,A2:D2, An:Dn)

où les Ai sont les noms d’attributs et les Di les domaines. L’arité d’une relation est le nombre de
ses attributs. On peut trouver dans un schéma de relation plusieurs fois le même domaine, mais
une seule fois un nom d’attribut. Le domaine peut être omis en phase de définition. Le schéma de
la relation de la figure précédente est donc : Film (titre: string, année: number, genre : string)

L’instance d’une relation R , ou simplement relation se définit mathématiquement comme un

sous ensemble fini du produit cartésien des domaines des attributs de R . Rappelons que le
produit cartésien D1D2 …Dn  entre des domaines d1, D2, …Dn est l’ensemble de tous les
tuples (v1, …vn) où viDi. Un des fondements du modèle relationnel est la théorie des
ensembles et la notion de relation dont le modèle correspond strictement au concept
mathématique dans cette théorie. Une relation se représente sous forme de table, et on emploie le
plus souvent ces deux termes comme des synonymes.

La clé d’une relation est le plus petit sous-ensemble des attributs qui permet d’identifier chaque
ligne de manière unique. Comme on a vu que deux lignes sont toujours différentes, l’ensemble de
tous les attributs est lui-même une clé mais on peut pratiquement toujours trouver un sous-
ensemble qui satisfait la condition. Pour distinguer la clé, nous mettrons le (ou les) attribut(s) en
gras. Film (titre, année, genre) : Le choix de la clé est très important pour la qualité du schéma.

Un tuple est une liste de n valeurs (v1, v2,..., vn) où chaque valeur vi est la valeur d’un attribut Ai
de domaine Di. Exemple: (’Cyrano’, 1992, ’Rappeneau’) ; Un tuple est donc simplement une
ligne dans la représentation d’une relation sous forme de table. En théorie, on connaît les valeurs
de tous les attributs du tuple.

0.2.1. Base de données relationnelle

Une (instance de) base de données est un ensemble fini (d’instances) de relations. Le schéma de
la base est l’ensemble des schémas des relations de cette base. La création d’un schéma de base
de données est simple une fois que l’on a déterminé toutes les relations qui constituent la base. En
revanche le choix de ces relations est un problème difficile car il détermine en grande partie les
caractéristiques et qualités de la base: performances, exactitude, exhaustivité, disponibilité des
informations, etc. Un des aspects importants de la théorie des bases de données relationnelles
consiste précisément à définir ce qu’est un
bon schéma et propose des outils formels pour y parvenir.

5
 Fig.0.2. Le schéma de la base de données Films

0.2.2. Les règles d’intégrité

Les règles d'intégrité sont les assertions qui doivent être vérifiées par les données contenues dans
une base. Le modèle relationnel impose les contraintes structurelles suivantes :

– Intégrité de Domaine
– Intégrité de clé
– Intégrité référentielle
La gestion automatique des contraintes d’intégrité est l’un des outils les plus importants d’une
base de données. Elle justifie à elle seule l’usage d’un SGBD.

Exemple d’intégrité référentielle:

CLIENT (no_client, nom, adresse)

ACHAT (no_produit, no_client, date, qte)

Clé étrangère no_client dans ACHAT

 Insertion tuple no_client = X dans ACHAT
o vérification si X existe dans CLIENT
 Suppression tuple no_client = X dans CLIENT
o soit interdire si X existe dans ACHAT
o soit supprimer en cascade tuple X dans ACHAT
o soit modifier en cascade X = NULL dans ACHAT
 Modification tuple no_client = X en X’ dans CLIENT
o soit interdire si X existe dans ACHAT
o soit modifier en cascade X en X’ dans ACHAT

6
0.3. Le langage SQL

SQL (Structured Query Language) est le langage de manipulation des données relationnelles le
plus utilisé aujourd’hui. Il est devenu un standard de fait pour les relationnels. Il possède des
caractéristiques proches de l’algèbre relationnelle (jointure par emboîtement) et d’autres proches
du calcul des tuples (variables sur les relations).

SQL est un langage de définition de données: SQL est un langage de définition de données
(LDD), c’est-à-dire qu’il permet de créer des tables dans une base de données relationnelle, ainsi
que d’en modifier ou en supprimer.

SQL est un langage de manipulation de données : SQL est un langage de manipulation de

données (LMD), cela signifie qu’il permet de sélectionner, insérer, modifier ou supprimer des
données dans une table d’une base de données relationnelle.

SQL est un langage de protections d’accès : Il est possible avec SQL de définir des permissions
au niveau des utilisateurs d’une base de données. On parle de DCL (Data Control Language).

0.3.1. Définition des données

Les exemples dans cette partie du cours s’appuient sur la base de données relative aux
fournisseurs (F), produits (P), usines (U) et livraisons (PUF), décrite par le schéma suivant:

F (NF, nomF, statut, ville)

P (NP, nomP, poids, couleur)
U (NU, nomU, ville)
PUF (NP, NU, NF, qt)

Pour créer une table, on utilise le couple de mots-clés CREATE TABLE.

La syntaxe est la suivante :
CREATE TABLE NomTable (
NomColonne1 TypeDonnée1,
NomColonne2 TypeDonnée2, ... );
CREATE TABLE U (
NU integer,
NomU char(30)
Ville char(30)
);

Les informations pouvant être mises à jour par les instructions suivantes :
• Ajouter des n-uplets : INSERT INTO
– Insérer une seule ligne :
INSERT INTO NomTable(colonne1,colonne2,colonne3,...)
VALUES (Valeur1,Valeur2,Valeur3,...)
– Insérer plusieurs lignes :
INSERT INTO NomTable(colonne1,colonne2,...)
SELECT colonne1,colonne2,... FROM NomTable2
WHERE qualification

7
(les valeurs inconnues prennent la valeur NULL)

• Modifier des n-uplets existants : UPDATE...SET...WHERE...

UPDATE NomTable
SET Colonne = ValeurOuExpression
WHERE qualification

• Supprimer des n-uplets : DELETE FROM...WHERE...

DELETE FROM NomTable
WHERE qualification

0.3.2. Interrogation d’une base de données

La commande SELECT permet d’interroger une BD. La syntaxe est la suivante :
SELECT [ALL|DISTINCT] NomColonne1,... | *
FROM NomTable1,...
WHERE Condition

Exemples :
1. Nom et poids des produits rouges.
SELECT nomP, poids
FROM P
WHERE couleur = "rouge"

2. Tous les renseignements sur tous les fournisseurs.

SELECT NF, nomF, statut, ville
FROM F
ou
SELECT * /* l'étoile signifie: tous les attributs*/
FROM F

3. Liste des couleurs qui existent (sans doublons)

SELECT DISTINCT couleur
FROM P

0.3.3. Concurrence d’accès

Plusieurs utilisateurs doivent pouvoir accéder en même temps aux mêmes données. Le SGBD
doit savoir :

– Gérer les conflits si les deux font des mises-à-jour.

– Offrir un mécanisme de retour en arrière si on décide d’annuler des modifications en cours.

– Donner une image cohérente des données si l’un fait des requêtes et l’autre des mises-à-jour.

Le but étant d’éviter les blocages, tout en empêchant des modifications anarchiques.

8
Une transaction est une unité logique de traitement qui est soit complètement exécutée, soit
complètement abandonnée. Une transaction fait passer la BD d'un état cohérent à un autre état
cohérent. Une transaction est terminée soit par COMMIT, soit par ROLLBACK.

Exemple du Banquier : Le transfert d'une somme S d’un compte C1 vers un compte C2

(1) début-transaction
(2) lire C1
(3) C1 := C1 - S
(4) écrire C1
(5) lire C2
(6) C2 := C2 + S
(7) écrire C2
(8) fin-transaction

Cette transaction est constituée d’un ensemble d’actions élémentaires, mais elle doit être traitée
comme une seule opération. Autrement dit le gestionnaire des transactions doit assurer que toutes
les actions de la transaction sont exécutées, ou bien qu’aucune ne l’est.

Un système de gestion transactionnel doit garantir les propriétés suivantes (résumées par le
vocable ACID) :

Atomicité : Une transaction doit effectuer toutes ses mises à jour ou ne rien faire du tout

Cohérence : La transaction doit faire passer la base de données d’un état cohérent à un autre

Isolation : Les résultats d’une transaction ne doivent être visibles aux autres transactions qu’une
fois la transaction validée

Durabilité : Dès qu’une transaction valide ses modifications, le système doit garantir que ces
modifications seront conservées en cas de panne.

De nombreuses solutions ont été proposées pour traiter le problème des accès concurrents. Un
exemple important est le protocole appelé verrouillage à deux phases qui est un des plus utilisés.

9
 Chapitre 1 :
Introduction au Big Data
1. 1. Introduction

Le “Big Data” est un concept très difficile à définir, puisque la notion même de “Big” en termes
de volumétrie des données varie d’une entreprise à l’autre. En règle générale, on considère du
BigData quand le traitement devient trop long pour une seule machine.

La notion de Big Data est un concept s’est popularisé en 2012 pour traduire le fait que les
entreprises sont confrontées à des volumes de données à traiter de plus en plus considérables et
présentant un fort enjeux commercial et marketing. Ces Grosses Données en deviennent difficiles
à travailler avec des outils classiques de gestion de base de données. Il s’agit donc d’un ensemble
de technologies, d’architecture, d’outils et de procédures permettant à une organisation de très
rapidement capter, traiter et analyser de larges quantités et contenus hétérogènes et changeants, et
d’en extraire les informations pertinentes à un coût accessible.

1.2. Les V du Big Data

1.2.1. Le Volume

On note, des volumes de données croissants de tous types, qui se comptent en pétaoctets ou
même en zétaoctets. Des solutions de stockage fiables sont nombreuses telles que : SAN (Storage
Area Networks) ou Stockage sur le cloud (Amazon S3)

1.2.2. La Variété

Les données traitées sont sous forme structurée (bases de données structurée, feuilles de calcul
venant de tableur,…) et non structurée (textes, sons, images, vidéos, données de capteurs, fichiers
journaux, medias sociaux, signaux,…) qui doivent faire l’objet d’une analyse collective.

1.2.3. La Vitesse

La vitesse fait référence à la vitesse à laquelle de nouvelles données sont générées et la vitesse à
laquelle les données sont traitées par le système pour être bien analysées. (parfois même des
teraoctets par jour).

1.2.4. La Véracité

La véracité fait référence à la qualité de la fiabilité et la confiance des données (Données bruités,
imprécises, prédictives, etc…)

1.2.5. La Valeur

10
La démarche Big Data n’a de sens que pour atteindre des objectifs stratégiques de création de
valeur pour les clients et pour l’entreprise; dans tous les domaines d’activité: commerce,
industrie, services…

1. 3. Caractéristiques des solutions Big Data

La plupart des outils et des frameworks de Big Data sont construits en gardant à l'esprit les
caractéristiques suivantes:

La distribution des données: Le grand ensemble de données est divisé en morceaux ou en petits
blocs et réparti sur un nombre N de nœuds ou de machines. Ainsi les données sont réparties sur
plusieurs noeuds et sont prêtes au traitement parallèle. En Big Data, ce type de distribution des
données est réalisé à l'aide d'un Système de Fichiers Distribués-DFS (Distributed File System).

Le traitement en parallèle: Lesdonnées distribuées obtiennent la puissance de N nombre de

serveurs et de machines dont les données résident.Ces serveurs travaillent en parallèle pour le
traitement et l'analyse. Après le traitement, les données sont fusionnées pour le résultat final
recherché.

La tolérance aux pannes: En général, nous gardons la réplique d'un seul bloc (ou chunk) de
données plus qu'une fois. Par conséquent, même si l'un des serveurs ou des machines est
complètement en panne, nous pouvons obtenir nos données à partir d'une autre machine ou d’un
autre «datacenter».

L'utilisation de matériel standard: La plupart des outils et des frameworks Big Data ont besoin du
matériel standard pour leur travail. Donc nous n'avons pas besoin de matériel spécialisé avec un
conteneur spécial des données «RAID»1. Cela réduit le coût de l'infrastructuretotale.

Flexibilité, évolutivité et scalabilité: Il est assez facile d'ajouter de plus en plus de noeuds dans le
cluster quand la demande pour l'espace augmente. De plus, la façon don’t les architectures de ces
frameworks sont faites, convient très bien le scénario de Big Data.

1.4. Les acteurs du Big Data

Les grands acteurs du web tel que Google, Yahoo, Facebook, Twitter, LinkedIn…ont été les
premiers à être confrontés à des volumétries de données extrêmement importantes et ont été à
l’origine des premières innovations en la matière portées principalement sur deux types de
technologies:

1. Les plate formes de développement et de traitement des données

(GFS,Hadoop,Spark,…)
2. Les bases de données (NoSQL)

1
Redundant Array of Independent Disks (Inexpensive)

11
 Chapitre 2 :
Introduction au MapReduce
2. 1. Introduction

MapReduce est à la fois un modèle de conception d’algorithmes et un cadre générique pour la

parallélisation des traitements. Il s’inspire du principe du « Diviser pour Régner ».

Problème initial

Diviser
W1 W2 W3

R1 R2 R3

Résultat Final Combiner

Fig. 2.1. Le principe du « Diviser pour Régner »

Pour un problème relevant du Big Data, le MapReduce se résume en deux grandes étapes : Le
Map et le Reduce qui se décomposent comme suit :

Map :

• Itérer sur un grand nombre d’enregistrements

• Extraire une information intéressante de chacun d’eux

Reduce :

• Regrouper et trier les résultats intermédiares

• Agréger les résultats intermédiares
• Produire le résultat final

2.2. Les étapes du MapReduce

Le processus MapReduce se base sur la structuration des données en paire: (clé, valeur). Deux
fonctions composent le processus : La fonction « Map » transforme les données d’entrée en une

12
liste de paires (clé,valeur) tandisque la fonction « Reduce » Agrège toute les valeurs associées à
la même clé.

Le processus se résume comme suit :

• Découper (SPLIT)
• Transformer (MAP)
• Grouper (SHUFFLE and SORT)
• Réduire (REDUCE)

2.3. Exemples illustratifs

2.3.1. Le comptage de mots

Imaginons qu'on nous donne un texte écrit en langue Française. On souhaite déterminer
pour un travail de recherche quels sont les mots les plus utilisés au sein de ce texte. Les données
d'entrée sont constituées du contenu du texte.

Première étape: déterminer une manière de découper (split) les données d'entrée pour que
chacune des machines puisse travailler sur une partie du texte. On décide de découper les
données d'entrée ligne par ligne. Chacune des lignes du texte sera un fragment de nos
données d'entrée.

Celui qui croyait au ciel

Celui qui n’y croyait pas
Fou qui fait le délicat
Fou qui songe à ses querelles

Il est de coutume de simplifier le travail en enlevant la ponctuation et les caractères accentués

ainsi que les majuscules. On obtient les quatre fragments suivants :

celui qui croyait au ciel

celui qui ny croyait pas
fou qui fait le délicat
fou qui songe a ses querelles

D’abord, on détermine la clé à utiliser pour l’opération MAP, et écrire son code. Comme on
s'intéresse aux occurrences des mots dans le texte, la clef qu’on choisit est le mot.
L’opération MAP consiste à parcourir le fragment considéré et, pour chacun des mots, émettre le
couple clef/valeur: (MOT ; 1). Cela signifie que nous avons rencontré une fois le mot. Le pseudo
code de la fonction Map peut être :

Pour chaque mot de la ligne

emettre (mot ; 1)

13
Pour nos fragments, les couples (clé,valeur) ainsi générés sont :

celui qui croyait au ciel (celui ;1) (qui ;1) (croyait ;1) (au ;1) (ciel ;1)
celui qui ny croyait pas (celui ;1) (qui ;1) (ny ;1) (croyait ;1) (pas ;1)
fou qui fait le délicat (fou ;1) (qui ;1) (fait ;1) (le ;1) (délicat ;1)
fou qui songe a ses querelles (fou ;1) (qui ;1) (songe ;1) (a ;1) (ses ;1) (querelles ;1)

Une fois l’opération « Map » achevée, un mécanisme intermédiaire permet de regrouper les
couples par clé commune ; on obtient :

(celui ;1) (celui ;1)

(qui ;1) (qui ;1) (qui ;1) (qui ;1)
(croyait ;1) (croyait ;1)
(fou ;1) (fou ;1)
(au ;1)
(ciel ;1)
etc.
La fonction « Reduce » considère chacun des groupements de clés où elle va opérer à une somme.
Le pseudo code peut être :

Total=0
Pour chaque Couple dans Groupe
Total=Total+1
emettre(mot ; total)

A la fin de l’opération, on obtient pour chaque mot son nombre d’apparition dans le texte.

(celui ;2) (qui ;4) (croyait ;2) (au ;1) (ciel ;1)
etc.

Fig. 2. 2. Flux de données MapReduce avec 1 seule tâche Reduce

14
2.3.2. Longueur moyenne des mots

On s’interesse maintenant à calculer la longueur moyenne des mots dans un texte. On procède
alors au découpage comme précédemment au texte d’entrée en lignes. Pour chaque ligne, on
calcule le nombre de mots et la longueur de la ligne (ie le nombre de caractères). La longueur
moyenne se fait selon la formule :
𝑛
1
𝜇 = ∑ 𝑥𝑖
𝑛
1

L'entrée de Map est un ensemble de mots {w} d'un fragment du texte, la fonction « Map » calcule
le nombre de mots dans le fragment et la longueur totale des mots. La sortie de la fonction
« Map » contient deux couples : <“count”, #mots> et <“length”, longueur totale>.

L'entrée de Reduce est un ensemble {<clé, {valeur}>}, où clé = “count” ou “length” et valeur est
un entier. La fonction « Reduce » calcule le nombre total de mots : N = somme de toutes les
valeurs “count” et la longueur totale des mots : L = somme de toutes les valeurs “length”

La sortie « Reduce » est <“count”, N> et <“length”, L>, Le résultat est obtenu en faisant la
division μ=L/N.

Fig. 2.3. Flux de données MapReduce avec 2 tâches Reduce

15
 Chapitre 3 :
Hadoop
3. 1. Introduction

Hadoop est une plateforme (framework) open source conçue pour

réaliser d'une façon distribuée des traitements sur des volumes de
données massives, de l'ordre de plusieurs pétaoctets. Ainsi, il est
destiné à faciliter la création d'applications distribuées et
échelonnables (scalables). Il s'inscrit donc typiquement sur le terrain
du Big Data.

Avec Hadoop, le Big Data est distribué en segments étalés sur une série de nœuds s’exécutant sur
des périphériques de base. Au sein de cette structure, les données sont dupliquées à différents
endroits afin de récupérer l’intégralité des informations en cas de panne. Il s'occupe de toutes
les problématiques liées au calcul distribué, comme l’accès et le partage des données, la
tolérance aux pannes, ou encore la répartition des tâches aux machines membres du cluster: le
programmeur a simplement à s'occuper du développement logiciel pour l'exécution de la
tâche.

3.2. Composants de Hadoop

Hadoop est constitué de deux grandes parties :

• Hadoop Distibuted File System – HDFS : destiné pour le stockage distribué des
données
• Distributed Programing Framework - MapReduce : destiné pour le traitement distribué
des données.

3.2.1. HDFS

HDFS (pour Hadoop Distributed File System) est un système de gestion fichiers distribué associé
à Hadoop. HDFS permet l'abstraction de l'architecture physique de stockage, afin de
manipuler un système de fichiers distribué comme s'il s'agissait d'un disque dur unique. HDFS se
démarque d'un système de fichiers classique pour les principales raisons suivantes :

HDFS n'est pas solidaire du noyau du système d'exploitation. Il assure une portabilité et peut être
déployé sur différents systèmes d'exploitation.

HDFS est un système distribué. Sur un système classique, la taille du disque est
généralement considérée comme la limite globale d'utilisation. Dans un système distribué
comme HDFS, chaque nœud d'un cluster correspond à un sous-ensemble du volume global

16
de données du cluster. Pour augmenter ce volume global, il suffit d'ajouter de nouveaux
nœuds.

HDFS utilise des tailles de blocs largement supérieures à ceux des systèmes classiques. Par
défaut, la taille est fixée à 64 Mo. Il est toutefois possible de monter à 128 Mo, 256 Mo, 512 Mo
voire 1 Go. Alors que sur des systèmes classiques, la taille est généralement de 4 Ko,
l'intérêt de fournir des tailles plus grandes permet de réduire le temps d'accès à un bloc.

HDFS fournit un système de réplication des blocs dont le nombre de réplications est
configurable. Pour la phase de lecture, si un bloc est indisponible sur un nœud, des copies de ce
bloc seront disponibles sur d'autres nœuds.

Une architecture de machines HDFS (aussi appelée trois types de composants majeurs :

NameNode : Un Namenode est un service central (généralement appelé aussi maître) qui
s'occupe de gérer l'état du système de fichiers. Il maintient l'arborescence du
système de fichiers et les métadonnées de l'ensemble des fichiers et répertoires d'un
système Hadoop.

Secondary Namenode : Le Namenode dans l'architecture Hadoop est un point unique de

défaillance (Single Point of Failure en anglais). Si ce service est arrêté, il n'y a pas un
moyen de pouvoir extraire les blocs d'un fichier donné. Pour répondre à cette problématique, un
Namenode secondaire appelé Secondary Namenode a été mis en place dans l'architecture Hadoop
version2. Son fonctionnement est relativement simple puisque le Namenode secondaire vérifie
périodiquement l'état du Namenode principal et copie les métadonnées.

Datanode : Un Datanode contient les blocs de données. En effet, il stocke les blocs de données
lui-mêmes. Il y a un DataNode pour chaque machine au sein du cluster. Les Datanodes sont
sous les ordres du Namenode et sont surnommés les
Workers. Ils sont donc sollicités par les Namenodes lors des opérations de lecture et
d'écriture.

Fig. 2.1. Architecture HDFS

17
3.2.2. MapReduce

Comme pour HDFS, la gestion des tâches de Hadoop se base sur deux serveurs (des
daemons):

• Le JobTracker, qui va directement recevoir la tâche à exécuter (un .jar Java), ainsi que
les données d'entrées (nom des fichiers stockés sur HDFS) et le répertoire où stocker les données
de sortie (toujours sur HDFS). Il y a un seul JobTracker sur une seule machine du
cluster Hadoop. Le JobTracker est en communication avec le NameNode de HDFS et sait
donc où sont les données.

• Le TaskTracker, qui est en communication constante avec le JobTracker et va recevoir les

opérations simples à effectuer (MAP/REDUCE) ainsi que les blocs de données correspondants
(stockés sur HDFS). Il y a un TaskTracker sur chaque machine du cluster.

L'entrée de MapReduce doit être faite à partir de fichiers dans HDFS où Chaque bloc contient
une liste de pairs clé-valeur.

18
 Chapitre 4 :
Les Bases de Données NoSQL
4. 1. Introduction

L’essor des très grandes plateformes et applications Web (Google, Facebook, Twitter, LinkedIn,
Amazon, …) et le volume considérable de données à gérer par ces applications nécessitant une
distribution des données et leur traitement sur de nombreux serveurs : « Data Centers » ; ces
données étant souvent associées à des objets complexes et hétérogène ont montré les limites des
SGBD traditionnels (relationnels et transactionnels) basés sur SQL.

Ainsi, de nouvelles approches de stockage et de gestion des données sont apparues, permettant
une meilleure scalabilité dans des contextes fortement distribués et offrant une gestion d’objets
complexes et hétérogènes sans avoir à déclarer au préalable l’ensemble des champs représentant
un objet.

Ces approches regroupées derrière le terme NoSQL (proposé par Carl Strozzi) ne se substituent
pas aux SGBD Relationnels mais les complètent en comblant leurs faiblesses (Not Only SQL).

4.2. Limites des SGBD relationnels

Les SGBD Relationnels offrent un système de jointure entre les tables permettant de construire
des requêtes complexes impliquant plusieurs entités ainsi qu’un système d’intégrité référentielle
permettant de s’assurer que les liens entre les entités sont valides. Dans un contexte fortement
distribué, ces mécanismes ont un coût considérable. En effet, avec la plupart des SGBD
relationnels, les données d’une BD liées entre elles sont placées sur le même nœud du serveur. Si
le nombre de liens important, il est de plus en plus difficile de placer les données sur des noeuds
différents.

D’autre part, les SGBD Relationnels sont généralement transactionnels et la gestion de

transactions respectant les contraintes ACID (Atomicity, Consistency, Isolation, Durability).
Dans un contexte fortement distribué, cette gestion a un coût considérable car il est nécessaire de
distribuer les traitements de données entre différents serveurs, il devient alors difficile de
maintenir les contraintes ACID à l’échelle du système distribué entier tout en maintenant des
performances correctes. De ce fait, la plupart des SGBD « NoSQL » relâchent les contraintes
ACID, ou même ne proposent pas de gestion de transactions.

4.2.1. Modèle de données relationnel vs Agrégats

Modèle relationnel :

 les données sont divisées en ligne (tuples) avec des colonnes prédéfinies (attributs)

19
  il n’y a pas de tuples emboîtés
 il n’y a pas de liste de valeurs

Modèle agrégat :

 une collection d’objets reliés

 qui doivent être traités ensemble.

Fig. 4.1. Modèle relationnel vs agrégat

4.2.2. Le théorème CAP

Soit les trois propriétés fondamentales pour les systèmes distribués :

Cohérence (Consitency): tous les nœuds du système voient exactement les mêmes données au
même moment

Disponibilité (Availability): la perte de nœuds n'empêche pas les survivants de continuer à

fonctionner correctement, les données restent accessibles

Résistance au partitionnement (Partition tolerance) : le système étant partitionné, aucune

panne moins importante qu'une coupure totale du réseau ne doit l’empêcher de répondre
correctement (en cas de partitionnement en sous réseaux, chacun doit pouvoir fonctionner de
manière autonome)

Théorème de CAP (Brewer, 2000) : 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 les 3.

20
Les SGBDR assurent les propriétés de Consistance et de Disponibilité (AC), tandisque les SGBD
« NoSQL » sont des systèmes AP (Disponible et Résistant au partitionnement) ou CP (Cohérent
et Résistant au partitionnement).

4.3. Caractéristiques générales des BD NoSQL

Les BD NoSQL :

 Adoptent une représentation de données non relationnelle

 ne remplacent pas les BD relationnelles mais sont une alternative, un complément
apportant des solutions plus intéressantes dans certains contextes
 apportent une plus grande performance dans le contexte des applications Web avec des
volumétries de données exponentielle
 utilisent une très forte distribution de ces données et des traitements associés sur de
nombreux serveurs
 font un compromis sur le caractère « ACID » des SGBDR pour plus de scalabilité
horizontale et d’évolutivité.

L’adoption croissante des bases NoSQL par des grands acteurs du Web (Google, faceBook, …)
favorise la multiplication des offres de systèmes NoSQL.

4.4. Fondements des systèmes NoSQL

Les systèmes NoSQL se fondent sur les éléments suivants :

4.4.1. Le Sharding

Le « Sharding » est un ensemble de techniques qui permet de répartir les données sur plusieurs
machines pour assurer la scalabilité de l’architecture.

C’est un mécanisme de partitionnement horizontal (par tuples) des données dans lequel les
objets-données sont stockées sur des nœuds serveurs différents en fonction d’une clé (ex :
fonction de hachage).

Certains systèmes utilisent aussi un partitionnement vertical (par colonnes) dans lequel des
parties d'un enregistrement sont stockées sur différents serveurs.

4.4.2. Le « Consistent hashing»

Le « Consistent hashing» est un mécanisme de partitionnement (horizontal) dans lequel les objet-
données sont stockés sur des nœuds-serveurs différents en utilisant la même fonction de hachage
à la fois pour le hachage des objets et le hachage des nœuds.

4.4.3. Le « Map Reduce »

21
Le « Map Reduce » est un modèle de programmation parallèle permettant de paralléliser tout un
ensemble de tâches à effectuer sur un ensemble de données,

4.4.4. Le MVCC

Le « MVCC » (Contrôle de Concurrence Multi-Version) est un mécanisme permettant d’assurer

le contrôle de concurrence,

4.4.5. Le « Vector – Clock »

Le « Vector-Clock» ou horloges vectorielles permet des mises à jours concurrentes en datant les
données par des vecteurs d’horloge.

4.5. Typologie des BD NoSQL

Selon la représentation adopté pour les données, différents types de BD NoSQL existent :

« Clé-valeur / Key-value » : basique, chaque objet est identifié par une clé unique constituant la
seule manière de le requêter.

 Voldemort, Redis, Riak, …

« Colonne / Column » : permet de disposer d'un très grand nombre de valeurs sur une même
ligne, de stocker des relations « one-to-many », d’effectuer des requêtes par clé (adaptés au
stockage de listes : messages, posts, commentaires, ...)

 HBase, Cassandra, Hypertable, …

« Document » : pour la gestion de collections de documents, composés chacun de champs et de

valeurs associées, valeurs pouvant être requêtées (adaptées au stockage de profils utilisateur).

 MongoDBn, CouchDB, Couchbase, …

« Graphe » : pour gérer des relations multiples entre les objets (adaptés au données issues de
réseaux sociaux, …)

 Neo4j, OrientDB, …

4.5.1. Le modèle « Clé-Valeur »

Les BD selon le modèle « Clé – Valeur » fonctionnent comme un grand tableau associatif et
retourne une valeur dont elle ne connaît pas la structure.

Les données sont simplement représentées par un couple clé/valeur, la valeur peut être une simple
chaîne de caractères, ou un objet sérialisé…Cette absence de structure ou de typage ont un impact
important sur le requêtage : toute l’intelligence portée auparavant par les requêtes SQL devra être
portée par l’applicatif qui interroge la BD. La structure de l’objet est libre, souvent laissé à la

22
charge du développeur de l’application (XML, JSON, ...), la base ne gérant généralement que des
chaînes d’octets.

Fig. 4.2. Une BD selon le modèle « clé/Valeur »

Leur exploitation est basée sur 4 opérations (CRUD):

C reate : créer un nouvel objet avec sa clé → create(key, value)

R ead : lit un objet à partir de sa clé → read(key)

U pdate : met à jour la valeur d’un objet à partir de sa clé → update(key, value)

D elete: supprime un objet à partir de sa clé → delete(key)

Elles disposent généralement d’une simple interface de requêtage HTTP REST accessible depuis
n’importe quel langage de développement. Elles ont des performances très élevées en lecture et
en écriture et une scalabilité horizontale considérable tandis que le besoin en scalabilité verticale
est faible du fait de la simplicité des opérations effectuées.

Forces :

 modèle de données simple

 bonne mise à l’échelle horizontale pour les lectures et écritures :

 évolutivité (scalable)

 disponibilité

 pas de maintenances requises lors d'ajout/suppression de colonnes

Faiblesses :

 modèle de données TROP simple :

 pauvre pour les données complexes

23
  interrogation seulement sur clé

 déporte une grande partie de la complexité de l'application sur la couche

application elle-même

4.5.2. Le modèle « Colonne »

Les bases orientés colonnes sont les plus complexes à appréhender parmi la mouvance NoSQL.
Bien que l’on obtienne au final un schéma relativement proche des bases documentaires,
l’organisation sous-jacente des données permet à ces bases d’exceller dans les traitements
d’analyse de données et dans les traitements massifs (notamment via des opérations de type
MapReduce).

Les principaux concepts associés sont les suivants :

Colonne : c’est une entité de base représentant un champ de donnée. Chaque colonne est définie
par un couple clé / valeur et une colonne contenant d’autres colonnes est nommée supercolonne.

Famille de colonnes : Elles permettent de regrouper plusieurs colonnes (ou supercolonnes). Les
colonnes sont regroupées par ligne où chaque ligne est identifiée par un identifiant unique
(assimilées aux tables dans le modèle relationnel) et sont identifiées par un nom unique.

Supercolonnes: situées dans les familles de colonnes, elles sont souvent utilisées comme les
lignes d’une table de jointure dans le modèle relationnel.

Ce modèle est proche d’une table dans un SGBDR mais ici le nombre de colonnes est dynamique
et peut varier d’un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des
valeurs NULL.

Exemple :

Soit le tuple pour le client 1234, on a

• table « Clients » partitionnée en 2 familles de colonnes : « Profile » et « Orders »

• chaque famille de colonnes a des colonnes (e.g. name et payment), des super colonnes
avec un nom et un nombre arbitraire de colonnes associées

24
 Fig.4. 3. Exemple du modèle « Colonne »

Forces :

 Modèle de données supportant des données semi-structurées (clairsemées)

 naturellement indexé (colonnes)

 bonne mise à l'échelle à l'horizontale

 MapReduce souvent utilisé en scaling horizontal,

 on peut voir les résultats de requêtes en temps réel

Faiblesses :

 A éviter pour des données interconnectés : si les relations entre les données sont aussi
importantes que les données elles-mêmes

 à éviter pour les lectures de données complexes

 exige de la maintenance - lors de l'ajout / suppression de colonnes et leur regroupements

4.5.3. Le modèle « Document »

Les BD « Document » stockent une collection de "documents". Elles sont basées sur le modèle «
clé-valeur » mais la valeur est un document en format semi-structuré hiérarchique de type JSON
ou XML (possible aussi de stocker n'importe quel objet, via une sérialisation). Les documents

25
n'ont pas de schéma, mais une structure arborescente : ils contiennent une liste de champs, un
champ a une valeur qui peut être une liste de champs, ...

Elles ont généralement une interface d’accès HTTP REST permettant d’effectuer des requêtes
(plus complexe que l’interface CRUD des BD clés/valeurs).

Un document est composé de champs et des valeurs associées. Ces valeurs peuvent être requêtées
et sont soit :

 d’un type simple (entier, chaine de caractère, date, ...)

 elles-mêmes composées de plusieurs couples clé/valeur.

Bien que les documents soient structurés, ces BD sont dites “schemaless” car il n’est pas
nécessaire de définir au préalable les champs utilisés dans un document et les documents peuvent
être très hétérogènes au sein de la BD. Elles permettent d’effectuer des requêtes sur le contenu
des documents/objets : pas possible avec les BD clés/valeurs simples et sont principalement
utilisées dans le développement de CMS (Content Management System - outils de gestion de
contenus).

Le code suivant est un exemple de document JSON basé sur une application web où on publie
des articles sur différents sujets, rédigés par les membres du site, et que les lecteurs peuvent
évaluer et commenter. Ce document JSON stocke un article dont le titre est « Pourquoi les
éléphants ont-ils de grandes oreilles ? » et qui comporte déjà un commentaire.

{
«auteur»:
{
«prénom»:»Annie»,
«nom»:»Brizard»,
«e-mail»:»annie.brizard@cocomail.com»
},
«titre»:»pourquoi les éléphants ont-ils de grandes oreilles ?»,
«mots-clés»:
[
«faune»,
«afrique»,
«questions intriguantes»
],
«catégories»:
[
«sciences»,
«éducation»,
«nature»
],
«date_création»: «12/05/2012 23:30»,
«statut»:»publié»,
«nombre_de_lectures»:»54»,
«commentaires»:
[
{

26
«date»:»14/05/2012 10:12»,
«auteur»:»fred92@jmenmail.fr»,
«contenu»:»il n’y a pas que les éléphants qui ont des grandes oreilles !»
}
]
}

Forces :

• modèle de données simple mais puissant (expression de structures imbriquées)

• bonne mise à l'échelle (surtout si le sharding est pris en charge)

• pas de maintenance de la BD requise pour ajouter/supprimer des «colonnes»

• forte expressivité de requêtage (requêtes assez complexes sur des structures imbriquées)

Faiblesses :

• inadaptée pour les données interconnectées

• modèle de requête limitée à des clés (et indexes)

• peut alors être lent pour les grandes requêtes (avec MapReduce)

4.5.4. Le modèle « Graphe »

Les BD « Graphe » permettent la modélisation, le stockage et la manipulation de données

complexes liées par des relations non-triviales ou variables. C’est un modèle de représentation
des données basé sur la théorie des graphes et qui s’appuie sur les notions de nœuds, de relations
et de propriétés qui leur sont rattachées.

Forces :

• modèle de données puissant

• rapide pour les données liées, bien plus rapide que les SGBDR

• modèles d’interrogation bien établis et performants.

Faiblesses :

• Fragmentation (sharding) :

– Même si elles peuvent évoluer assez bien

– Pour certains domaines, on peut aussi fractionner.

27
 Chapitre 5 :
HBase
5. 1. Introduction

HBase est un système de stockage efficace pour des données très volumineuses. Il permet
d’accéder aux données très rapidement même quand elles sont gigantesques. Une variante de
HBase est notamment utilisée par FaceBook pour stocker tous les messages SMS, email et chat.

Fig. 5.1. HBase dans l’écosystème Hadoop

5.2. Présentation

HBase mémorise des n-uplets constitués de colonnes (champs). Les n-uplets sont identifiés par
une clé. À l’affichage, les colonnes d’un même n-uplet sont affichées successivement :

Clés Colonnes et Valeurs

isbn7615 colonne=auteur valeur="Jules Verne"

isbn7615 colonne=titre valeur="De la Terre à la Lune"

isbn7892 colonne=auteur valeur="Jules Verne"

isbn7892 colonne=titre valeur="Autour de la Lune"

28
Voici quelques caractéristiques de HBase :

 Les n-uplets sont classés selon leur clé, dans l’ordre alphabétique. Cette particularité est
extrêmement importante pour la recherche d’informations. On est amené à définir les clés
de façon à rapprocher les données connexes. Les n-uplets de HBase peuvent être
incomplets. Les colonnes ne sont pas forcément remplies pour chaque n-uplet, au point
qu’on peut même avoir des colonnes différentes pour les n-uplets.

 Ce ne sont pas des valeurs null, mais des colonnes carrément absentes. On qualifie ça de «
matrice creuse » (sparse data).

 Les colonnes appelées qualifiers sont groupées en familles.

 Les valeurs, appelées cellules sont enregistrées en un certain nombre de versions, avec
une date appelée timestamp.

Au plus haut niveau, une table HBase est un dictionnaire <clé, n-uplet> trié sur les clés,

 Chaque n-uplet est une liste de familles,

 Une famille est un dictionnaire <nomcolonne, cellule> trié sur les noms de colonnes
(aussi appelées qualifier),

 Une cellule est une liste de (quelques) paires <valeur, date>.

 La date, un timestamp permet d’identifier la version de la valeur.

Donc finalement, pour obtenir une valeur isolée, il faut fournir un quadruplet :

(clé, nomfamille, nomcolonne, date)

Si la date est omise, HBase retourne la valeur la plus récente.

Exemple :

On veut enregistrer les coordonnées et les achats de clients. On va construire une table contenant
trois familles:

 La famille personne contiendra les informations de base:

 colonnes personne:nom et personne:prenom

 La famille coords contiendra l’adresse :

 colonnes coords:rue, coords:ville, coords:cp, coords:pays

 La famille achats contiendra les achats effectués :

29
  colonnes achats:date, achats:montant, achats:idfacture

HBase autorise à dé-normaliser un schéma (redondance dans les informations) afin d’accéder aux
données plus rapidement.

5.3. Commandes de base

5.3.1. Création d’une table

create 'NOMTABLE', 'FAMILLE1', 'FAMILLE2'...

D’autres propriétés sont possibles, par exemple VERSIONS pour indiquer le nombre de versions
à garder.

Remarques : Les familles doivent être définies lors de la création. C’est coûteux de créer une
famille ultérieurement.

On ne définit que les noms des familles, pas les colonnes. Les colonnes sont créées
dynamiquement.

5.3.2. Destruction d’une table

Il faut d’abord désactiver la table, puis la supprimer :

1. disable 'NOMTABLE'

2. drop 'NOMTABLE'

Désactiver la table permet de bloquer toutes les requêtes.

5.3.3. Ajout et suppression de n-uplets

 Ajout de cellules

Un n-uplet est composé de plusieurs colonnes. L’insertion d’un n-uplet se fait colonne par
colonne.

On indique la famille de la colonne. Les colonnes peuvent être créées à volonté.

put 'NOMTABLE', 'CLE', 'FAM:COLONNE', 'VALEUR‘

 Suppression de cellules

Il y a plusieurs variantes selon ce qu’on veut supprimer, seulement une valeur, une cellule, ou
tout un n-uplet :

deleteall 'NOMTABLE', 'CLE', 'FAM:COLONNE', TIMESTAMP

30
deleteall 'NOMTABLE', 'CLE', 'FAM:COLONNE'

deleteall 'NOMTABLE', 'CLE'

5.3.4. Affichage de n-uplets

La commande « get » affiche les valeurs désignées par une seule clé. On peut spécifier le nom de
la colonne avec sa famille et éventuellement le timestamp.

get 'NOMTABLE', 'CLE'

get 'NOMTABLE', 'CLE', 'FAM:COLONNE'

get 'NOMTABLE', 'CLE', 'FAM:COLONNE', TIMESTAMP

La première variante affiche toutes les colonnes ayant cette clé. La deuxième affiche toutes les
valeurs avec leur timestamp.

5.3.5. Recherche de n-uplets

La commande scan

La commande « scan » affiche les n-uplets sélectionnés par les conditions.

scan 'NOMTABLE', {CONDITIONS}

Parmi les conditions possibles :

COLUMNS=>['FAM:COLONNE',...] pour sélectionner certaines colonnes.

STARTROW=>'CLE1', STOPROW=>'CLE2' pour sélectionner les n-uplets de [CLE1, CLE2[.

Ou alors (exclusif), une condition basée sur un filtre :

FILTER=>"PrefixFilter('binary:client')"

Les filtres

L’ensemble des filtres d’un « scan » doit être placé entre "...".

Plusieurs filtres peuvent être combinés avec AND, OR et les parenthèses.

Exemple :

{ FILTER => "PrefixFilter('client') AND ColumnPrefixFilter('achat')" }

 PrefixFilter('chaîne') : accepte les valeurs dont la clé commence par la chaîne

ColumnPrefixFilter('chaîne') : accepte les valeurs dont la colonne commence par la chaîne.

31
Ensuite, on a plusieurs filtres qui comparent quelque chose à une valeur constante. La syntaxe
générale est du type :

MachinFilter(OPCMP, VAL), . . . avec OPCMP VAL définies ainsi :

 OPCMP doit être l’un des opérateurs <, <=, =, !=, > ou >= (sans mettre de quotes
autour)

 VAL est une constante qui doit valoir :

 'binary:chaine' pour une chaîne telle quelle

 'substring:chaine' pour une sous-chaîne

 …

Exemple :

{ FILTER => "ValueFilter(=,'substring:univ-annaba')"}

Plusieurs filtres questionnent la clé, famille ou colonne d’une valeur :

 RowFilter(OPCMP, VAL)

 FamilyFilter(OPCMP, VAL)

 QualifierFilter(OPCMP, VAL)

Le filtre suivant accepte les n-uplet dont la clé, famille, colonne correspond à la constante

 SingleColumnValueFilter('fam','col',OPCMP,VAL)

Il garde les n-uplets dont la colonne 'fam:col' correspond à la constante. Ce filtre est utile pour
garder des n-uplets dont l’un des champs possède une valeur qui nous intéresse.

 ValueFilter(OPCMP, VAL)

accepte les valeurs qui correspondent à la constante

32
 Chapitre 6 :
Introduction à MongoDB
6.1. Introduction

MongoDB (de l'anglais humongous qui peut être traduit par « énorme ») est un SGBD NOSQL
orientée documents à schéma flexible et distribuable, développé depuis 2007 par la société de
logiciel 10gen. MongoDB est écrit en C++ et distribuée sous licence AGPL (licence libre) et très
adaptée aux applications web.

MongoDB a été adoptée par plusieurs grands noms de l’informatique, tels que Foursquare, SAP,
ou bien même GitHub. Il manipule des documents au format BSON (Binary JSON), qui est un
dérivé de JSON plus axé sur la performance, fonctionnant comme une architecture distribuée
centralisée.

Télécharger MongoDB à partir de https://www.mongodb.com/download-center#community

6.2. Présentation

6.2.1. Les collections

Une collection c’est l’équivalent de la table en relationnel, les valeurs peuvent être complexes
(listes, dictionnaires), il y a deux modes de création :

i. Automatiquement lors d’une insertion de document (tuple)

ii. En exécutant la commande db.createCollection(‘<nom_collection>’);

Exemple d’une collection :

6.2.2. Les opérations sur les collections

Créer :

> db.createCollection(' nom_collection ');

Lister :

33
 > show collections;

> db.getCollections();

Insérer un document :

> db.< nom_collection >.insert( { var1: "valeur", var2: "valeur", var3: "valeur", } );

Supprimer :

> db.<nom_collection>.drop();

6.2.3. Les documents

Un document est l’équivalent d’un enregistrement (tuple) en relationnel,

Il y a deux modes d’insertion :

i. En utilisant la commande db.<nom_collection>.insert() du schell

ii. En utilisant la commande db.<nom_collection>.save () du schell

Chaque document crée contient le champ « _id » : c’est le seul champ obligatoire, utilisé comme
clef primaire dans une collection il est généré automatiquement et indexé.

Le document supporte plus de types de données que JSON composée de paires clef/valeur,
MongoDB stocke les documents au format BSON (Binary JSON) ou BSON est la représentation
binaire des objets JSON.

Le format JSON

JSON (JavaScript Object Notation) :

 Permet de représenter de l’information structurée

 Format de données textuelle

 Utilise une notation JavaScript

 Décrit par la RFC 4627

Un document JSON, ne comprend que deux éléments structurels :

1. des ensembles de paires nom / valeur.

2. des listes ordonnées de valeurs.

34
Structure des documents

1. Références :

 Inclusion de liens ou références d’un document à un autre

 C’est à l’application de résoudre ces références pour accéder aux données associées

 On dit qu’on utilise des Modèles de Données Normalisés.

Exemple :

2. Données Imbriquées (Embedded Data) :

 Sauvegarde des données associées dans la même structure de documents

 Il est possible d’inclure des documents dans un champ ou un tableau

 Permet aux applications d’extraire et manipuler plusieurs niveaux de hiérarchie en une

seule instruction

 Ce sont les Modèles de Données Dé normalisés.

Exemple :

35
 6.2.4. Les opérations « CRUD »

Pour insérer des données dans la collection MongoDB il faut utiliser la syntaxe suivante :

 db.NomCollection.insert( document ) ; ou

 db.NomCollection.insert( documents ) ; pour plusieurs documents.

Exemple :

>db.films.insert({
‘titre’ : ‘Le cercle’,
‘genre’ : ‘horreur’,
‘annee’ : 2017
})

Pour interroger les données de la collection MongoDB il faut utiliser la méthode « find() », les
syntaxes pour cette méthode sont :

 db.NomCollection.find() ;
 db.NomCollection.find(Requête) ;
 db.NomCollection.find(Requête, Projection) ;

Sans paramètre : tous les documents sont renvoyés

Requête : est un tableau clefs / valeurs spécifiant des opérateurs sur les champs des documents
recherchés

Projection : est un tableau permettant de limiter les champs que l’on souhaite consulter dans les
documents recherchés

Exemple : soit la collection « films » contient les documents suivant :

{ "_id" : ObjectId("59089552387a"), "titre" : "le cercle", "genre" : "horreur", "année" :

"2017" }

{ "_id" : ObjectId("590895ea387b"), "titre" : "arsenal", "genre" : " thriller", "année" :

"2017" }

{ "_id" : ObjectId("59089629387c"), "titre" : "criminel", "genre" : " policier", "année" :

"2016" }

La commande suivante n’affiche que les titres des films :

>db.films .find({},{"titre":1,_id:0})

36
 {"titre" :"le cercle"}

{"titre" :"arsenal"}

{"titre" :"criminel"}

Utilisation des opérateurs dans la recherche : Dans la plupart des cas, les recherches sont plus
complexes. On peut alors utiliser des opérateurs logiques au lieu de simplement donner une
valeur. Voici quelques opérateurs courants, avec des exemples d’utilisation :

Opérateur Signification Exemple

$gt, $gte, $lt, $lte >, >=, <, <= age: {$gte: 20, $lt: 30}

$exists Test sur l'existence d'un adresse: {$exists: true}

champ

$type Test sur le type d'un champ nom: {$type: 2}

$regex Recherche de pattern dans prénom: {$regex: "o$"}

une chaine

$or OU logique sur les clauses $or: [{prénom: {$regex:

fournies dans le tableau "o$" }},adresse: {$exists: true}]

$and ET logique sur les clauses $and: [{prénom: {$regex:"o$" }},

fournies dans le tableau adresse: {$exists: true}]

Pour mettre à jour le document dans une collection il faut utilisé la méthode « Update() », la
syntaxe est la suivante : db.collection.update(Requête, Modifications) ;

Requête : est de la même forme que pour « find() »

Modifications : est un tableau clefs / valeurs définissant des opérations sur les champs.

Exemple : on utilise l’exemple précèdent :

>db.films.update({‘titre':’criminel'},{$set:{‘annee':2015}}) ;

>db.films.find() ;

{ "_id" : ObjectId("59089552387a"), "titre" : "le cercle", "genre" : "horreur", "année" :

"2017" }

{ "_id" : ObjectId("590895ea387b"), "titre" : "arsenal", "genre" : " thriller", "année" :

"2017" }

37
 { "_id" : ObjectId("59089629387c"), "titre" : "criminel", "genre" : " policier", "année" :
"2015" }

Pour supprimer un document dans une collection il faut utilisé la méthode « Remove() », les
syntaxes est les suivantes :

 db.collection.remove() ;
 db.collection.remove(Requête) ;

Sans paramètre : tous les documents sont supprimés.

Requête : Elle désigne les documents qui seront supprimés.

Exemple : La commande suivante supprime tous les documents dont l’année est « 2017 » :

>db.films.remove({‘annee':2017}) ;

>db.films.find() ;

{ "_id" : ObjectId("59089629387c"), "titre" : "criminel", "genre" : " policier", "année" :

"2015" }

6.3. MongoDB vs SQL

SQL Insert MongoDB Insert

INSERT INTO film(titre,genre,annee) db.film.insert({

VALUES (“le cercle",” horreur”,2017) ‘titre’ : ‘le cercle’,
‘genre’ : ‘horreur’,
‘annee’ : 2017
})

Select SQL Select MongoDB

SELECT * FROM film db.film.find()

SELECT id,titre,genre FROM film db.film.find({ 'titre': 1, 'genre': 1 })

SELECT titre,genre FROM film db.film.find({ 'titre': 1, 'genre':

1,_id:0 })
SELECT * FROM film WHERE annee = 2017 db.film.find({ 'annee': 2017 })

38
SELECT * FROM film WHERE annee != 2017 db.film.find( { 'annee':
{ $ne:2017 } } )
SELECT * FROM people WHERE genre="horreur" AND db.film.find(
annee=2017 { 'genre': 'horreur',annee: 2017 })
SELECT * FROM film WHERE genre = "thriller" OR db.film.find(
annee = 2016 { $or: [ { 'genre': 'thriller' } ,
{ 'annee': 2016 } ] })

Update SQL Update MongoDB

UPDATE film SET genre = "romance" WHERE db.film.updateMany(

annee < 2017 { 'annee': { $lt: 2017 } },
{ $set: { genre: "romance" } }
)
UPDATE film SET annee = annee + 1 WHERE db.film.updateMany(
titre = "le cercle" { titre: "le cercle" } ,
{ $inc: { annee: 1 } }
)

SQL delete MongoDB delete

DELETE FROM film db.film.deleteMany()

DELETE FROM film WHERE genre = "policier" db.film.deleteMany( { 'genre': 'policier' } )

39
 Annexe

40
 Références

Rudi Bruchez, Les bases de données NoSQL: Comprendre et mettre en œuvre, Eyrolles, 2013.

Eelco Plugge, Peter Membrey et Tim Hawkins, The Definitive Guide to MongoDB, Apress,
2010.

Tom White, Hadoop: The Definitive Guide, O’Reilly, 2015.

http://juvenal-chokogoue.developpez.com/tutoriels/hadoop-fonctionnement/

http://www.mbds-fr.org/wp-
content/uploads/2014/09/mooc_fun_big_data_semaine_9_hadoop.pdf

41