CoursDWH-AIR3-CoursNoSQL - Not Bad

Entrepôts de données
NoSQL
Thierry Hamon
Bureau H202
Institut Galilée - Université Paris 13
&
LIMSI-CNRS
hamon@limsi.fr
https://perso.limsi.fr/hamon/Teaching/P13/DWH-AIR3-2020-2021/
AIR3 – DWH
1/83
Sources des transparents
Bernd Amann, LIP6

Bernard Espinasse, Ecole Polytechnique Universitaire de
Marseille
Olivier Guibert, Université de Bordeaux
Anne-Cécile Caron, Université de Lille
2/83
Introduction
Introduction
Constats :
De plus en plus de données disponibles ou à manipuler
très grandes plateformes
applications Web (Google, Facebook, Twitter, Amazon, ...)
Nécessite de la gestion des données de manière distribuée
Le respect des propriétés ACID (Atomicité, Cohérence,
Isolation et Durabilité) n’est pas possible dans un
environnement distribué
Aussi, manipulation
de données complexes, hétérogènes, non structurées
de très grands volumes de données (Big Data)
3/83
Introduction
Evolutions de la gestion des données

Nouvelles Données :
Web 2.0 : Facebook, Twitter, news, blogs, ...
LOD : graphes, ontologies, ...
Flux : capteurs, GPS, ...
→ Très gros volumes, données pas ou faiblement structurées
Nouveaux Traitements :
Moteurs de recherche
Extraction, analyse, ...
Recommandation, filtrage collaboratif, ...
→ Transformation, agrégation, indexation
Nouvelles Infrastructures :
Clusters, réseaux mobiles, microprocesseurs multi-coeurs, ...
→ Distribution, parallélisation, redondance
4/83
Introduction
Augmentation du volume de données
w3resource.com/mongodb/nosql.php
5/83
Introduction
Caractéristiques du Big Data
Variété : Gestion et Utilisation des différentes types et

structures de données
Vélocité : Analyse de flux de données et de grands volumes de
données persistentes
Volume : Capacité à traiter des Téraoctets (240 ) à des
Zettoctets (270 ) de données
6/83
Introduction
Limites de SGBD relationnels/traditionnels

Faible efficacité lorsque les volumes de données sont importants car
Transaction respectant les propriétés ACID
Requêtes LMJ réalisées séquentiellement et préservant
l’intégrité des données
→ Gestion des transactions complexe ayant un impact sur les
performances
Modèle ER flexible mais peu adapté aux données
non-structurées
→ peu performant et couteux en temps de développement
Matériel et logicieux coûteux et compétences en optimisation
peu répandues
→ Nécessité de distribuer les traitements
7/83
Introduction
NoSQL
Définition de systèmes NoSQL (not only SQL)

Pour répondre à l’augmentation du volume de donnnées à
traiter :
Spécialisation des systèmes
Systèmes sur mesure
Pas d’utilisation de SQL comme langage de requête
Généralement des modèles de données différents :
Document store
Tabular store
Key-value store
Graph store
8/83
Introduction
Systèmes NoSQL
Caractéristiques :
Facilité d’utilisation
Cohérence des données pas forcément assurée
Persistence des données
Fiabilité (pannes) pas forcément assurée
Efficacité
Pas d’Universalité
→ Théorème CAP
9/83
Introduction
Systèmes NoSQL
Composants et fonctionnalités :
Langages spécialisées
Données hétérogènes
Réplication
Parallélisation
Indexation de contenus
10/83
Introduction
Cohérence, Disponibilité, Pannes

Théorème CAP (Brewer, 2000) :
dans un système distribué il est impossible de garantir à
chaque instant T plus que deux parmi les trois propriétés
fondamentales suivantes :
Cohérence (Coherency ) :
tous les noeuds voient la même version
Disponibilité (Availability ) :
chaque requête obtient une réponse
Résistance à une panne partielle (Partition tolerance) :
la perte de messages n’empêche pas le système de continuer à
fonctionner
11/83
Introduction
Théorème CAP
w3resource.com/mongodb/nosql.php
12/83
Introduction
Illustration du théorème CAP
1 Un premier utilisateur modifie une valeur sur l’un des nœuds

du système.
2 Un second utilisateur voulant lire cette valeur sur un autre
nœud doit attendre leur synchronisation pour garantir la
cohérence.
Or
Ce temps d’attente est incompressible
Sur un système très chargé et très vaste, il va
considérablement influencer la disponibilité et la résistance au
morcellement
13/83
SGBD NoSQL
SGBD NoSQL
Définition
SGBD non fondé sur

