REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix-travail-patrie Peace-work-fatherland
******** ********
UNIVERSITE DE DOUALA THE UNIVERSITY OF DOUALA
******** *********
ECOLE DOCTORALE DES SCIENCES POSTGRA DUATE SCHOOL FOR P URE
FONDAMENTALES ET APPLIQUEES APPLIED SCIENCES
(EDOSFA) (POSPAS)
BP 8580 DOUALA PO BOX 8580 DOUALA
TEL. 697916557 TEL.697916557
email : edosfauvdl@yahoo.com email : edosfauvdl@yahoo.com

Laboratoitre informatique appliquee

LE BIG DATA: NOSQL

LES MEMBRES SONT:

Noms et prenoms Matricule
TAGA SIGNE KENNEDY MARTIAL
DONGMO APPOLINAIRE
YNSUFU ALI

Sous l’encadrement de : Dr. moskolai

Année Académique 2020/2021

 PLAN
Introduction
 GENERALITES
 CARACTERISTIQUE DES NoSQL
 CARACTERISTIQUE DES NoSQL
 LES TROIS PROPRIÉTÉS POUR LES
SYSTÈMES DISTRIBUÉS
 MODELES OU TYPES DE BASE DE DONNEE NO
SQL
 GRAPHE
 COMPARAISON ENTRE SGBDR ET MODÈLES DE SGBD
NOSQL
 AVANTAGES ET INCONVÉNIENT DE NO SQL
 CONCLUSION
 BIBLIOGRAPHIE
 Introduction
1. le terme NOSQL regroupe des solutions récentes qui
se différencient du modèle SQL par une logique de
représentation des données différentes.

1. Leurs principaux avantages sont leurs performances et

leur capacité à traiter de très grands volumes de données.

1. Le big data est une innovation qui se trouve à la frontière

entre technologie et management.
 GENERALITES

1. Le terme « NoSQL » a été inventé en

2009 lors d’un événement sur les bases
de données distribuées.
2. Dans cette partie, 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.
 CARACTERISTIQUE DES NoSQL

Simplification en renonçant aux fonctionnalités classiques des

SGBDR.
 Redondance (via réplication)
Pas forcément de schéma normalisé, initialement voire à terme.
 Pas de tables mais des collections.
Rarement du SQL (L4G déclaratif, complet au sens de Turing
depuis SQL-99) mais API simple ou langage spécialisé.
Pas forcément de jointure mais multiplication des requêtes
cache/réplication/données non normalisées, données
imbriquées.
Transactions pas forcément ACID mais plutôt BASE
 Les trois propriétés fondamentales
pour les systèmes distribués :
 cohérence ou Consistance : tous les nœuds du système
voient exactement les mêmes données au même moment
 availability ou Disponibilité : la perte de nœuds n'empêche
pas les survivants de continuer à fonctionner correctement,
les données restent accessibles
 partition tolérance ou Résistance au partitionnement : 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
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
Les trois propriétés fondamentales pour les systèmes distribués :
 MODELES OU TYPES DE BASE DE DONNEE NO SQL
On peut citer cinq représentations de la base de donne

• create (clé,valeur) : crée un couple (clé,valeur)

• read (clé) : lit une valeur à partir de sa clé
• update(clé,valeur) : modifie une valeur à partir de sa
clé
• delete(clé) : supprime un couple à partir de sa clé
- Souvent interface HTTP REST (Representational
State Transfer)disponible depuis nʼimporte quel langage
• La colonne est l’entité
de base représentant un REPRESENTATION DE VENTES EN
champ de donnée, RELATIONNEL
• chaque colonne est
définie par un couple
(clé, valeur) avec une
estampille (pour gérer
les versions et les
conflits)
• Une super-colonne est
une colonne contenant
d’autres colonnes
Une famille de colonnes
regroupe plusieurs
colonnes ou super
colonnes où les colonnes
sont regroupées par
ligne et chaque ligne
est identifiée par un
identifiant unique et par
un nom unique
Représentation de ventes en document avec imbrication redondante
 GRAPHE
Gestion d’un graphe (a priori orienté) c.-à-d. la modélisation, le stockage et la
manipulation de données complexes liées par des relations non-triviales ou variables
Comparaison entre SGBDR et modèles de
SGBD NoSQL
Cas pratique sur le No SQL : Mongo DB

données au format JSON (en fait BSON,

qui est une version binaire de JSON). Le
serveur MongoDB est organisé en
plusieurs databases :
Chaque database contient des
collections.
Chaque collection contient des
documents.
 Chaque document est au format JSON
et contient donc des propriétés.
 Comparaison SQL / MongoDB
SQL MongoDB

base de données et/ou schéma base de données

Table Collection

Enregistrement Document

attribut (atomique) propriété (chaîne, entier, tableau, structure)

En BDR, tous les tuples d’une table Dans une collection MongoDB, les
ont les mêmes champs (mais les documents peuvent ne pas avoir un champ
valeurs peuvent être différentes (les partage (pas de colonnes dans un document
valeurs sont affectées a des colonnes) MongoDB).

Les bases de données relationnelles et les bases de données NoSQL respectent les
orientées objet respectent les principes BASE
principes ACID

concept de transaction Pas de commit et de rollback!

QUELQUES SYNTAXE :MONGODB
find() peut être utilisée pour
récupérer tous les documents
stockés dans une collection
Syntaxe: collectionName.find()
deleteOne({condition}) suppri
me le document unique répondant
aux critères de suppression.
Syntaxe: collectionName.delete
One({DeletionCondition})
Avantages et inconvénients de No SQL
Avantages
 L’évolutivité se fait de manière horizontale (pour
augmenter les performances on ajoute des nouvelles
machines)
 Les données sont distribuées sur plusieurs machines
(sharding) de ce fait on évite les goulets
d’étranglements lors de la récupération des données
(fortes performances de lecture)
 La représentation des données est notable par
l’absence de schéma (schemaless)
 La majorité des solutions est Open Source, néanmoins
il existe des Support Pro pour répondre aux besoins
des entreprises.
Avantages et inconvénient de No SQL
Inconvénients
Il n’existe pas de langage d’interrogation standardisé :
 chaque éditeur a mis en place le sien
 La mise en œuvre d’un environnement fortement
transactionnel (fort besoin d’écriture) où le
séquencement des écrituresest primordial, reste
complexe puisque l’architecture est distribuée
compliquant l’atomicité et la cohérence des
transactions.
 L’écriture de requêtes complexes est difficile à mettre
en œuvre L’offre NoSQL est segmentée en plusieurs
familles où chacune répond à un besoin précis
CONCLUSION

 Pour répondre à la problématique du big

data que sont nées les bases de données
NOSQL, sous l’impulsion de grands acteurs
du web comme Facebook ou Google, qui
les ont développés à l’origine pour leurs
besoins propres.
 C’est dans ce sens qu’on cherche à fournir
la même puissance évolutive que les bases
de données NOSQL, mais en garantissant les
propriétés ACI standards pourra peut-être
réconcilier SQL et NOSQL
Merci pour votre
aimable attention

Thanks You for you kind

attention