NoSQLPar4 PDF

NoSQL pour le BigData NoSQL pour le BigData
Introduction
1 / 29 2 / 29
Introduction
I NoSQL : ”Not Only SQL”, ce n’est pas du relationnel, et le contexte
d’utilisation n’est donc pas celui des SGBDR.
NoSQL pour le BigData I Origine : recherche d’information sur le web, moteurs type Google,
Yahoo, données des réseaux sociaux, ...
I Besoin de stockage d’énormes masses de données. Twitter par
Anne-Cécile Caron exemple reçoit plusieurs Tera-octets de données par jour.
I Système distribué
Master MIAGE - SGBD
I table d’associations - Map - de couples (clef,valeur)
1er trimestre 2017-2018 I Di↵érentes approches, rangées dans la famille ”NoSQL”.

Introduction Introduction
3 / 29 4 / 29
Bibliographie Introduction
Le cours d’aujourd’hui utilise Pourquoi ces technologies sont passées des acteurs du web au ”grand
I le livre de Serge Abiteboul et al, public” ?
Web Data Management I Big Data =) Volume, Variété, Vélocité
http://webdam.inria.fr/Jorge/ I Exploitation de données externes ajoutées aux données internes,
I le livre blanc de Smile sur NoSQL : quelles soient structurées (relationnelles, multidimensionnelles) ou
http://www.smile.fr/Livres-blancs/Culture-du-web/NoSQL non (e.g. documentaires)
I le livre de Eric Redmond et Jim R. Wilson, I Quelques exemples de Big Data :
Seven Databases in Seven Weeks I Service marketing : informatique décisionnelle ”classique” (données
I le livre de Nick Dimiduk et Amandeep Khurana, structurées), couplée avec l’exploitation de mails (données internes
HBase in Action non structurés), et des réseaux sociaux (données externes non
structurées).
I Recherche Scientifique : capteurs qui ramènent énormément de
données numériques (accélérateur de particules, télescope, ...) ou
nécessité de partager des données très volumineuses (génomique, ...)
I NoSQL n’est qu’une partie de cette vaste problématique du Big
Data.
Contexte Contexte
Recherche sur le web Recherche sur le web
5 / 29 6 / 29
Un cas d’utilisation : Recherche sur le Web Inverted File

I collecter les documents publiés sur le web = ”web crawling”. I comme le glossaire d’un livre
+ détecter des changements sur un document déjà parcouru. I à 1 mot clef on associe une collection de documents qui contiennent
I traiter ces documents pour extraire l’information qu’ils contiennent : ce mot
mots significatifs
I construire un index permettant de retrouver les documents les plus
pertinents pour 1 mot clef ou un ensemble de mots clefs
= ”inverted files”

Contexte Contexte
Recherche sur le web Système distribué
7 / 29 8 / 29
Inverted File - structure Système distribué

I Système distribué = système logiciel qui permet de coordonner
plusieurs ordinateurs. Généralement, cette coordination se fait par
envoi de messages via un réseau auquel sont reliés ces ordinateurs.
I Pourquoi ? parce qu’on manipule un très grand volume de données.
Sans distribution, on n’a pas d’application ”scalable”.
I On peut imaginer 2 scenarii de traitement des données :
1. On dispose d’un grand ensemble de données, et on doit leur
appliquer des traitements disponibles sur des sites distincts. Il faut
donc envoyer les données aux endroits appropriés, et enchaı̂ner les
exécutions distantes. C’est un scénario de type Workflow, que l’on
peut implémenter avec des web services. ) Traitements distribués.
I on connaı̂t le nombre de documents ni associés à un terme ti . 2. Les données sont distribuées sur un certain nombre de serveurs, et on
”pousse” les programmes vers ces serveurs. Il est en e↵et plus
I on donne un poids wk à chaque document dk associé au terme ti . Le efficace de transférer un petit programme sur le réseau plutôt qu’un
poids traduit la pertinence du document pour ce terme. grand volume de données. ) Données distribuées. On verra
aujourd’hui l’algorithme MapReduce qui utilise cette approche.
Contexte Contexte
Système distribué Système distribué
9 / 29 10 / 29
Exemple : Data Centers de Google Schéma : LAN/data center