l’architecture des SGBDR
open source
distribué
horizontally scalable (montée en charge par ajout de serveurs)
14/83
SGBD NoSQL
SGBD NoSQL
Simplification en renonçant aux fonctionnalités classiques des
SGBDR :
Redondance (via réplication)
Pas forcément de schéma normalisé, initialement voire à terme
Pas de tables mais des collections
Rarement du SQL mais API simple ou langage spécialisé
Pas forcément de jointure mais multiplication des requêtes,
cache/réplication/données non normalisées, données imbriquées
Transactions pas forcément ACID mais plutôt BASE
Résistance aux pannes (P) s’impose pour un système distribué :
AP (accepte de recevoir des données éventuellement
incohérentes)
CP (attendre que les données soient cohérentes)
15/83
SGBD NoSQL
SGBD NoSQL
Gestion des mégadonnées (big data) du web, des objets connectés,
etc.
Structure des données hétérogène et évolutive
Données complexes et pas toujours renseignées
Environnement distribué : données répliquées et accédées d’un peu
partout (dans le monde), traitement répartis
Techniques de partionnement des BD : sharding, hachage cohérent
(consistent hashing )
Contrôle de concurrence multi-version (Multi-Version Concurrency
Control MVCC)
Adaptation du protocole Paxos
Performances linéaires avec la montée en charge (les requêtes
obtiennent toujours aussi rapidement une réponse)
16/83
SGBD NoSQL
Propriétés BASE
SGBD issu du cloud computing et des systèmes distribués :
privilégiant la haute disponibilité des données (distribuées), la
rapidité, la simplicité
au détriment de la cohérence, de l’exactitude de la réponse
Propriétés BASE :
Basically Available : le système doit toujours être accessible
(ou indisponible sur de courtes périodes)
Soft state : l’état de la BD n’est pas garanti à un instant
donné (les mises à jour ne sont pas immédiates : cf. cohérence
à terme)
Eventual consistency : la cohérence des données à un instant
donné n’est pas primordiale (mais assurée à terme :
verrouillage optimiste en reportant à plus tard la vérification de
l’intégrité)
17/83
SGBD NoSQL
Protocole Paxos
Paxos :
Famille de protocoles pour résoudre le consensus (processus
permettant de parvenir à une décision sur un résultat) dans un
réseau de nœuds faillibles
Protocole Paxos
Informations gérées :
échanges entre les nœuds
temps entre chaque réponse à un message avant de prendre
une décision
niveau d’activité des participants
nombre de messages envoyés
types de pannes
18/83
SGBD NoSQL
Protocole Paxos
A un instant donné, chaque acteur a au moins un rôle : client,
acceptor, proposer, learner, leader
En fait, plusieurs pour permettre de baisser la latence entre les
messages
Pas d’incohérence possible, et les conditions qui peuvent l’empêcher
de progresser (s’exécuter jusqu’à apporter une réponse valable) sont
rares
Théorème : aucun algorithme de consensus résistant aux pannes ne
permet de garantir de progresser sur un réseau asynchrone
→ intégrité garantie si moins de la moitié des processus en panne
E/S & transaction
Très efficace pour la lecture dans un environnement distribué
Beaucoup moins efficace pour l’écriture/modification
Ne gère pas les transactions ACID
Cas d’utilisation : application devant assurer la durabilité
19/83
SGBD NoSQL
Protocole Paxos : rôles
Client : envoie des requêtes au système distribué et attend une

réponse
Acceptor sont regroupés en quorums et servent de mémoire
résistante au panne
Chaque message envoyé à un acceptor doit l’être au quorum entier
Proposer : pousse la requête du client
il doit convaincre les acceptors de tomber d’accord, et agı̂t comme
coordinateur pour avancer quand un conflit se présente
20/83
SGBD NoSQL
Protocole Paxos : rôles

Learner : servent à la réplication
une fois qu’une requête d’un client a été acceptée par les
acceptors,
le learner peut agir (exécuter une requête et envoyer la
réponse au client)
Pour augmenter la disponibilité, on peut ajouter des learners
Leader : Proposer spécifique pour avancer
Plusieurs processus peuvent croire être le leader
mais le protocole ne garantit l’avancement que si l’un d’eux est
choisi
Remarque : si plusieurs processus croient qu’ils sont leaders
ils peuvent bloquer le protocole en envoyant continuellement
des propositions conflictuelles,
mais l’intégrité des données est cependant toujours préservée
dans ce cas
21/83
SQL vs. NoSQL
SQL vs. NoSQL
Cohérence forte : Cohérence faible :

Logique : Schémas, Pas de schémas, pas de
contraintes contraintes
Physique : Cohérence à terme
Transactions ACID Distribution des
Distribution des données traitements :
Transactions Traitements batch
distribuées MapReduce
Ressources limitées Ressources illimitées
Optimisation de Passage à l’échelle

requêtes horizontal
Langage standard : SQL Langages spécialisés, API
22/83
SQL vs. NoSQL
SQL vs. NoSQL
Traitements centralisés Traitements distribués

Accès distribué Accès local
23/83
SQL vs. NoSQL
SQL vs. NoSQL
Accès à grain fin Accès batch
beaucoup de lectures / peu de lectures / écritures

écritures de petits objets de grands objets
24/83
SQL vs. NoSQL
Vers NoSQL
Étendre / adapter un SGBD traditionnel :

niveaux de concurrence, indexes, stockage
Définir des systèmes spécialisés pour
une infrastructure (distribuée) : cloud, clusters
un type de données : profils, documents XML, RDF, ...
un type de traitements : partage, analyse/agrégation,
visualisation
25/83
Modèles de BD NoSQL
Classification de systèmes
Types de données : tables, clés/valeurs, arbres, graphes,

documents
Paradigme (langages) : MapReduce (PIG, Hive)
API / Protocole : JSON/REST
Persistence : mémoire, disque, cloud...
Gestion de concurrence / cohérence
Réplication, protocoles
Langage d’implémentation, ...
Voir https://db-engines.com/en/ranking
26/83
Systèmes NoSQL
27/83
Modèles NoSQL
Modèles clé-valeur (Key-value store - KVS)

