Les Bases de Données Nosql: Pr. Soussi Nassima

Les Bases de Données NoSQL
ENSA Khouribga
Pr. SOUSSI Nassima
Les Bases de Données NoSQL et Calcul Distribué [email protected]

Sommaire
I. Introduction au Big Data

(Définition, et Règles du Big Data)
II. Limites des Systèmes de Stockage Classiques
(Fichiers, BDR et les DW classique)
III. Bases de données NoSQL
1. Définition,
2. Théorème CAP,
3. Caractéristiques,
4. Fondements des Systèmes NoSQL
5. Typologie de BD NoSQL
6. Cas d’utilisations
Les Bases de Données NoSQL et Calcul Distribué 2
Introduction au Big Data

Introduction sur le Big Data
Nous parlons en
Brontobytes.

Nom Symbole Valeur (en octet)

Kilo-octet ko 103
Méga-octet Mo 106
Giga-octet Go 109
Téra-octet To 1012
Péta-octet Po 1015
Exa-octet Eo 1018
Zetta-octet Zo 1021
Yotta-octet Yo 1024
Bronto-octet Bo 1027

Big Data : Définition
‒ Le mot Big Data est inventé par les Anglo-Saxon pour désigner
l'explosion du volumes de données.
‒ Représente des collections de données très volumineuses
caractérisées par:
 Une vitesse de croissement exponentielle,
 Une variété si grandes 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.


 Statistiquement parlons:
‒ Si nous prenons toutes les données qui ont été créées dans le
monde jusqu’au 2008, la même quantité de données est
maintenant générée chaque minute.
‒ Plus de 90% des données dans le monde ont été créées au
cours de ces dernières années :
 80% des données est non structurées,
 20% des données qui peuvent être traitées par
des systèmes traditionnels.


Big Data : Caractéristiques (Règles)
Pour caractériser le Big

Data, on parle de la
règle des 3V qui est
devenue par extension,
règle des 4V, puis règle
des 5V.

1. Volume
‒ Fait référence aux énormes quantités de données à traiter qui
ne cesse de s’accroître chaque seconde.
‒ Sur Facebook seulement, nous envoyons 10 millions de
messages par jour, « Likons » 4,5 millions de fois et
téléchargeons 350 millions de nouvelles photos chaque jour.
=> Nous ne parlons plus en Téraoctets mais en Zettabytes
et Brontobytes.
2. Variété
Fait référence à l’hétérogénité de format de données (
Géolocalisation, vidéos, échanges vocaux, posts sur les
réseaux sociaux…)
=> Les technologies du Big Data permettent d’analyser
les données non structurées qui représentent au moins
80 % des informations collectées.

3.Vitesse (Vélocité)
Fait référence à la fréquence du traitement et de génération de
données.
Exemples:
1. les transactions bancaires frauduleuses détectées en quelques
secondes,
2. le temps que prennent les logiciels pour analyser les réseaux
sociaux et capter les comportements qui déclenchent l’achat,
dans des millisecondes !
4. Véracité
‒ Concerne l’authenticité de données (Fiabilité de données).
‒ Avec autant de formes de grosse donnée, la qualité et la
précision sont moins vérifiables (Faux profils sur les réseaux
sociaux, fautes d’orthographe, les abréviations, le langage
familier, …).
=> Il est indispensable de multiplier les précautions et penser
à vérifier systématiquement la validité des données d’entrée
et de traiter notamment le cas d’obsolescence des données.
5. Valeur
‒ Concerne la création de valeur (objectif)
‒ Représente le point le plus important des 5 V. Les
technologies de stockage et d’analyse des Big Data ont de
sens si et seulement si elles apportent de la valeur ajoutée.
=> Exploiter les données, c’est avant tout répondre à des
objectifs commerciaux ou Marketing. La définition des
objectifs orientera l’utilisation des Big Data.

Le Big Data va au-delà des 5Vs qui ont été extensiers en 8Vs,
puis en 10Vs :
Visualisation
Vulnérabilité
5 Vs + Variabilité = 8 Vs + = 10 Vs
Volatilité
Validité

6. Visualisation:
‒ Pour tirer un résultat significatif lors du traitement des
mégadonnées, il faut les visualisés avec des outils appropriés
afin d’aider les data scientists ou les analystes à mieux les
comprendre.
Exemple d’outils de visualisation de Big Data: Tableau,

Google Chart, D3.js (Data Driven Document), …