I Utilise des LANs (Local Area Networks). On distingue 3 niveaux de
communication :
1. Les serveurs sont regroupés en ”racks”. Liaison réseau rapide,
environ 1Go/sec.
2. Un data center consiste en un grand nombre de racks, interconnectés
par des routeurs (switches). Liaison à 100 Mo/sec.
3. Entre di↵érents data centers, il y a aussi une possibilité de
communication mais par liaison assez lente (internet - 2-3 Mo/sec)
I Les serveurs communiquent par envoi de messages, Ils ne partagent
pas de disque ni de ressource de traitement.
= architecture ”shared nothing”.
I Début 2010 : 1 data center Google contient entre 100 et 200 racks,
chacun contenant 40 serveurs. Environ 5000 serveurs par data-center
pour un total de 1 millions de serveurs (estimation d’après la
consommation électrique).

Contexte Contexte
Système distribué Système distribué
11 / 29 12 / 29
Le théorème CAP
Aucun système distribué ne peut fournir les 3 propriétés suivantes :
1. Consistency (cohérence) : tous les noeuds voient exactement les
mêmes données en même temps
2. Availability (disponibilité) : garantie que toutes les requêtes
reçoivent une réponse, car l’échec d’un noeud n’empêche pas les
survivants de continuer à fonctionner
3. Partition tolérance (résistance au partitionnement) : Le système
continue à fonctionner malgré la perte d’un message du à une pendant l’envoi du message M, d 0 6= d
panne. Autrement dit, en cas de morcellement du réseau, chaque I en général, la résistance au partitionnement n’est pas discutable dans un
sous-réseau doit pouvoir fonctionner de façon autonome. système distribué : on doit choisir en A+P ou C+P
I Un SGBD relationnel classique va privilégier C+P, avec un système
transactionnel distribué et la vérification des propriétés ACID. C’est au
détriment des performances !
I En NoSQL, on choisit plutôt A+P.
Bases NoSQL Bases NoSQL
MapReduce
13 / 29 14 / 29
Bases NoSQL Algorithme MapReduce

Dans un contexte distribué, avec un très grand volume de données, sont I Le programmeur définit 2 fonctions :
apparues plusieurs solutions englobées sous le terme de ”NoSQL”. 1. Map : transforme l’entrée en couples (clef,valeur)
Ces bases de données ont certaines caractéristiques : 2. Reduce : calcule 1 valeur à partir de la liste des valeurs associées à
I pas de schéma pour les données chaque clef
I données de structures complexes ou imbriquées I L’environnement d’exécution de l’algorithme MapReduce s’occupe
I mode d’utilisation : peu d’écritures, beaucoup de lectures de l’aspect distribution : le programme est distribué sur les di↵érents
I
noeuds, on a donc une exécution en parallèle.
on privilégie la disponibilité à la cohérence : A+P plutôt que C+P,
I Un programme complexe est décomposé en une succession de tâches
! ces solutions NoSQL ne contiennent pas de support pour les
transactions (ou rarement) Map et Reduce.
I Données distribuées : on a souvent la possibilité d’utiliser des
algorithmes MapReduce.

MapReduce MapReduce
15 / 29 16 / 29
Fonctions de base Exemple

On reprend les documents du transparent 6, on applique les fonctions
1. map : (K 1, V 1) ! list(K 2, V 2)
map et reduce du transparent précédent pour compter le nombre de
function map(uri, doc) documents par terme.
// uri : nom (id) du document, doc : le contenu du document
foreach distinct term in doc
output (term, count(term, doc))
2. shu✏e : list(K 2, V 2) ! list(K 2, list(V 2)) regroupe les couples
intermédiaires en fonction de leur clef.
3. reduce : (K 2, list(V 2)) ! list(K 3, V 3)
function reduce(term, counts)
output (term, sum(counts))
Couples (clef,valeur)
17 / 29 18 / 29
Bases NoSQL Couples (clef,valeur)