Modèle colonne (Tabular store - TS)
Modèle document (Document store - DS)
Modèle Graphe (Graph store - GS)
Autres types de systèmes noSQL : XML, Triplestore
(RDF), oriénté objet
28/83
Modèle clé-valeur
Définition
BD = 1 tableau associatif unidimensionnel
Chaque objet de la base représenté par un couple (clé,valeur)
est identifié par une clé unique qui est le seul moyen d’accès à
l’objet
Structure de l’objet libre (du ressort du programmeur)
Variante : clés triées en ordre lexicographique
Opérations
Les 4 opérations CRUD :
create(clé,valeur) : crée un couple (clé, valeur)
read(clé) : lit une valeur à partir de sa clé
update(clé,valeur) : modifie une valeur à partir de sa clé
delete(clé) : supprime un couple à partir de sa clé
Souvent interface HTTP REST (Representational State
Transfer ) disponible depuis n’importe quel langage
29/83
Modèle clé-valeur
Utilisation
Dépôt de masses de données avec des besoins de requêtage
simple pour des analyses en temps-réel (sessions web et
fichiers de log, profils utilisateurs, données de capteurs, ...),
gestion de caches
Logiciels Riak (ou Amazon Dynamo), Redis, Voldemort,
Oracle NoSQL Database
Commentaires :
Avantages : simple, très performant, bonne mise à l’échelle,
disponibilité, évolutivité des valeurs
Inconvénients : interrogation seulement sur la clé, complexité
des valeurs à gérer dans les programmes
30/83
Modèle colonne
Définition
Données stockées en colonnes
La colonne est l’entité de base représentant un champ de
donnée
Chaque colonne est définie par un couple (clé,valeur) avec une
estampille (pour gé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 où les colonnes sont regroupées par ligne et chaque
ligne est identifiée par un identifiant unique et par un nom
unique
Opérations
Les requêtes doivent être prédéfinies en fonction de l’organisation en
colonnes (et super-colonnes et familles de colonnes) choisie
31/83
Modèle colonne
Schéma des données (keyspace) d’une application
32/83
Modèle colonne
Utilisation
Analyse de données, OLAP, data mining, entrepôt de données
gestion de données semi-structurées
jeux de données scientifiques, génomique fonctionnelle
journalisation d’événements et de compteurs
analyses de clientèle et recommandation, stockage de listes
(messages, posts, commentaires, ...), traitements massifs
33/83
Modèle colonne
Exemples :
Netflix (logging et analyse de sa clientèle)
eBay Inc. (optimisation de la recherche)
Adobe Systems Incorporated (traitement de données
structurées et d’informatique décisionnelle (Business
Intelligence (BI)))
sociétés de TV (connaissance de leur audience et gestion du
vote des spectateurs)
Logiciels
HBase (ou BigTable), Cassandra, SimpleDB
34/83
Modèle colonne
Avantages :
bonne mise à l’échelle horizontale
efficace avec l’indexation sur les colonnes et pour des requêtes
temps-réel connues à l’avance
capacité de gestion de données tabulaires à schéma variable et de
données semi-structurées
ajout/fusion facile des colonnes
ajout une colonne/super-colonne à n’importe quelle ligne
d’une colonne/super-colonne/super-colonne
nombre de colonnes dynamique (variable d’un enregistrement à un
autre permettant d’éviter les indéterminations)
Inconvénients :
ne supporte pas les données structurées complexes ou
interconnectées
maintenance nécessaire pour la modification de structure en colonne
ajout de ligne couteux
requêtes doivent être pré-écrites
35/83
Modèle document
Définition
BD = collection de documents
Modèle clé-valeur où la valeur est un document (lisible par un
humain) au format semi-structuré hiérarchique (XML, YAML,
JSON ou BSON, etc.)
Document (structure arborescente) = collection de couples
(clé,valeur)
Valeur de type simple ou composée de plusieurs couples
(clé,valeur)
Opérations
Les opérations CRUD du modèle clé-valeur
Souvent interface HTTP REST disponible
Requêtage (API ou langage) possible sur les valeurs des
documents
36/83
Modèle document
Utilisation
Outils de gestion de contenu (Content Management System –
CMS)
catalogues de produits
web analytique
analyse temps-réel
enregistrement d’événements
stockage de profils utilisateurs
systèmes d’exploitation
gestion de données semi-structurées
Logiciels
CouchDB, RavenDB, MongoDB, Terrastore
37/83
Modèle document
Avantages :
performances élevées
bonne mise à l’échelle
modèle simple augmenté de la richesse des documents
semi-structurés
expressivité des requêtes
schéma de BD évolutif
efficace pour les interrogations par clé
Inconvénients :
peut être limité pour les interrogations par le contenu des
documents
limité aux données hiérarchiques
inadapté pour les données interconnectées
baisse des performances pour de grandes requêtes
38/83
Modèle graphe
Gestion d’un graphe (a priori orienté) :
modélisation
stockage
manipulation de données complexes liées par des relations
non-triviales ou variables
Mécanisme
Moteur de stockage pour les objets (qui se présentent sous la
forme d’une base documentaire, chaque entité de cette base
étant un nœud)
Description des arcs (relations entre les objets) disposant de
propriétés (nom, date, ...)
Opérations
SPARQL pour les SGBD NoSQL et les graphes RDF
API et langages spécialisés de programmation et de requêtes
sur les graphes
39/83
Modèle graphe
Utilisation
Moteurs de recommandation, réseaux sociaux
informatique décisionnelle
web sémantique, données liées, données ouvertes (open data)
internet des objets (internet of things (IoT)),
sciences de la vie et calcul scientifique (bioinformatique, ...)
données géospatiales
données hiérarchiques (catalogue des produits, généalogie, ...)
réseaux de transport, services de routage et d’expédition,
services financiers (chaı̂ne de financement, dépendances,
gestion des risques, détection des fraudes, ...)
Logiciels
Neo4J, OrientDB
40/83
Modèle graphe
Avantages :
modèle riche et évolutif bien adapté aux situations où il faut
modéliser beaucoup de relations
nombreux langages et API bien établis et performants
Inconvénients
répartition des données peut être problématique pour de gros
volumes de données
fragmentation (sharding )
41/83
Fondements des systèmes NoSQL
Sharding : partitionnement sur plusieurs serveurs

Consistent hashing : partitionnement des données sur
plusieurs serveurs eux-mêmes partitionnés sur un segment
Map Reduce : modèle de programmation parallèle permettant
de paralléliser tout un ensemble tâches à effectuer sur un
ensemble de données,
MVCC (Contrôle de Concurrence Multi-Version) : mécanisme
permettant d’assurer le contrôle de concurrence
Vector-Clock (horloges vectorielles) : mises à jour
concurrentes en datant les données par des vecteurs d’horloge
42/83
Sharding
Ensemble de techniques qui permet de répartir les données sur
plusieurs machines pour assurer la scalabilité de l’architecture
Partitionnement horizontal d’une BD (collection) :

Stockage des données sur des nœuds serveurs différents en fonction
d’une clé (fonction de hachage)
Accès ou mise à jour des objets-données en même temps s’ils
résident sur le même nœud
Equilibrage de charge automatique : réplication uniforme de la
charge entre les nœuds
Réplication des objet-données
Plusieurs milliers de nœuds
Ajout / suppression (dynamique) de nœuds
Certains systèmes utilisent aussi un partitionnement vertical (par
colonnes) dans lequel des parties d’un enregistrement sont stockées sur
différents serveurs
43/83
Consistent hashing
Mécanisme de partitionnement (horizontal) dans lequel les objet-données
sont stockés sur des nœuds-serveurs différents en utilisant la même
fonction de hachage à la fois pour le hachage des objets et le hachage
des nœuds :
les nœuds et objets sont associés par une même fonction de hachage, et
imaginés être placés sur un anneau (rack/cluster de serveurs)
A, B, C sont des nœuds (serveurs) et 1, 2, 3, 4 sont des objets.
un objet est associé au premier nœud serveur dans le sens horaire :
les objets 4 et 1 sont associés au nœud A ; 2 à B ; 3 à C
quand un nœud quitte l’anneau, les objets qui lui sont liés sont alors
associés à leur nœud adjacent dans le sens
le nœud C quitte l’anneau, 3 est alors associé avec 4 et 1 au nœud A
quand un nœud entre dans l’anneau, il est placé (haché) sur l’anneau et
des objets lui seront associés selon sa place dans l’anneau :
le nœud D entre dans l’anneau, les objets 3 et 4 lui sont associés
44/83
Parallélisation : MapReduce
MapReduce : distribution des données sur de nombreux serveurs

vers lesquels on pousse les programmes (car plus efficace de
transférer un petit programme sur le réseau plutôt qu’un grand
volume de données)
Entrée :
une (grande) collection d’objets (documents, données)
un traitement / calcul ensembliste : compter, agréger, filtrer,
indexer, jointure
un grand nombre de machines connectées
Problème :
paralléliser le traitement en utilisant efficacement les machines
disponibles
45/83
Approche MapReduce
Programme :
Séquence de deux appels de fonctions :
map1 → reduce1 → map2 → reduce2 → ...
Coordinateur
Déploiement des données et des traitements dans le cluster
Coordination de l’exécution
Avantage :
Parallélisation automatique de l’évaluation
Virtualisation de l’infrastructure
46/83
2 fonctions :
1 Map : transforme l’entrée en couples (clé,valeur)
2 Reduce : calcule une valeur à partir de la liste des valeurs
associées à chaque clé
L’environnement d’exécution de l’algorithme MapReduce
s’occupe de l’aspect distribution :
le programme est distribué sur les différents noeuds, on a donc
une exécution en parallèle.
47/83
Parallélisation : MapReduce
Collection d’objets = collection de couples (Clés, Valeurs)

Deux fonctions utilisateur f et g :
map(f , [(A, V )]) → (B, V 0 )∗ :
map(countWords, (url, doc)) → (mot, int)∗
shuffle(B, V 0 )∗ → (B, V 0∗ )∗ :
shuffle(mot, int)∗ → (mot, int ∗ )∗
(group by mot)
reduce(g , (C 0 , V 0 ∗)∗) → (C , V 00 )∗ :
reduce(sum, (mot, int ∗ )∗ ) → (mot, int)∗
(agrégation)
48/83
MapReduce (exemple)
49/83
MVCC
Multi-Version Concurrency Control
Contrôle de concurrence multi-version

Modification d’une donnée
non pas par écrasement des anciennes données par les nouvelles
mais en indiquant que les anciennes données sont obsolètes
et en ajoutant une nouvelle version
seule la plus récente étant correcte
→ nécessité d’une purge régulière des données obsolètes
50/83
Horloges vectorielles - Vector-Clock

Les ensembles de données répartis sur nœuds peuvent être lus et modifiés
sur chaque nœud et aucune cohérence stricte n’est assurée par des
protocoles de transactions distribuées
Problème : comment faire des modifications concurrentes
Une solution : les horloges vectorielles :
un vecteur d’horloge est défini comme un n-uplet V [0], V [1], ...,
V[n] des valeurs d’horloge à partir de chaque noeud.
à tout instant le noeud i maintient un vecteur d’horloge
représentant son état et celui des autres nœuds répliques :
(Vi [0] = valeur de l’horloge du premier noeud, Vi [1] = valeur de
l’horloge du deuxième noeud, ... Vi [i] = sa propre valeur d’horloge,
... Vi [n] = valeur de l’horloge du dernier nœud)
les valeurs d’horloge peuvent être de réelles timestamps dérivées
d’une horloge locale de nœud, du numéro de version/révision ...
51/83
Hadoop
Hadhoop pour High-Availability Distributed Object-Oriented

Platform : framework de référence, libre et open source
Système distribué qui permet d’analyser, stocker et manipuler de
très grandes quantités de données (Big Data)
Création par Doug Cutting en 2002 pour les besoins du projet
Apache Nutch
intégration MapReduce suite à la sortie de l’article de Google en

2004
Yahoo! : contributeur majeur au projet Hahoops
Depuis 2008 : projet indépendant de la fondation Apache
Utilisation par les géants du web comme Yahoo!, Twitter, LinkedIn,
eBay, Amazon, ...
52/83
Hadoop
Hadoop n’a d’intérêt que pour gérer des données de très

grande taille dans un environnement composé de très
nombreuses machines (data centers)
Hadoop fractionne les fichiers en gros blocs :
il distribue ces blocs à travers les nœuds du cluster
Il comprend plusieurs composants, notamment :
les nœuds maı̂tres (Master nodes),
les nœuds travailleurs (Worker nodes – ou Slave nodes).
53/83
Hadoop
https://blog.octo.com/hadoop-une-plateforme-de-reference-pour-faire-du-big-data/
54/83
Composition du framework Hadoop

Hadoop Distributed File System (HDFS)
Système de gestion de fichiers distribués permettant de stocker les
données sur les machines du cluster
Hadoop Common
Bibliothèques et utilitaires nécessaires aux autres modules Hadoop
Hadoop YARN (Yet Another Resource Negotiator )
Plate-forme chargée de la gestion des ressources informatiques du
clusters et de les utiliser pour la planification des applications des
utilisateurs
Hadoop MapReduce
Implémentation du modèle de programmation MapReduce pour le
traitement des données à grande échelle
Ecosystème et ensemble des logiciels : Apache Pig, Apache Hive,
Apache HBase, Apache Phoenix, Apache Spark, Apache ZooKeeper,
Cloudera Impala, Apache Flume, Apache Sqoop, Apache oozie et
Apache Storm
55/83
Exemples de systèmes NoSQL
Exemple : Riak
Stockage (clé,valeur) distribué : hachage distribué
Accès via une API Restful (put, get, post, delete)
Pas de schéma, les données stockées sont quelconques : images,
texte (libre, ou semi-structuré comme XML et JSON), vidéos, ...
Pas de langage de requête, pas d’opération un peu complexe que
l’on pourrait envoyer via une URL
Gestion de la réplication : un cluster primaire qui contrôle la
réplication sur un ou plusieurs clusters secondaires
Théorème CAP : privilégie A+P
Programmation MapReduce essentiellement en Erlang (aussi en
d’autres langages comme javascript mais moins performant).
Couplage possible avec Redis pour la gestion du Cache
Si on intègre le moteur de recherche full-text SolR, Riak devient
(presque) une base de documents.
56/83
Exemple : CouchBase
Modèle semi-structuré, basé sur JSON (Javascript object
notation)
{
” t i t l e ” : ”The S o c i a l n e t w o r k ” ,
” y e a r ” : ” 2010 ” ,
” d i r e c t o r ” : {” l a s t n a m e ” : ” F i n c h e r ” ,
” f i r s t n a m e ” : ” David ” } ,
” actors ” : [
{” f i r s t n a m e ” : ” J e s s e ” , ” l a s t n a m e ” : ” E i s e n b e r g ” } ,
{” f i r s t n a m e ” : ” Rooney ” , ” l a s t n a m e ” : ” Mara ”}
]
}
Les documents ont un document ID et sont distribués sur un

cluster. Une fonction de hashage permet d’associer 1 partition
(donc un serveur) à 1 document.
les documents sont répliqués (maximum 3 fois)
Méthodes set/get pour qu’une application récupère/fournisse
un document (pas une partie d’un document)
57/83
Exemple : CouchBase
Vues en CouchBase
CouchBase propose des vues structurées définies grâce au
paradigme MapReduce : une vue est donc une liste de couples
(clé,valeur)
Les vues permettent de définir des indexes secondaires sur les
documents (l’index primaire est selon le document id)
A la création d’une vue, on applique les fonctions map-reduce
sur l’ensemble des documents, et le résultat est matérialisé
sous la forme d’un index B-arbre
58/83
Exemple : HBase
Modèle de données
Table : les données sont organisées en Tables
Ligne : Dans une table, on stocke des lignes, identifiées par leur Rowkey.
Famille de colonnes : A l’intérieur d’une ligne, les données sont groupées
par familles de colonnes. Ces familles ont un impact sur le stockage
physique, et doivent être connues à l’avance. Toutes les lignes d’une table
ont les mêmes familles de colonne (donc ces familles constituent le
schéma de la table).
Colonne : Les données d’une famille de colonnes sont découpées en
colonnes. Ces colonnes ne sont pas connues à l’avance, et on n’a pas
toujours les mêmes colonnes d’une ligne à l’autre.
Cellule : pour 1 ligne, 1 famille et 1 colonne, on a 1 seule cellule.
Version : Les valeurs d’une cellule sont versionnées.
Il n’y a pas vraiment de type de données : tout est traité comme byte.
HBase peut être vue comme une sorted map of maps
59/83
Exemple : HBase
60/83
Neo4j
Très efficace pour traverser un graphe (pas de jointure)

Algorithmes classiques sur les graphes, que l’on peut appeler
avec l’interface REST
Par défaut, Neo4j gère des transactions avec les propriétés
ACID.
Pour le passage à l’échelle en mode distribué, utiliser Neo4j
HA (pour High Availability) : available et partition tolerant
(A+P du théorème CAP)
Peut gérer plus de 30 milliards de sommets, et plus de 30
milliards de relations (arcs).
Pas de support pour de la programmation MapReduce
61/83
Exemple : Apache TinkerPop
https://github.com/tinkerpop/gremlin/wiki/Basic-Graph-Traversals
http://tinkerpop.apache.org/
62/83
Performances
Performances
MySQL vs. Cassandra

> 50 Go de données
MySQL Cassandra
Ecriture 300ms 0.12ms
Lecture 350ms 15ms
https://www.slideshare.net/Eweaver/cassandra-presentation-at-nosql
Limites de Cassandra :
Une ligne doit tenir sur un seul noeud (sur le disque)
Maximum de colonnes pour une ligne: 2 milliards
63/83
MongoDB
MongoDB (DS)
JSON document store

Protocole : BSON (binary JSON)
MapReduce, langage orienté-objet (JSON)
Écrit en C++
64/83
MongoDB
MongoDB
SGBD
orienté documents
libre
scalable : réplication, auto-sharding
flexible : pas de schéma de données, full-text index
écrit en C++.
Il fait partie de la mouvance NoSQL et vise a fournir des
fonctionnalités avancées. Utilisée par Foursquare, bit.ly,
Doodle, Disqus
65/83
MongoDB
Mongo DB
Modèle logique
BD = ensemble de collections
Collection = ensemble de documents
Taille variable
Taille fixe (capped) : LRU
Document = objet BSON
Modèle physique
Index : attributs, geo-spatial
MapReduce
Sharding (partitionnement horizontal)
66/83
MongoDB
Langage MongoDB
LMD
LMJ :
db.collection.insert()
db.collection.update()
db.collection.save()
db.collection.findAndModify()
db.collection.remove()
LID :
db.collection.find()
db.collection.findOne()
67/83
MongoDB
Insert
db . c o l l e c t i o n . i n s e r t (<doc> [ , <doc> ] ∗ )
c o l l e c t i o n = db . c o n t a c t i n f o
doc = { ”nom” : ” t o t o ” ,
” info” : {
” t w i t t e r ” : ” @toto5646 ” ,
” e m a i l ” : ” toto@upmc . f r ” } ,
” amis ” : 87687 ,
” p h o t o ” : BinData ( . . . )
” d a t e l o g i n ” : new Date ( ) }
db . c o n t a c t i n f o . i n s e r t ( doc )
68/83
MongoDB
Update
db.collection.update(query, update, <upsert>, <multi>)

query : requête
update : modifications
upsert (booléen) :
false (défaut) : update
true : update or insert if not exists
multi (booléen) :
false (défaut) : maj de la 1ere occurrence trouvée
true : maj toutes les occurrence
69/83
MongoDB
Update
db . p r o d u c t s . upd ate ( { i t e m :
” book ” , q t y : { $ g t : 5 } } , { $ s e t :
{ x : 6 } , $ i n c : { y : 5} } )
” book ” , q t y : { $ g t : 5 } } , { x : 6 ,
y : 15 } )
” book ” , q t y : { $ g t : 5 } } , { $ s e t :
{ x : 6 , y : 15 } } , { m u l t i : t r u e } )
” book ” , q t y : { $ g t : 5 } } , { $ s e t :
{ x : 6 , y : 15 } } , f a l s e , t r u e )
” magazine ” , qty : { $gt : 5 } } ,
{ $ s e t : { x : 2 5 , y : 50 } } ,
{ upsert : true } )
70/83
MongoDB
Requêtes
db.collection.find( <query>, <projection> )