7. Variabilité:
‒ Elle fait référence au nombre d’incohérences dans les données.
 un scénario courant qui se produit lorsque les données proviennent
de différentes sources.
‒ Même en cas de forte variabilité, les données ne sont pas forcément
invalides ni non-utilisables.
‒ Ces incohérences doivent être détectées par des techniques de détection
d’anomalies pour faciliter la création d’analyse significative.
8. Validité :
‒ La validité a quelques similitudes avec la véracité. Comme le
sens du mot l'indique, la validité des mégadonnées signifie à quel
point les données sont correctes et précises aux fins pour
lesquelles elles sont utilisées.
‒ Il est intéressant de noter qu'une partie considérable des
mégadonnées reste inutile, ce qui est considéré comme des
«données obscures». La partie restante des données non
structurées collectées est d'abord nettoyée pour analyse.
8. Validité : (suite)
60% du temps d’un scientifique est consacré au nettoyage
de ses données avant de pouvoir effectuer une analyse.
=> Avant l’analyse des données massives, il faut passer par le
nettoyage profont des données pour garantir une qualité des
données cohérente avec des définitions communes.

9. Vulnérabilité :
Le Big Data apporte de nouveaux problèmes de sécurité.
10. Volatilité :
‒ La volatilité des mégadonnées fait référence à la durée de
validité des données et à la durée de leur stockage.
 Il faut déterminer à quel moment les données ne sont plus
pertinentes pour l'analyse actuelle.
Volume Visualisation
Variété Variabilité
Les 10 Vs
Vitesse du Vulnérabilité
Big Data
Véracité Validité
Valeur Volatilité
Devant ce contexte d’explosion de données

semi et non structurées les systèmes de
stockage classique présentent plusieurs
limitations …

Les Limites des Systèmes de
Stockage Classique

Les Systèmes de Stockage Classique
‒ Fichiers
‒ Base de Données Relationnelle
‒ Entrepôt de Données Classique

Les Systèmes de Stockage Classique : Fichiers
 Mode d’accès le plus direct

‒ Données accessible depuis n’importe quel outil de
lecture.
 Fichiers organisés en répertoires
‒ Arborescence permettant de structurer les fichiers.
‒ Sur poste de travail ou serveur distant.


‒ Fichiers Plats : Première ligne (en-tête)
Nombre de colonnes identique


‒ Fichiers XML: Très utiliser pour l’échange de données.
Structure arborescence: racine avec enfants.


‒ Fichiers JSON:
 Similaire à XML avec une syntaxe plus légère.
 Plus facile à aborder en programmation.
 Fréquemment utilisé pour les service web et les BD NoSQL.

‒ Fichiers HTML:
 Langage des pages web.
 Interpréter par les navigateurs
 Intégrant des annexes (jpg, css,
js, …)


‒ Fichiers Logs:
Trace enregistrée par un serveur lors d’un événement.
 Démarrage ou erreur sur une application
 Clic sur une page web
 Démarrage d’une session
 …
Pas de format universel mais certains élément sont toujours présent:
 Timestamp (date + heure)
 Identifiant du système ayant produit le log
 Informations pour l’interprétations (adresse page web, …)
‒ Fichiers Brute:
 Suite de caractère peu structuré
 Traitement du langage naturel (NPL) pour avoir des
informations.
‒ Fichiers Binaire:
 Suite d’octets non lisible: Image, video, programme, …
 Prétraitement à faire avant d’exploiter les données.

Limitations des Fichiers:

Compliquer de traiter efficacement des grands volumes de
données via les fichiers de structures hétérogènes.

Les Systèmes de Stockage Classique : BDR
Une base de données relationnelle offrent:

‒ Un système de jointure entre les tables permettant de
construire des requêtes complexes impliquant plusieurs
entités.
‒ Un système d’intégrité référentielle permettant de
s’assurer que les liens entre les entités sont valides.

Limitations:
Le modèle relationnel est moins efficace et peu adapté au stockage
et à l’interrogation des données (semi/non structurées):
‒ Toutes les lignes d’une table ont les mêmes colonnes.
‒ Elle respecte un schéma de base imposé à toute la BD  Mise
à jour du schéma des données est peu performant et couteux en
temps de développement.
‒ Interrogation par jointures  requête complexe, lourdes et
couteuse en temps d’exécution.
Limitations: (suite)
‒ Incapable de stocker et gérer de très grands volumes de
données (de l’ordre du brontobyte) : limité à quelques To,
‒ Elle ne savent pas se distribuer massivement.
‒ Non adaptée pour faire des calculs de statistiques
complexes sur des valeurs ni sur des données volumineuses!