Nous allons voir maintenant les di↵érents paradigmes utilisés pour les La base est une table de hachage distribuée. On dispose en général de 4
bases NoSQL. opérations :
1. stockage de couples (clé,valeur) 1. Create : créer un nouveau couple (clef,valeur). La valeur est
n’importe quel objet.
2. bases de documents
2. Read : lire un objet connaissant sa clef
3. bases orientées colonnes
3. Update : mettre à jour l’objet associé à une clef
4. bases de graphes
4. Delete : supprimer un objet connaissant sa clef
on ne peut pas e↵ectuer de requête sur le contenu des objets
stockés.
Quelques exemples :
I Amazon Dynamo, dont Riak est l’implémentation Open Source.
I Redis, projet sponsorisé par VMWare. Toutes les données doivent
tenir en mémoire.
I Voldemort, développé par LinkedIn en interne puis passage en open
source.

Couples (clef,valeur) Bases de documents
19 / 29 20 / 29
Exemple : Riak Bases de documents

I stockage (clé,valeur) distribué : hachage distribué I on stocke une collection de ”documents”
I accès via une API Restful (put, get, post, delete) I un document a une structure arborescente : il contient une liste de
I pas de schéma, les données stockées sont quelconques : images, champs, un champs a une valeur qui peut elle même être une liste
texte (libre, ou semi-structuré comme XML et JSON), vidéos, ... de champs, ...
I le format choisi est semi-structuré comme JSON ou XML. On peut
I pas de langage de requête, pas d’opération un peu complexe que
stocker n’importe quel objet, via une sérialization
l’on pourrait envoyer via une URL
I les documents n’ont pas de schéma : grande flexibilité
I gère la réplication : un cluster primaire qui contrôle la réplication sur
I Remarque : ces bases sont parfois utilisées pour stocker les données
un ou plusieurs clusters secondaires
JSON d’applications écrites en javascript, ce qui évite un mapping
I Théorème CAP : privilégie A+P objet-relationnel (exemple MEAN/MERN).
I programmation MapReduce essentiellement en Erlang (aussi en
Quelques exemples :
d’autres langages comme javascript mais moins performant).
I MongoDB
I Couplage possible avec Redis pour la gestion du Cache
I CouchBase fondation Apache. intégration de CouchDB dans
I Si on intègre le moteur de recherche full-text SolR, Riak devient
memBase
(presque) une base de documents.
I RavenDB
Bases de documents Bases de documents
21 / 29 22 / 29
Exemple : CouchBase Les vues en CouchBase

I Modèle semi-structuré, basé sur JSON (Javascript object notation). I CouchBase propose des vues structurées définies grâce au
{ paradigme MapReduce : une vue est donc une liste de couples
"title": "The Social network",
"year": "2010",
(clé,valeur)
"director": {"last_name": "Fincher", I Les vues permettent de définir des indexes secondaires sur les
"first_name": "David"}, documents (l’index primaire est selon le document id)
"actors": [
{"first_name": "Jesse", "last_name": "Eisenberg"}, I A la création d’une vue, on applique les fonctions map-reduce sur
{"first_name": "Rooney", "last_name": "Mara"} l’ensemble des documents, et le résultat est matérialisé sous la forme
] d’un index B-arbre.
}
I 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.
I les documents sont répliqués (maximum 3 fois)
I méthodes set/get pour qu’une application récupère/fournisse un
document (pas une partie d’un document)

Bases orientées colonnes Bases orientées colonnes
23 / 29 24 / 29
Bases orientées colonnes HBase - le Modèle de données