db.collection.findOne( <query>, <projection> )
db .i n v e n t o r y . f i n d ( {} )
db .c o n t a c t i n f o . f i n d O n e ( { ”nom” : ” t o t o ” } ) ;
db .c o n t a c t i n f o . findOne ({ ” c o n t a c t . t w i t t e r ” : ” @toto5646 ” } ) ;
db .c o n t a c t i n f o . f i n d ({ ” d a t e l o g i n ” : {
” $ g t ” : ISODate ( ”2015−09−17T23 : 2 5 : 5 6 . 3 1 4 Z” ) ,
” $ l t ” : ISODate ( ”2014−09−17” ) } } ) . s o r t ( { nom :
1}). l i m i t ( 1 0 ) . skip (100)
71/83
MongoDB
Requêtes
db . e m p l o y e e . i n s e r t (
{
”name” : ” John Smith ” ,
” address ” : {
” s t r e e t ” : ” L i l y Road ” ,
” number ” : 3 2 ,
” c i t y ” : ” Owatonna ” ,
” z i p ” : 55060
},
” hobbies ” : [ ” yodeling ” , ” ice skating ” ]
})
db . e m p l o y e e . FindOne (
{”name” : ” John Smith ” })
db . e m p l o y e e . f i n d (
{” a d d r e s s . c i t y ” : ” Owatonna ” } ,
{”name” : 1})
{” a d d r e s s . c i t y ” : ” Owatonna ” } ,
{”name” : 1})
{” h o b b i e s ” : {” $ne ” : ” y o d e l i n g ” }})
72/83
MongoDB en Java
MongoDB en Java
Authentification (optionnel) :
b o o l e a n a u t h = db . a u t h e n t i c a t e ( myUserName , myPassword ) ;
Liste des collections :

Set <S t r i n g > c o l l s = db . G e t C o l l e c t i o n N a m e s ( ) ;
for ( String s : colls ) {
System . o u t . p r i n t l n ( s ) ;
}
Accès à une collection :

D B C o l l e c t i o n c o l l = db . g e t C o l l e c t i o n ( ” t e s t C o l l e c t i o n ” )
73/83
MongoDB en Java
MongoDB en Java
import com . mongodb . Mongo ;

import com . mongodb . DB ;
import com . mongodb . D B C o l l e c t i o n ;
import com . mongodb . B a s i c D B O b j e c t ;
import com . mongodb . DBObject ;
import com . mongodb . DBCursor ;
Mongo m = new Mongo ( ) ;

// o r
Mongo m = new Mongo ( ” l o c a l h o s t ” ) ;
// o r
Mongo m = new Mongo ( ” l o c a l h o s t ” , 27017 ) ;
DB db = m. getDB ( ”mydb” ) ;
74/83
MongoDB en Java
MongoDB en Java
Insertion d’un objet (document) :

B a s i c D B O b j e c t doc = new B a s i c D B O b j e c t ( ) ;
doc . p u t ( ”name” , ”MongoDB” ) ;

doc . p u t ( ” t y p e ” , ” d a t a b a s e ” ) ;
doc . p u t ( ” c o u n t ” , 1 ) ;
B a s i c D B O b j e c t i n f o = new B a s i c D B O b j e c t ( ) ;
i n f o . put ( ”x” , 2 0 3 ) ;
i n f o . put ( ”y” , 1 0 2 ) ;
doc . p u t ( ” i n f o ” , i n f o );
c o l l . i n s e r t ( doc ) ;
75/83
MongoDB en Java
MongoDB en Java
Requêtes :
// g e t f i r s t document
DBObject doc = c o l l e c t i o n . f i n d O n e ( ) ;
System . o u t . p r i n t l n ( d b O b j e c t ) ;
DBCursor c u r s o r = c o l l e c t i o n . f i n d ( ) ;
w h i l e ( c u r s o r . hasNext ( ) ) {
System . o u t . p r i n t l n ( c u r s o r . n e x t ( ) ) ;
}
B a s i c D B O b j e c t q u e r y = new B a s i c D B O b j e c t ( ) ;
q u e r y . p u t ( ” number ” , 5 ) ;
DBCursor c u r s o r = c o l l e c t i o n . f i n d ( q u e r y ) ;
}
76/83
MongoDB en Java
MongoDB en Java
Requêtes :
L i s t <I n t e g e r > l i s t = new A r r a y L i s t <I n t e g e r > ( ) ;
l i s t . add ( 9 ) ;
l i s t . add ( 1 0 ) ;
q u e r y . p u t ( ” number ” , new B a s i c D B O b j e c t ( ” $ i n ” , l i s t ));
}
77/83
MongoDB en Java
MongoDB en Java
Requêtes :
q u e r y . p u t ( ” number ” ,
new B a s i c D B O b j e c t ( ” $ g t ” , 5 ) . append ( ” $ l t ” , 8 ) ) ;
}
Création d’un index :

// c r e a t e i n d e x on ” i ” , a s c e n d i n g
c o l l . c r e a t e I n d e x ( new B a s i c D B O b j e c t ( ” i ” , 1 ) ) ;
78/83
MongoDB en Java
MongoDB : MapReduce
db . runCommand (
{ mapreduce : <c o l l e c t i o n >,
map : <m a p f u n c t i o n >,
r e d u c e : <r e d u c e f u n c t i o n >
[ , q u e r y : <q u e r y f i l t e r o b j e c t >]
[ , s o r t : <s o r t s t h e i n p u t o b j e c t s u s i n g t h i s key . U s e f u l f o r o p t i m i z a t i o n ,
l i k e s o r t i n g by t h e e m i t key f o r f e w e r r e d u c e s >]
[ , l i m i t : <number o f o b j e c t s t o r e t u r n from c o l l e c t i o n >]
[ , o u t : <s e e o u t p u t o p t i o n s below >]
[ , keeptemp : <t r u e | f a l s e >]
[ , f i n a l i z e : <f i n a l i z e f u n c t i o n >]
[ , s c o p e : <o b j e c t where f i e l d s go i n t o j a v a s c r i p t g l o b a l s c o p e >]
[ , jsMode : t r u e ]
[ , verbose : true ]
}
);
79/83
MongoDB en Java
MapReduce : exemple
Collection de commentaires :
{ username : ” j o n e s ” , l i k e s : 20 ,
t e x t : ”J ’ aime c e t t e p h o t o ! ” }
Fonction Reduce :
f u n c t i o n ( key , v a l u e s ) {
v a r r e s u l t = {count : 0 , l i k e s : 0};
values . forEach ( function ( value ) {
r e s u l t . c o u n t += v a l u e . c o u n t ;
r e s u l t . l i k e s += v a l u e . l i k e s ;
});
return result ;
Fonction Map :
function () {
e m i t ( t h i s . username ,
{count : 1 , l i k e s : t h i s . l i k e s } ) ; }
}
MapReduce incrémental
Map/shuffle : [(C , V )] → [(C 0 , [V 0 ])]
Reduce : [(C 0 , [V 0 ])] → [(C 0 , V 0 )]
80/83
MongoDB en Java
MonoDB : Sharding
Notions :
shard : traitement de requêtes (query, maj) sur un fragment
de collection (identifié par shardkey)
mongos : routage de requêtes
config server : surveillance des shards (métadonnées)
81/83
MongoDB en Java
Conclusion
On a besoin de SQL et de NoSQL