Les Systèmes de Stockage Classique : DW
‒ Le Data warehouse est une base données conçue pour stocker la

data pour des fins décisionnelles  Il s’agit d’une vaste base de
données relationnelle dédié au décisionnel.
‒ Les informations qui y sont stockées offrent une vue d’ensemble
chronologique afin de pouvoir offrir la meilleure capacité d’analyse
possible de la data.
‒ dispose d’un outil intégré nommé ETL pour l’extraction, la
transformation et le chargement de données.
‒ Les données sont orientées « sujet », « thème ».
 Avantages :
Le grand avantage d’un Data warehouse pour une entreprise est
le fait qu’il représente une façon pratique de visualiser les données
passées sans affecter les opérations actuelles.
 Les entreprises exploitent la donnée stockée dans le Data
warehouse dans une optique de Business intelligence.
 Elles peuvent optimiser leurs actions commerciales grâce à
une connaissance plus fine de leur marché, de leurs clients,
concurrents et prospects.
 Limites :
Les entrepôts de données classiques s'appuient sur des bases de
données relationnelles pour stocker des données structurées
relatives à l'historique de l'entreprise dans des tables de fait.
 Il est nécessaire de changer ou adapter l'architecture
existante des DW pour stocker, traiter et faire l’analyser en
temps réel des grandes quantités de données non structurées.

Parmi les travaux de recherches orientés vers l’adaptation des

Data Warehouse au Big Data :
‒ Mallek, H., Ghozzi, F., & Gargouri, F. (2020). Towards Extract-
Transform-Load Operations in a Big Data context. International Journal
of Sociotechnology and Knowledge Development (IJSKD), 12(2), 77-95.
‒ Dehdouh, K., Boussaid, O., & Bentayeb, F. (2020). Big Data
Warehouse: Building Columnar NoSQL OLAP Cubes. International
Journal of Decision Support System Technology (IJDSST), 12(1), 1-24.
‒…

Big Data : Besoins

Les principaux besoins liés à l'émergence du Big Data sont:
‒ Un schéma de données flexible.
‒ La capacité de stockage, traitement et lecture de données
non structurées et semi-structurées.
‒ La performance des requêtes en lecture.
‒ La haute disponibilité des données.
‒ La capacité à gérer une montée en charge horizontale.
‒ La parallélisassions des traitements des requêtes.

Base de Données NoSQL

Bases de données NoSQL
BD NoSQL: Définition
‒ Le terme NoSQL a été créé par Johan Oskarsson en 2009 au
cour d’un meeting à San Fransisco.
‒ Elle s’écarte au paradigme classique des BD relationnelle.
‒ Permet de gérer une grandes
quantité de données avec une
haute scalabilité et flexibilité.

Scalabilité : Définition
Lorsque la charge du serveur augmente, et qu’il est temps de
rajouter des ressources matérielles à votre infrastructure, on parle
de la scalabilité:
 C’est la capacité qu’a l’architecture pour évoluer en cas de
montée en charge si nécessaire.
‒ Scalabilité horizontale : possibilité d’ajouter des serveurs
d’un type donné.
‒ Scalabilité verticale : possibilité d’upgrader un serveur (ajout
de processeurs, RAM, disques…).

Scalabilité : Horizontale vs. Verticale

BD NoSQL: Théorème du CAP
Les bases de données NoSQL

suivent le théorème CAP qui
annonce qu’il est impossible pour un
système distribué de fournir les 3
propriétés suivante à la fois:
‒ Disponibilité
‒ Cohérence
‒ Tolérance au partitionnement


– Cohérence (Consistency) : tous les nœuds (clients) du système voient
exactement les mêmes données au même moment.
– Disponibilité (Availability) : tous les nœuds actifs du système réparti
renvoient une réponse valide à toute demande, sans exception.
– Tolérance au partitionnement (Distribution) : Un partitionnement est
une rupture de communication au sein d'un système réparti, une perte ou
un retard temporaire de connexion entre deux nœuds. La tolérance au
partitionnement signifie que le cluster doit continuer à fonctionner quel
que soit le nombre d'interruptions entre les nœuds du système.

Les bases de données NoSQL sont tenues de respecter

deux principes sur trois. On choisi l’un des trois cas en
fonction des besoins à combler:
‒ Cohérence et Disponibilité (CA)
‒ Disponibilité et la tolérance au partitionnement (AP)
‒ Cohérence et la tolérance au partitionnement (CP)