I Les données sont stockées par colonne, non par ligne. I Table : les données sont organisées en Tables
I On peut facilement ajouter des colonnes aux tables, par contre I Ligne : Dans une table, on stocke des lignes, identifiées par leur Rowkey.
l’insertion d’une ligne est plus coûteuse. I Famille de colonnes : A l’intérieur d’une ligne, les données sont groupées
I Quand les données d’une colonne se ressemblent, on peut facilement par familles de colonnes. Ces familles ont un impact sur le stockage
compresser la colonne. physique, et doivent être connues à l’avance. Toutes les lignes d’une table
I Ce concept de base orientée colonnes existait avant NoSQL ont les mêmes familles de colonne (donc ces familles constituent le
I MonetDB pour le modèle relationnel, schéma de la table).
I modèle efficace pour des requêtes OLAP I Colonne : Les données d’une famille de colonnes sont découpées en
Quelques exemples en NoSQL : 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.
I BigTable de Google et son implémentation open source (Apache) I Cellule : pour 1 ligne, 1 famille et 1 colonne, on a 1 seule cellule.
HBase. Google utilise BigTable pour l’indexation des pages web,
I Version : Les valeurs d’une cellule sont versionnées.
Google Earth, Google analytics, ...
I I il n’y a pas vraiment de type de données : tout est traité comme byte [].
Cassandra fondation Apache, projet né chez Facebook à partir de
Amazon’s Dynamo et Google’s BigTable. I HBase peut-être vue comme une ”sorted map of maps”.
I SimpleDB de Amazon. Service Web.
Bases orientées colonnes Bases orientées colonnes
25 / 29 26 / 29
HBase
I HBase est construit au dessus de HDFS, système de fichier distribué.
I 1 table est stockée dans une ou plusieurs régions, Le découpage se fait
par famille de colonnes, chacune stockée dans des HFiles (HDFS).
I HBase est construit au dessus de Hadoop, framework de programmation
distribuée, basé sur MapReduce ! HBase propose donc aussi une API
pour MapReduce
I HBase est fortement consistent (C+P) sur 1 cluster : HDFS gère la
réplication des données à chaque écriture, et si un serveur de régions
tombe en panne, il faut modifier les informations ”dans quelle région
trouver quelle donnée”, pendant ce temps la base n’est plus disponible.
Quand on a plusieurs clusters, les clusters de réplication ne donnent pas
forcément la donnée la plus récente (mais système ”eventually
consistent”).
I HBase ne permet pas l’indexation des données, autrement qu’avec la
rowkey.
I HBase permet de gérer beaucoup de données ... il n’est pas adapté pour 1
seule machine.

Bases orientées colonnes Bases de graphes
27 / 29 28 / 29
Architecture BigTable/HBase Bases de graphes

I Utilisation d’un moteur de stockage pour les objets, du type base de
documents.
I Mécanisme permettant de décrire des arcs (relations entre objets),
arcs orientés et pouvant posséder des propriétés
I Ces bases sont adaptées à la manipulation d’objets complexes
organisés en réseaux : cartographie, réseaux sociaux, web sémantique
...
Quelques exemples :
I Neo4j
I OrientDB fondation Apache
même architecture pour BigTable et HBase. Une région HBase correspond à

une ”tablet” BigTable
NoSQL pour le BigData
Bases NoSQL
Bases de graphes
29 / 29
Exemple : Neo4j
I très efficace pour traverser un graphe (pas de jointure)
I algorithmes classiques sur les graphes, que l’on peut appeler avec
l’interface REST
I Par défaut, Neo4j gère des transactions avec les propriétés ACID.
I 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)
I Peut gérer plus de 30 milliards de sommets, et plus de 30 milliards
de relations (arcs).
I Pas de support pour de la programmation MapReduce

NoSQLPar4 PDF

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

NoSQLPar4 PDF

Transféré par

Droits d'auteur :

Formats disponibles

NoSQL pour le BigData NoSQL pour le BigData

NoSQL pour le BigData NoSQL pour le BigData

Un cas d’utilisation : Recherche sur le Web Inverted File

NoSQL pour le BigData NoSQL pour le BigData

Inverted File - structure Système distribué

Exemple : Data Centers de Google Schéma : LAN/data center

NoSQL pour le BigData NoSQL pour le BigData

Bases NoSQL Algorithme MapReduce

NoSQL pour le BigData NoSQL pour le BigData

Fonctions de base Exemple

Bases NoSQL Couples (clef,valeur)

NoSQL pour le BigData NoSQL pour le BigData

Exemple : Riak Bases de documents

Exemple : CouchBase Les vues en CouchBase

NoSQL pour le BigData NoSQL pour le BigData

Bases orientées colonnes HBase - le Modèle de données

NoSQL pour le BigData NoSQL pour le BigData

Architecture BigTable/HBase Bases de graphes

même architecture pour BigTable et HBase. Une région HBase correspond à

Vous aimerez peut-être aussi