NoSQL = not only SQL
Principe CAP
Importance de noSQL
Analyse de données
Passage à l’échelle
Parallélisation / partionnement verticale
82/83
MongoDB en Java
Conclusion
Les SGBDR en font trop, alors que les produits NoSQL
font exactement ce dont vous avez besoin (Travis, 2009)
Gestion des BD géantes des sites web de très grande audience

Exemple des SGBD d’annuaires : grande majorité des accès aux BD
consistent en lectures sans modification (ainsi, seule la persistance
doit être vérifiée)
Consensus actuel :
Les SGBD NoSQL ne replacent pas les SGBDR mais les complètent
en palliant leurs faiblesses
A venir :
UnQL (Unstructured Query Language)
2011 : début d’une spécification d’un langage de manipulation
standardisé (pour formaliser le requêtage des collections des BD
NoSQL)
83/83

CoursDWH-AIR3-CoursNoSQL - Not Bad

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

CoursDWH-AIR3-CoursNoSQL - Not Bad

Transféré par

Droits d'auteur :

Formats disponibles

Entrepôts de données

Bernd Amann, LIP6

Evolutions de la gestion des données

Augmentation du volume de données

Caractéristiques du Big Data

Variété : Gestion et Utilisation des différentes types et

Limites de SGBD relationnels/traditionnels

Définition de systèmes  NoSQL  (not only SQL)

Cohérence, Disponibilité, Pannes

Illustration du théorème CAP

1 Un premier utilisateur modifie une valeur sur l’un des nœuds

SGBD non fondé sur

Protocole Paxos : rôles

Client : envoie des requêtes au système distribué et attend une

Protocole Paxos : rôles

SQL vs. NoSQL

Cohérence forte : Cohérence faible :

Optimisation de Passage à l’échelle

SQL vs. NoSQL

Traitements centralisés Traitements distribués

SQL vs. NoSQL

Accès à grain fin Accès  batch 

beaucoup de lectures / peu de lectures / écritures

Étendre / adapter un SGBD traditionnel :

Types de données : tables, clés/valeurs, arbres, graphes,

Modèles clé-valeur (Key-value store - KVS)

Fondements des systèmes NoSQL

Sharding : partitionnement sur plusieurs serveurs

Partitionnement horizontal d’une BD (collection) :

MapReduce : distribution des données sur de nombreux serveurs

Collection d’objets = collection de couples (Clés, Valeurs)

Contrôle de concurrence multi-version

Horloges vectorielles - Vector-Clock

Hadhoop pour High-Availability Distributed Object-Oriented

intégration MapReduce suite à la sortie de l’article de Google en

Hadoop n’a d’intérêt que pour gérer des données de très

Composition du framework Hadoop

Les documents ont un document ID et sont distribués sur un

Très efficace pour traverser un graphe (pas de jointure)

Exemple : Apache TinkerPop

MySQL vs. Cassandra

JSON document store

db.collection.update(query, update, <upsert>, <multi>)

db.collection.find( <query>, <projection> )

Liste des collections :

Accès à une collection :

import com . mongodb . Mongo ;

Mongo m = new Mongo ( ) ;

Insertion d’un objet (document) :

doc . p u t ( ”name” , ”MongoDB” ) ;

Création d’un index :

On a besoin de SQL et de NoSQL

Gestion des BD géantes des sites web de très grande audience

Vous aimerez peut-être aussi

Définition de systèmes NoSQL (not only SQL)

Accès à grain fin Accès batch