Les « SGBDR » sont des systèmes:

‒ AC (Cohérent et Disponible)
NoSQL
Les SGBD « NoSQL » sont des systèmes :

‒ AP (Disponible et Distribué)
‒ CP (Cohérent et Distribué)
NoSQL


Le Couple CA (Cohérence et Disponibilité):
‒ Il représente le fait que lors
d'opérations concurrentes sur une même
donnée, les requêtes L1 et L2
retournent la nouvelle version (v2) et
sans délai d'attente.
‒ Cette combinaison n'est possible que
dans le cadre de bases de
données transactionnelles telles que les
SGBDR.

Le Couple CP (Cohérence – Distribution):
‒ Il propose de distribuer les données sur
plusieurs serveurs en garantissant la
tolérance aux pannes (réplication).
‒ En même temps, il est nécessaire de
vérifier la cohérence des données en
garantissant la valeur retournée malgré des
mises à jour concurrentielles.
‒ L1 et L2 attendent la synchronisation
pour voir v2
Le Couple AP (Disponibilité – Distribution):

‒ Il s'intéresse à fournir un temps de
réponse rapide tout en distribuant les
données et les réplicas.
‒ Les mises à jour sont asynchrones sur le
réseau, et la donnée est finalement
cohérente.
‒ L1 voit la version v2, tandis que L2 voit
la version v1.


BD NoSQL: Caractéristiques
Les BD NoSQL :
‒ Adoptent une représentation de données non relationnelle
‒ Ne remplacent pas les BD relationnelles mais c’est 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.

BD NoSQL: Caractéristiques
Les BD NoSQL: (suite)

‒ Utilisent une très forte distribution de ces données et des
traitements associés sur de nombreux serveurs
‒ Pas de schéma pour les données ou schéma dynamique
‒ Données de structures complexes ou imbriquées.
‒ Partitionnement horizontal des données (sharding) sur plusieurs
noeuds (serveurs).
‒ Réplication des données sur plusieurs nœuds.

Fondements des Systèmes
NoSQL

Fondements des Systèmes NoSQL
1. Sharding
2. Map Reduce
3. MVCC

Fondement 1 : Sharding
« Sharding » = Partitionnement des données sur plusieurs
serveurs
‒ Un ensemble de techniques qui permet de répartir les données sur
plusieurs nœuds/serveurs (shards) pour assurer la scalabilité de
l’architecture.
‒ Mécanisme de partitionnement horizontal des données dans lequel
les objets-données sont dispachés uniformément sur des nœuds serveurs
différents en fonction d’une clé de sharding.
‒ La répartition des données est gérée automatiquement par le
système.
Concrètement, il s’agit de créer un cluster appelé sharded cluster
composé de plusieurs machines (appelées shard) sur lesquelles les
données contenues dans notre base vont être réparties selon une clé de
sharding.
An Example of sharding a
single collection to five
sharded servers on an
aphanumeric key field

‒ L’ensemble des serveurs forment un cluster.
‒ Quand les besoins s’augmentent il suffit d’ajouter des serveurs
au cluster.
 On a ainsi un système que l’on peut faire évoluer
facilement selon les besoins (grande scalabilité).
Remarque: La capacité d’extension est théoriquement infinie
car il n’y a à ce jour pas de limites au nombre de machines que
l’on peut ajouter.

Avantages :
‒ Le "Sharded Cluster" est économique : On ne travaille plus avec
une seule machine extrêmement performante, mais avec un cluster
composé de plusieurs machines de milieux de gamme, nettement
moins coûteuses.
‒ les requêtes se feront sur des jeux de données moins
volumineuse et pourront être parallélisées, ce qui permet d’obtenir
des temps de réponse plus rapides.
‒ Ajouter des serveurs supplémentaires sans interruption du
service.
Fondement 2 : MapReduce
‒ Modèle de traitement parallèle (framework de calcul distribué)

pour le traitement d’une grandes masses de données.
‒ Développé par Google pour le traitement de gros volumes de
données en environnement distribué :
 Permet de répartir la charge sur un cluster,
 Gère entièrement, de façon transparente la distribution de
données dans le cluster.
‒ La librairie MapReduce existe dans plusieurs langages
( C++, C#, Java, Python, …)
Dans le modèle de programmation MapReduce, le

développeur implémente deux fonctions principales:
‒ La fonction Map : extraction/calcul d’une

information sur chaque n-uplet,
‒ La fonction Reduce : regroupement de ces
informations.

L’algorithme MapReduce s’exécute en 5 phases :
File Spliting Map Shuffling Reduce

1. L’étape File : lire le fichier document en entrée et initialiser les
différents « Workers MapReduce »
2. L’étape Splitting : distribuer les données à traiter sur les
différents noeuds du cluster de traitement
3. L’étape Map : effectuer le calcul demandé en local sur chaque
nœud du cluster. Cette fonction opère sur la clé du split ainsi
que sa valeur pour retourner à la fin du traitement une liste des
pairs {clé,valeur}.
Map(keyin,valin) = { (key1,value1), …, (keyn,valuen)}
On peut avoir des clés identiques dans cette liste
4. L’étape Shuffling : phase intermédiaire qui permet de
transférer les outputs des mappeurs aux réducteurs après
avoir les trier par clé.
Shuffle((key1,value1), …, (keyn,valuen)) =
{(key1,{value1, …,valuep}), …, (keym,{value1, …,valueb})}
5. L’étape Reduce : calcule une valeur à partir de la liste des

valeurs associées à chaque clé pour les regrouper et retourner
le résultat finale.
Reduce((key1,{value1, …,valuep}) = {(key1,valueout_1)
Exemple d’utilisation :
Soit un fichier document contenant 3 lignes composée
chacune de 3 mots parmi les mots {A, B, C, D}. Il s’agit
de compter tous les mots contenus dans ce fichier.
Le traitement MapReduce effectué pour compter les
mots du document est :


Les étapes réalisées sont :
1. L’étape File : Lire du fichier d’entrée
2. L’étape Splitting : distribuer les données à traiter sur les
différents nœuds du cluster.
3. L’étape Map : on effectue le compte de chacune des lettres
et ceci en local sur chaque nœud du cluster de traitement

Les étapes réalisées sont :
4. L’étape Suffling : on regroupe toutes les lettres ainsi que
leur compte à partir de tous les noeuds de traitement
5. L’étape Reduce: on effectue le cumule de toutes les valeurs
de chaque lettre
6. L’étape Result : on agrège tous les résultats des différentes
étapes Reduce et on retourne le résultat final

Fondement 3 : MVCC
MVCC  Contrôle de Concurrence Multi-Version
‒ Méthode de contrôle de concurrence couramment utilisée par

les SGBD pour gérer des accès simultanés à la base de données
avec mises à jour.
‒ La gestion des mises à jour des données s’effectuent non par
écrasement des anciennes données par les nouvelles mais en
indiquant que les anciennes données sont obsolètes et en ajoutant une
nouvelle version (il existe plusieurs version enregistrées, seule la
plus récente étant correcte)
‒ Nécessite généralement une purge régulière.
Fondement 3 : MVCC
‒ les écritures peuvent être virtuellement isolées des opérations de

lecture qui s'effectuent sur les anciennes versions dans la base et
qui ont été générées par copie et maintenues tant que la transaction
est vivante.
‒ MVCC permet à chaque utilisateur connecté de voir une capture
de la base. Les modifications apportées ne seront pas visibles par
les autres utilisateurs avant que la transaction ne soit validée
(commit).
Fondement 3 : MVCC
‒ En cas de mise à jour concurrente, la transaction qui est la

première à valider les modifications, gagne; avec une annulation
forcée aux autre transaction.
‒ L'avantage du MVCC est que les lectures ne sont jamais
bloquées, et les écritures ne se bloquent pas entre elles.
=> Il y a donc globalement peu de temps d'attente, donc une
meilleure concurrence d'accès à la base.

Fondement 3 : MVCC
Les inconvénients de ce système sont :

‒ L'abandon de certaines transaction, en fin de traitement, si
une opération concurrente, portant sur les mêmes informations,
a validé ses modifications en premier.
‒ Le coût du maintien de multiples versions des objets en base
(surtout dans le cas de bases de données avec de nombreuses
transactions fortement concurrentielles).
‒ La maintenance éventuelle des versions obsolètes à purger.
Typologie des BD NoSQL

Type de BD NoSQL
Les types de base de données NoSQL sont:
 Les bases orientées clé-valeur

 Les bases orientées documents
 Les bases orientées colonnes
 Les bases orientées graphes

Type de BD NoSQL : clé-valeur
‒ Elle se caractérise par un modèle basique et le plus simple des

différents types de BD NoSQL.
‒ Elles fonctionnent comme un grand tableau associatif ou une
énorme table de hachage distribuée sur le réseau. Tout repose sur le
couple Clé/Valeur.
 La clé : identifie la donnée de manière unique et permet de la
gérer.
 La valeur : contient n'importe quel type de données
(numérique simple, chaîne de caractères ou un objet sérialisé).
‒ Chaque objet est identifié par une clé unique qui

représente la seule manière d’interroger les données.
=> On ne peut requêter le système que par la clé, et pas
sur le contenu de la valeur.
‒ Cette absence de structure ou de typage ont un impact

important sur l‘interrogation de données.


Statistiquement, un grand nombre applications demandent à lire
des données à partir de leurs identifiants.
=> engendre le besoin de BD stockant des paires clé‐valeur

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

‒ Create : créer un nouvel objet avec sa clé
=> create(key, value)
‒ Read : lit un objet à partir de sa clé => read(key)
‒ Update : met à jour la valeur d’un objet à partir de sa clé
=> update(key, value)
‒ Delete: supprime un objet à partir de sa clé
=> delete(key)
Forces :
 Interface de requête très simple et souvent accessible
facilement.
 Scalabilité horizontale performante et très facile : lors de
l'ajout d'un nouveau nœud, il suffira de redéfinir les intervalles des
clés dont les serveurs du cluster sont responsables.
 Opérations de lecture et écriture très performantes.
 Répartition des données aisée.
Faiblesses :
‒ Modèle de données TROP simple : pauvre pour les
données complexes
‒ Interrogation de données par clé seulement (médiocre).
‒ On ne peut agir que sur la valeur dans son entier: on ne
peut pas réaliser d'opérations CRUD sur une partie de la
valeur.

‒ Exemple de BD clé-Valeur
 Redis : projet sponsorisé par VMWare
 Voldemort : développé par Linkedln en
interne puis passage en open source.
 Amazon Dynamo : Riak est son
implémentation Open Source.

Type de BD NoSQL : Document
‒ Elles stockent une collection de "documents" identifié par une

clé unique.
‒ 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.
‒ Les documents n'ont pas de schéma, mais une structure
arborescente : ils contiennent une liste de champs.
‒ Un champ a une valeur qui peut être de type simple (entier,
chaine de caractère, date, ...) ou complexe (plusieurs couples
clé/valeur).

 Modèle d’une BD NoSQL avec JSON:


‒ Bien que les documents soient semi-structurés, ces BD sont dites
“schemaless” : il n’est pas nécessaire de définir au préalable les
champs utilisés dans un document.
‒ Les documents peuvent être très hétérogènes au sein de la BD.
‒ Contrairement au modèle clé/valeur, on peut effectuer des requêtes
sur le contenu des documents/objets : pas possible avec les BD
clés/valeurs simples
‒ Elles sont principalement utilisées dans le développement de
CMS (Content Management System).
Forces :
 Modèle de données simple mais puissant
 Mise à jour possible d’un document.
 Forte expressivité de requêtage (requêtes assez complexes sur
des structures imbriquées)
 Permet de structurer la valeur à stocker
 Possibilité d’effectuer des requêtes sur le contenu dudocument.
 Stocker d'importants volumes de données distribuées et
répliquées.
Faiblesses :
‒ Inadaptée pour les données interconnectées
‒ Lenteur éventuelle sur les données complexe.
‒ La forte duplication des données et la difficulté à gérer
la non-cohérence de ces dernières.

‒ Exemples de BD orientée document

 MongoDB
 CouchDB
 DynamoDB

Type de BD NoSQL : Colonne
‒ Traditionnellement, les données sont représentées en

ligne avec un ensemble des attributs.
‒ Le stockage orienté colonne change ce paradigme en se
focalisant sur chaque attribut et en les distribuant.
=> Possibilité de focaliser les requêtes sur une ou
plusieurs colonnes, sans avoir à traiter les informations
inutiles (les autres colonnes)

‒ Les bases orientées colonnes fonctionnent par familles de

colonnes. Elles représentent l'équivalent de sous-tables.
‒ Chaque ligne d'une "table" comporte exactement le
nombre de colonnes qu'elle a besoin pour stocker ses
valeurs.
=> Pas de NULL stockés dans des enregistrements vides
comme c'était le cas dans les SGBDR (à noter qu'un
NULL occupe quand même de l'espace mémoire).
Remarque: On considère que la famille de colonne existe si elle est non vide
Concepts de base:
1. Colonne :
 entité de base représentant un champ de donnée
 chaque colonne est définie par un couple clé/valeur

Concepts de base:
2. Famille de colonnes :
 permettent de regrouper plusieurs colonnes
 les colonnes sont regroupées par ligne
 chaque ligne est identifiée par un identifiant unique
(assimilées aux tables dans le modèle relationnel)

Modèle de base:

Forces:
 Modèle proche du relationnel
 Modèle de données simple mais puissant (expression de
structures imbriquées)
 Très grandes flexibilité
Faiblesses :
 N’est pas adapté aux données interconnectées ou
complexes (de type hiérarchique)

‒ Exemple de BD orientée colonne

 BigTable (Google)
 HBase : Open Source de BigTable de Google
utilisé pour l'indexation des pages web, Google
Earth, Google analytics, ...
 SimpleDB (Amazon)
 Elasticsearch

Type de BD NoSQL : Graphe
Les trois premières familles NoSQL n'adressent pas le problème

de corrélations entre les éléments.
 Les BD orienté graphe offrent une réponse adéquate à
un modèle de données très volumineux et fortement connecté.
 La modélisation d'un problème avec un graphe est très
intuitive et correspond à la réalité métier. Ce type de base est
très flexible car elle n'impose pas de schéma de données figées.


‒ Les données sont représentées sous forme de graphe.
‒ S’appuie sur les notions de nœuds, de relations et de propriétés
qui leur sont rattachées (chaque propriété est représentée par une
paire clé/valeur).
1. Nœuds : représentent les entités
Chaque nœud du graphe se caractérise par :
a. Identifiant,
b. Ensemble de label décrivant sa sémantique,
c. Ensemble de ses propriétés.
2. Relations : (sous forme d’arcs) définissent les relations entre

les nœuds connectés.
Chaque relation du graphe se caractérise par :
a. Identifiant,
b. Label (nom),
c. Identifiant du nœud de départ,
d. Identifiant du nœud cible,
e. Ensemble de ses propriétés.
Exemple:


Forces :
 Modèle de données puissant
 Très efficace pour les données liées
 Exécuter des algorithmes de graphes régulièrement utilisés
dans un modèle de données fortement connecté.
Faiblesses :
 Partitionnement (sharding) compliqué
 Parcours moins efficace si le graphe est très connecté

‒ Exemple de BD orienté graphe

 Neo4j
 OrientDB
 FlockDB
 Infinite Graph

Cas d'utilisations des
SGBD NoSQL

Cas d’utilisation des BD NoSQL
Cas d’utilisations : clé-valeur
Elles sont parfaitement adaptées à:

 Dépôt de données avec besoins de requêtage très simples
‒
 Les profils, préférences d’utilisateur

 Les données de panier d’achat
 Les données de capteur
‒
 Les logs de données

 …
Cas d’utilisations : clé-valeur
‒ Ce type de bases de données est un choix judicieux lorsque

les données sont codées de multiples façons sans schéma
rigoureux.
‒ Elles ne sont pas spécialement adaptées à la gestion des
relations complexes entre différents ensembles de données ni
à l'interrogation au moyen de tout élément autre que la clé
définie.

Cas d’utilisations : Document
‒ Ce type de BD est parfaitement adapté au stockage de

différents types de données pour chaque document, grâce à la
flexibilité qu'il offre en matière de recherches à l'échelle de
toutes les données.
‒ Elles constituent un choix judicieux lorsque le schéma n'est
pas rigide, mais qu'il est tout de même nécessaire d'effectuer
des requêtes en utilisant un élément autre qu'une simple
clé.

La flexibilité de leurs schéma les rend parfaitement adaptées à:

 Gestion de sessions,
 Systèmes de gestion de contenu (bibliothèques
numériques, collections de produits, dépôts de logiciels,
collections multimédia, etc.),
 Gestion des historiques d’utilisateurs sur réseaux
sociaux.
 …
Inconvénients :
‒ Elles ne sont pas spécialement adaptées au traitement de
transactions complexes.
‒ Leurs utilisation n'est pas idéale non plus pour les
applications qui recourent à l'agrégation de données.
 leur schéma flexible signifie que les données ne sont pas
homogènes sur tous les documents et ont, par conséquent,
peu de chances d'être correctement agrégées.

Cas d’utilisations : Colonnes
‒ Elles sont efficaces pour les systèmes :

 Affichant peu d'opérations en écriture,
 Dans lesquels un faible nombre de colonnes présentant
de nombreuses lignes doivent être lues fréquemment et
simultanément.
‒ Ce type de stockage est adapté à la journalisation
d'événements, à la gestion de contenu.

Cas d’utilisations : Graphe
‒ Elles sont adaptées aux éléments de données interconnectés

entre eux avec un nombre indéterminé de relations.
 La mise en œuvre de réseaux sociaux (Ex: LinkedIn ou
Facebook) représente le cas d'utilisation le plus courant des bases
de données orientées graphes.
‒ Les bases de données orientées graphes sont également
pratiques pour la prise en charge de moteurs de
recommandations, comme ceux utilisés par les sites de vente de
détail en ligne.
Cas d’utilisations : Graphe
‒ D'autres applications sont évidemment possibles, comme

l'acheminement et l'expédition des livraisons, les réseaux des
transports publics, les cartes routières, les topologies réseau, …
‒ Elles ne sont pas adaptées aux données qui se changent
fréquemment, ni aux mises à jour en temps réel de grands
volumes de données.
‒ Si vous prévoyez de partitionner la base de données sur un
réseau, ce type de base de données subira probablement une
dégradation de ses performances.

Les Bases de Données Nosql: Pr. Soussi Nassima

Transféré par

Droits d'auteur :

Formats disponibles

Les Bases de Données Nosql: Pr. Soussi Nassima

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Les Bases de Données Nosql: Pr. Soussi Nassima

Transféré par

Droits d'auteur :

Formats disponibles

Les Bases de Données NoSQL

Pr. SOUSSI Nassima

Les Bases de Données NoSQL et Calcul Distribué [email protected]

I. Introduction au Big Data

Les Bases de Données NoSQL et Calcul Distribué 3

Les Bases de Données NoSQL et Calcul Distribué 4

Nom Symbole Valeur (en octet)

Les Bases de Données NoSQL et Calcul Distribué 5

Big Data : Définition

Les Bases de Données NoSQL et Calcul Distribué 6

Big Data : Définition

Les Bases de Données NoSQL et Calcul Distribué 7

Big Data : Définition

Les Bases de Données NoSQL et Calcul Distribué 8

Big Data : Caractéristiques (Règles)

Pour caractériser le Big

Les Bases de Données NoSQL et Calcul Distribué 9

Big Data : Caractéristiques (Règles)

Big Data : Caractéristiques (Règles)

Les Bases de Données NoSQL et Calcul Distribué 11

Big Data : Caractéristiques (Règles)

Big Data : Caractéristiques (Règles)

Big Data : Caractéristiques (Règles)

Les Bases de Données NoSQL et Calcul Distribué 14

Big Data : Caractéristiques (Règles)

Les Bases de Données NoSQL et Calcul Distribué 15

Big Data : Caractéristiques (Règles)

Exemple d’outils de visualisation de Big Data: Tableau,

Les Bases de Données NoSQL et Calcul Distribué 16

Big Data : Caractéristiques (Règles)

Big Data : Caractéristiques (Règles)

Big Data : Caractéristiques (Règles)

Les Bases de Données NoSQL et Calcul Distribué 19

Big Data : Caractéristiques (Règles)

Big Data : Caractéristiques (Règles)

Devant ce contexte d’explosion de données

Les Bases de Données NoSQL et Calcul Distribué 22

Les Bases de Données NoSQL et Calcul Distribué 23

Les Systèmes de Stockage Classique

Les Bases de Données NoSQL et Calcul Distribué 24

Les Systèmes de Stockage Classique : Fichiers

 Mode d’accès le plus direct

Les Bases de Données NoSQL et Calcul Distribué 25

Les Systèmes de Stockage Classique : Fichiers

Les Bases de Données NoSQL et Calcul Distribué 26

Les Systèmes de Stockage Classique : Fichiers

Les Bases de Données NoSQL et Calcul Distribué 27

Les Systèmes de Stockage Classique : Fichiers

Les Bases de Données NoSQL et Calcul Distribué 28

Les Systèmes de Stockage Classique : Fichiers

Les Bases de Données NoSQL et Calcul Distribué 29

Les Systèmes de Stockage Classique : Fichiers

Les Systèmes de Stockage Classique : Fichiers

Les Bases de Données NoSQL et Calcul Distribué 31

Les Systèmes de Stockage Classique : Fichiers

Limitations des Fichiers:

Les Bases de Données NoSQL et Calcul Distribué 32

Les Systèmes de Stockage Classique : BDR

Une base de données relationnelle offrent: