Entrepots de donneesNoSQL

Thierry Hamon

Bureau H202Institut Galilee - Universite Paris 13

&LIMSI-CNRS

hamon@limsi.fr

https://perso.limsi.fr/hamon/Teaching/P13/DWH-AIR3-2018-2019/

AIR3 – DWH

1/83

Sources des transparents

Bernd Amann, LIP6

Bernard Espinasse, Ecole Polytechnique Universitaire deMarseille

Olivier Guibert, Universite de Bordeaux

Anne-Cecile Caron, Universite de Lille

2/83

Introduction

Introduction

Constats :

De plus en plus de donnnees disponibles ou a manipuler

tres grandes plateformesapplications Web (Google, Facebook, Twitter, Amazon, ...)

Necessite de la gestion des donnees de maniere distribueeLe respect des proprietes ACID (Atomicite, Coherence,Isolation et Durabilite) n’est pas possible dans unenvironnement distribue

Aussi, manipulation

de donnees complexes, heterogenes, non structureesde tres grands volumes de donnees (Big Data)

3/83

Introduction

Evolutions de la gestion des donnees

Nouvelles Donnees :Web 2.0 : Facebook, Twitter, news, blogs, ...LOD : graphes, ontologies, ...Flux : capteurs, GPS, ...

→ Tres gros volumes, donnees pas ou faiblement structurees

Nouveaux Traitements :

Moteurs de rechercheExtraction, analyse, ...Recommandation, filtrage collaboratif, ...

→ Transformation, agregation, indexation

Nouvelles Infrastructures :Cluster, reseaux mobiles, microprocesseurs multi-coeurs, ...

→ Distribution, parallelisation, redondance

4/83

Introduction

Augmentation du volume de donnees

w3resource.com/mongodb/nosql.php

5/83

Introduction

Caracteristiques du Big Data

Variete : Gestion et Utilisation des differentes types etstructures de donnees

Velocite : Anlyse de flux de donnees et de grands volumes dedonnees persistentes

Volume : Capacite a traiter des Teraoctets (240) a desZettoctets (270) de donnees

6/83

Introduction

Limites de SGBD relationnels/traditionnels

Faible efficacite lorsque les volumes de donnees sont importants car

Transaction respectant les proprietes ACIDRequetes LMJ realisees sequentiellement et preservantl’integrite des donnees→ Gestion des transaction complexe ayant un impact sur lesperformances

Modele ER flexible mais peu adapte aux donneesnon-structurees→ peu performant et couteux en temps de developpement

Materiel et logicieux couteux et competences en optimisationpeu repandues→ Necessite de distribuer les traitements

7/83

Introduction

NoSQL

Definition de systemes � NoSQL � (not only SQL)

Pour repondre a l’augmentation du volume de donnnees atraiter :

Specialisation des systemesSystemes sur mesurePas d’utilisation de SQL comme langage de requete

Generalement des modeles de donnees differents :

Document storeTabular storeKey-value storeGraph store

8/83

Introduction

Systemes NoSQL

Caracteristiques :

Facilite d’utilisation

Coherence des donnees pas forcement assuree

Persistence des donnees

Fiabilite (pannes) pas forcement assuree

Efficacite

Pas d’Universalite

→ Theoreme CAP

9/83

Introduction

Systemes NoSQL

Composants et fonctionnalites :

Langages specialisees

Donnees heterogenes

Replication

Parallelisation

Indexation de contenus

10/83

Introduction

Coherence, Disponibilite, Pannes

Theoreme CAP (Brewer, 2000) :

dans un systeme distribue il est impossible de garantir achaque instant T plus que deux parmi les trois proprietesfondamentales suivantes :

Coherence (Coherency) :tous les noeuds voient la meme version

Disponibilite (Availability) :chaque requete obtient une reponse

Resistance a une panne partielle (Partition tolerance) :la perte de messages n’empeche pas le systeme de continuer afonctionner

11/83

Introduction

Theoreme CAP

w3resource.com/mongodb/nosql.php

12/83

Introduction

Illustration du theoreme CAP

1 Un premier utilisateur modifie une valeur sur l’un des nœudsdu systeme.

2 Un second utilisateur voulant lire cette valeur sur un autrenœud doit attendre leur synchronisation pour garantir lacoherence.

Or

Ce temps d’attente est incompressible

Sur un systeme tres charge et tres vaste, il vaconsiderablement influencer la disponibilite et la resistance aumorcellement

13/83

SGBD NoSQL

SGBD NoSQLDefinition

SGBD non fonde sur

l’architecture des SGBDR

open source

distribue

horizontally scalable (montee en charge par ajout de serveurs)

14/83

SGBD NoSQL

SGBD NoSQLSimplification en renoncant aux fonctionnalites classiques desSGBDR :

Redondance (via replication)

Pas forcement de schema normalise, initialement voire a terme

Pas de tables mais des collections

Rarement du SQL mais API simple ou langage specialise

Pas forcement de jointure mais multiplication des requetes,cache/replication/donnees non normalisees, donnees imbriquees

Transactions pas forcement ACID mais plutot BASE

Resisitance aux pannes (P) s’impose pour un systeme distribue :

AP (accepte de recevoir des donnees eventuellementincoherentes)CP (attendre que les donnees soient coherentes)

15/83

SGBD NoSQL

SGBD NoSQL

Gestion des megadonnees (big data) du web, des objets connectes,etc.

Structure des donnees heterogene et evolutive

Donnees complexes et pas toujours renseignees

Environnement distribue : donnees repliquees et accedees d’un peupartout (dans le monde), traitement repartis

Techniques de partionnement des BD : sharding, hachage coherent(consistent hashing)

Controle de concurrence multi-version (Multi-Version ConcurrencyControl MVCC)

Adaptation du protocole Paxos

Performances lineaires avec la montee en charge (les requetesobtiennent toujours aussi rapidement une reponse)

16/83

SGBD NoSQL

Proprietes BASE

SGBD issu du cloud computing et des systemes distribues :

privilegiant la haute disponibilite des donnees (distribuees), larapidite, la simpliciteau detriment de la coherence, de l’exactitude de la reponse

Proprietes BASE :

Basically Available : le systeme doit toujours etre accessible(ou indisponible sur de courtes periodes)Soft state : l’etat de la BD n’est pas garanti a un instantdonne (les mises a jour ne sont pas immediates : cf. coherencea terme)Eventual consistency : la coherence des donnees a un instantdonne n’est pas primordiale (mais assuree a terme :verrouillage optimiste en reportant a plus tard la verification del’integrite)

17/83

SGBD NoSQL

Protocole Paxos

Paxos :Famille de protocoles pour resoudre le consensus (processuspermettant de parvenir a une decision sur un resultat) dans unreseau de nœuds faillibles

Protocole Paxos

Informations gerees :

echanges entre les nœudstemps entre chaque reponse a un message avant de prendreune decisionniveau d’activite des participantsnombre de messages envoyestypes de pannes

18/83

SGBD NoSQL

Protocole Paxos

A un instant donne, chaque acteur a au moins un role : client,acceptor, proposer, learner, leaderEn fait, plusieurs pour permettre de baisser la latence entre lesmessages

Pas d’incoherence possible, et les conditions qui peuvent l’empecherde progresser (s’executer jusqu’a apporter une reponse valable) sontraresTheoreme : aucun algorithme de consensus resistant aux pannes nepermet de garantir de progresser sur un reseau asynchrone→ integrite garantie si moins de la moitie des processus en panne

E/S & transaction

Tres efficace pour la lecture dans un environnement distribueBeaucoup moins efficace pour l’ecriture/modificationNe gere pas les transactions ACID

Cas d’utilisation : application devant assurer la durabilite

19/83

SGBD NoSQL

Protocole Paxos : roles

Client : envoie des requetes au systeme distribue et attend unereponse

Acceptor sont regroupes en quorums et servent de memoireresistante au panneChaque message envoye a un acceptor doit l’etre au quorum entier

Proposer : pousse la requete du clientil doit convaincre les acceptors de tomber d’accord, et agıt commecoordinateur pour avancer quand un conflit se presente

20/83

SGBD NoSQL

Protocole Paxos : rolesLearner : servent a la replication

une fois qu’une requete d’un client a ete acceptee par lesacceptors,le learner peut agir (executer une requete et envoyer lareponse au client)Pour augmenter la disponibilite, on peut ajouter des learners

Leader : Proposer specifique pour avancer

Plusieurs processus peuvent croire etre le leadermais le protocole ne garantit l’avancement que si l’un d’eux estchoisiRemarque : si plusieurs processus croient qu’ils sont leaders

ils peuvent bloquer le protocole en envoyant continuellementdes propositions conflictuelles,mais l’integrite des donnees est cependant toujours preserveedans ce cas

21/83

SQL vs. NoSQL

SQL vs. NoSQL

Coherence forte :

Logique : Schemas,contraintesPhysique :Transactions ACID

Distribution des donnees

Transactionsdistribuees

Ressources limitees

Optimisation derequetes

Langage standard : SQL

Coherence faible :

Pas de schemas, pas decontraintesCoherence � a terme �

Distribution destraitements :

Traitements � batch �

MapReduce

Ressources � illimitees �

Passage a l’echellehorizontal

Langages specialises, API

22/83

SQL vs. NoSQL

SQL vs. NoSQL

Traitements centralises

Acces distribue

Traitements distribues

Acces local

23/83

SQL vs. NoSQL

SQL vs. NoSQL

Acces a grain fin

beaucoup de lectures /ecritures de de petitsobjets

Acces � batch �

peu de lectures / ecrituresde grands objets

24/83

SQL vs. NoSQL

Vers NoSQL

Etendre / adapter un SGBD traditionnel :niveaux de concurrence, indexes, stockage

Definir des systemes specialises pour

une infrastructure (distribue) : cloud, clustersun type de donnees : profils, documents XML, RDF, ...un type de traitements : partage, analyse/agregation,visualisation

25/83

Modeles de BD NoSQL

Classification de systemes

Types de donnees : tables, cles/valeurs, arbres, graphes,documents

Paradigme (langages) : MapReduce (PIG, Hive)

API / Protocole : JSON/REST

Persistence : memoire, disque, cloud...

Gestion de concurrence / coherence

Replication, protocoles

Langage d’implementation, ...

Voir https://db-engines.com/en/ranking

26/83

Modeles de BD NoSQL

Systemes NoSQL

27/83

Modeles de BD NoSQL

Modeles NoSQL

Modeles cle-valeur (Key-value store - KVS)

Modele colonne (Tabular store - TS)

Modele document (Document store - DS)

Modele Graphe (Graph store - GS)

Autres types de systemes � noSQL � : XML, Triplestore(RDF), orientes objets

28/83

Modeles de BD NoSQL

Modele cle-valeur

DefinitionBD = 1 tableau associatif unidimensionnelChaque objet de la base represente par un couple (cle,valeur)est identifie par une cle unique qui est le seul moyen d’acces al’objetStructure de l’objet libre (du ressort du programmeur)Variante : cles triees en ordre lexicographique

OperationsLes 4 operations CRUD :

create(cle,valeur) : cree un couple (cle, valeur)read(cle) : lit une valeur a partir de sa cleupdate(cle,valeur) : modifie une valeur a partir de sa cledelete(cle) : supprime un couple a partir de sa cle

Souvent interface HTTP REST (Representational StateTransfer) disponible depuis n’importe quel langage

29/83

Modeles de BD NoSQL

Modele cle-valeur

UtilisationDepot de masses de donnees avec des besoins de requetagesimple pour des analyses en temps-reel (sessions web etfichiers de log, profils utilisateurs, donnees de capteurs, ...),gestion de caches

Logiciels Riak (ou Amazon Dynamo), Redis, Voldemort,Oracle NoSQL Database

Commentaires :

Avantages : simple, tres performant, bonne mise a l’echelle,disponibilite, evolutivite des valeursInconvenients : interrogation seulement sur la cle, complexitedes valeurs a gerer dans les programmes

30/83

Modeles de BD NoSQL

Modele colonne

Definition

Donnees stockees en colonnesLa colonne est l’entite de base representant un champ dedonneeChaque colonne est definie par un couple (cle,valeur) avec uneestampille (pour gerer les versions et les conflits)Une super-colonne est une colonne contenant d’autres colonnesUne famille de colonnes regroupe plusieurs colonnes ou super-colonnes ou les colonnes sont regroupees par ligne et chaqueligne est identifiee par un identifiant unique et par un nomunique

OperationsLes requetes doivent etre predefinies en fonction de l’organisation en

colonnes (et super-colonnes et familles de colonnes) choisie

31/83

Modeles de BD NoSQL

Modele colonneSchema des donnees (keyspace) d’une application

32/83

Modeles de BD NoSQL

Modele colonne

Utilisation

Analyse de donnees, OLAP, data mining, entrepot de donneesgestion de donnees semi-structureesjeux de donnees scientifiques, genomique fonctionnellejournalisation d’evenements et de compteursanalyses de clientele et recommandation, stockage de listes(messages, posts, commentaires, ...), traitements massifs

33/83

Modeles de BD NoSQL

Modele colonne

Exemples :

Netflix (logging et analyse de sa clientele)eBay Inc. (optimisation de la recherche)Adobe Systems Incorporated (traitement de donneesstructurees et d’informatique decisionnelle (BusinessIntelligence (BI)))societes de TV (connaissance de leur audience et gestion duvote des spectateurs)

LogicielsHBase (ou BigTable), Cassandra, SimpleDB

34/83

Modeles de BD NoSQL

Modele colonneAvantages :

bonne mise a l’echelle horizontaleefficace avec l’indexation sur les colonnes et pour des requetestemps-reel connues a l’avancecapacite de gestion de donnees tabulaires a schema variable et dedonnees semi-structurees

ajout/fusion facile des colonnesajout une colonne/super-colonne a n’importe quelle ligned’une colonne/super-colonne/super-colonne

nombre de colonnes dynamique (variable d’un enregistrement a unautre permettant d’eviter les indeterminations)

Inconvenients :

ne supporte pas les donnees structurees complexes ouinterconnecteesmaintenance necessaire pour la modification de structure en colonneajout de ligne couteuxrequetes doivent etre pre-ecrites

35/83

Modeles de BD NoSQL

Modele document

Definition

BD = collection de documents Modele cle-valeur ou la valeurest un document (lisible par un humain) au formatsemi-structure hierarchique (XML, YAML, JSON ou BSON,etc.)Document (structure arborescente) = collection de couples(cle,valeur) Valeur de type simple ou composee de plusieurscouples (cle,valeur)

Operations

Les operations CRUD du modele cle-valeurSouvent interface HTTP REST disponibleRequetage (API ou langage) possible sur les valeurs desdocuments

36/83

Modeles de BD NoSQL

Modele document

Utilisation

Outils de gestion de contenu (Content Management System –CMS)catalogues de produitsweb analytiqueanalyse temps-reelenregistrement d’evenementsstockage de profils utilisateurssystemes d’exploitationgestion de donnees semi-structurees

LogicielsCouchDB, RavenDB, MongoDB, Terrastore

37/83

Modeles de BD NoSQL

Modele document

Avantages :

performances eleveesbonne mise a l’echellemodele simple augmente de la richesse des documentssemi-structuresexpressivite des requetesschema de BD evolutifefficace pour les interrogations par cle

Inconvenients :

peut etre limite pour les interrogations par le contenu desdocumentslimite aux donnees hierarchiquesinadapte pour les donnees interconnecteesbaisse des performances pour de grandes requetes

38/83

Modeles de BD NoSQL

Modele grapheGestion d’un graphe (a priori oriente) :

modelisationstockagemanipulation de donnees complexes liees par des relationsnon-triviales ou variables

Mecanisme

Moteur de stockage pour les objets (qui se presentent sous laforme d’une base documentaire, chaque entite de cette baseetant un nœud)Description des arcs (relations entre les objets) disposant deproprietes (nom, date, ...)

OperationsSPARQL pour les SGBD NoSQL et les graphes RDFAPI et langages specialises de programmation et de requetessur les graphes

39/83

Modeles de BD NoSQL

Modele graphe

Utilisation

Moteurs de recommandation, reseaux sociauxinformatique decisionnelleweb semantique, donnees liees, donnees ouvertes (open data)internet des objets (internet of things (IoT)),sciences de la vie et calcul scientifique (bioinformatique, ...)donnees geospatialesdonnees hierarchiques (catalogue des produits, genealogie, ...)reseaux de transport, services de routage et d’expedition,services financiers (chaıne de financement, dependances,gestion des risques, detection des fraudes, ...)

LogicielsNeo4J, OrientDB

40/83

Modeles de BD NoSQL

Modele graphe

Avantages :

modele riche et evolutif bien adapte aux situations ou il fautmodeliser beaucoup de relationsnombreux langages et API bien etablis et performants

Inconvenients

repartition des donnees peut etre problematique pour de grosvolumes de donneesfragmentation (sharding)

41/83

Fondements des systemes NoSQL

Fondements des systemes NoSQL

Sharding : partitionnement sur plusieurs serveurs

Consistent hashing : partitionnement des donnees surplusieurs serveurs eux-memes partitionnes sur un segment

Map Reduce : modele de programmation parallele permettantde paralleliser tout un ensemble taches a effectuer sur unensemble de donnees,

MVCC (Controle de Concurrence Multi-Version) : mecanismepermettant d’assurer le controle de concurrence

Vector-Clock (horloges vectorielles) : mises a jourconcurrentes en datant les donnees par des vecteurs d’horloge

42/83

Fondements des systemes NoSQL

ShardingEnsemble de techniques qui permet de repartir les donnees surplusieurs machines pour assurer la scalabilite de l’architecture

Partitionnement horizontal d’une BD (collection) :

Stockage des donnees sur des nœuds serveurs differents en fonctiond’une cle (fonction de hachage)Acces ou mise a jour des objets-donnees en meme temps s’ilsresident sur le meme nœudEquilibrage de charge automatique : replication uniforme de lacharge entre les nœudsReplication des objet-donneesPlusieurs milliers de nœudsAjout / suppression (dynamique) de nœuds

Certains systemes utilisent aussi un partitionnement vertical (parcolonnes) dans lequel des parties d’un enregistrement sont stockees surdifferents serveurs

43/83

Fondements des systemes NoSQL

Consistent hashingMecanisme de partitionnement (horizontal) dans lequel les objet-donnees

sont stockes sur des nœuds-serveurs differents en utilisant la meme

fonction de hachage a la fois pour le hachage des objets et le hachage

des nœuds :

les nœuds et objets sont associes par une meme fonction de hachage, etimagines etre places 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 associes au nœud A ; 2 a B ; 3 a C

quand un nœud quitte l’anneau, les objets qui lui sont lies sont alorsassocies 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 etdes objets lui seront associes selon sa place dans l’anneau :

le nœud D entre dans l’anneau, les objets 3 et 4 lui sont associes

44/83

Fondements des systemes NoSQL

Parallelisation : MapReduce

MapReduce : distribution des donnees sur de nombreux serveursvers lesquels on pousse les programmes (car plus efficace detransferer un petit programme sur le reseau plutot qu’un grandvolume de donnees)

Entree :

une (grande) collection d’objets (documents, donnees)un traitement / calcul ensembliste : compter, agreger, filtrer,indexer, jointureun grand nombre de machines connectees

Probleme :

paralleliser le traitement en utilisant efficacement les machinesdisponibles

45/83

Fondements des systemes NoSQL

Approche MapReduce

Programme :

Sequence de deux appels de fonctions :map1 → reduce1 → map2 → reduce2 → ...Coordinateur

Deploiement des donnees et des traitements dans le clusterCoordination de l’execution

Avantage :

Parallelisation �automatique� de l’evaluationVirtualisation de l’infrastructure

46/83

Fondements des systemes NoSQL

2 fonctions :1 Map : transforme l’entree en couples (clef,valeur)2 Reduce : calcule une valeur a partir de la liste des valeurs

associees a chaque clef

L’environnement d’execution de l’algorithme MapReduces’occupe de l’aspect distribution :le programme est distribue sur les differents noeuds, on a doncune execution en parallele.

47/83

Fondements des systemes NoSQL

Parallelisation : MapReduce

Collection d’objets = collection de couples (Cles, Valeurs)

Deux fonctions utilisateur f et g :

map(f , [(A,V )])→ (B,V ′)∗ :map(countWords, (url , doc))→ (mot, int)∗

shuffle(B,V ′)∗ → (B,V ′∗)∗ :shuffle(mot, int)∗ → (mot, int∗)∗

(group by mot)

reduce(g , (C ′,V ′∗)∗)→ (C ,V ′′)∗ :reduce(sum, (mot, int∗)∗)→ (mot, int)∗

(agregation)

48/83

Fondements des systemes NoSQL

MapReduce (exemple)

49/83

Fondements des systemes NoSQL

MVCCMulti-Version Concurrency Control

Controle de concurrence multi-version

Modification d’une donnee

non pas par ecrasement des anciennes donnees par les nouvellesmais en indiquant que les anciennes donnees sont obsoleteset en ajoutant une nouvelle versionseule la plus recente etant correcte

→ necessite d’une purge reguliere des donnees obsoletes

50/83

Fondements des systemes NoSQL

Horloges vectorielles - Vector-ClockLes ensembles de donnees repartis sur nœuds peuvent etre lus et modifiessur chaque nœud et aucune coherence stricte n’est assuree par desprotocoles de transactions distribueesProbleme : comment faire des modifications concurrentes

Une solution : les horloges vectorielles :

un vecteur d’horloge est defini 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’horlogerepresentant son etat et celui des autres nœuds repliques :(Vi [0] = valeur de l’horloge du premier noeud, Vi [1] = valeur del’horloge du deuxieme noeud, ... Vi [i] = sa propre valeur d’horloge,... Vi [n] = valeur de l’horloge du dernier nœud)

les valeurs d’horloge peuvent etre de reelles timestamps deriveesd’une horloge locale de nœud, du numero de version/revision ...

51/83

Fondements des systemes NoSQL

Hadoop

Hadhoop pour High-Availability Distributed Object-OrientedPlatform : framework de reference, libre et open source

Systeme distribue qui permet d’analyser, stocker et manipuler detres grandes quantites de donnees (Big Data)

Creation par Doug Cutting en 2002 pour les besoins du projet� Apache Nutch �

integration MapReduce suite a la sortie de l’article de Google en2004

Yahoo! : contributeur majeur au projet Hahoops

Depuis 2008 : projet independant de la fondation Apache

Utilisation par les geants du web comme Yahoo!, Twitter, LinkedIn,eBay, Amazon, ...

52/83

Fondements des systemes NoSQL

Hadoop

Hadoop n’a d’interet que pour gerer des donnees de tresgrande taille dans un environnement compose de tresnombreuses machines (data centers)

Hadoop fractionne les fichiers en gros blocs,

il distribue ces blocks 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

Fondements des systemes NoSQL

Hadoop

https://blog.octo.com/hadoop-une-plateforme-de-reference-pour-faire-du-big-data/

54/83

Fondements des systemes NoSQL

Composition du framework HadoopHadoop Distributed File System (HDFS)Systeme de gestion de fichiers distribues permettant de stocker lesdonnees sur les machines du clusterHadoop CommonBibliotheques et utilitaires necessaires aux autres modules HadoopHadoop YARN (Yet Another Resource Negotiator)Plate-forme chargee de la gestion des ressources informatiques duclusters et de les utiliser pour la planification des applications desutilisateursHadoop MapReduceImplementation du modele de programmation MapReduce pour letraitement des donnees a grande echelle

Ecosysteme et ensemble des logiciels : Apache Pig, Apache Hive,Apache HBase, Apache Phoenix, Apache Spark, Apache ZooKeeper,Cloudera Impala, Apache Flume, Apache Sqoop, Apache oozie etApache Storm

55/83

Exemples de systemes NoSQL

Exemple : Riak

stockage (cle,valeur) distribue : hachage distribue

acces via une API Restful (put, get, post, delete)

pas de schema, les donnees stockees sont quelconques : images,texte (libre, ou semi-structure comme XML et JSON), videos, ...

pas de langage de requete, pas d’operation un peu complexe quel’on pourrait envoyer via une URL

gere la replication : un cluster primaire qui controle la replicationsur un ou plusieurs clusters secondaires

Theoreme CAP : privilegie A+P

programmation MapReduce essentiellement en Erlang (aussi end’autres langages comme javascript mais moins performant).

Couplage possible avec Redis pour la gestion du Cache

Si on integre le moteur de recherche full-text SolR, Riak devient(presque) une base de documents.

56/83

Exemples de systemes NoSQL

Exemple : CouchBaseModele semi-structure, base sur JSON (Javascript objectnotation){

” t i t l e ” : ”The S o c i a l network ” ,” 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 ”} ,” a c t o r s ” : [{” 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 distribues sur uncluster. Une fonction de hashage permet d’associer 1 partition(donc un serveur) a 1 document.les documents sont repliques (maximum 3 fois)methodes set/get pour qu’une application recupere/fournisseun document (pas une partie d’un document)

57/83

Exemples de systemes NoSQL

Exemple : CouchBase

Vues en CouchBase

CouchBase propose des vues structurees definies grace auparadigme MapReduce : une vue est donc une liste de couples(cle,valeur)

Les vues permettent de definir des indexes secondaires sur lesdocuments (l’index primaire est selon le document id)

A la creation d’une vue, on applique les fonctions map-reducesur l’ensemble des documents, et le resultat est materialisesous la forme d’un index B-arbre.

58/83

Exemples de systemes NoSQL

Exemple : HBaseModele de donnees

Table : les donnees sont organisees en Tables

Ligne : Dans une table, on stocke des lignes, identifiees par leur Rowkey.

Famille de colonnes : A l’interieur d’une ligne, les donnees sont groupeespar familles de colonnes. Ces familles ont un impact sur le stockagephysique, et doivent etre connues a l’avance. Toutes les lignes d’une tableont les memes familles de colonne (donc ces familles constituent leschema de la table).

Colonne : Les donnees d’une famille de colonnes sont decoupees encolonnes. Ces colonnes ne sont pas connues a l’avance, et on n’a pastoujours les memes 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 versionnees.

il n’y a pas vraiment de type de donnees : tout est traite comme byte.

HBase peut-etre vue comme une sorted map of maps.

59/83

Exemples de systemes NoSQL

Exemple : HBase

60/83

Exemples de systemes NoSQL

Neo4j

tres efficace pour traverser un graphe (pas de jointure)

algorithmes classiques sur les graphes, que l’on peut appeleravec l’interface REST

Par defaut, Neo4j gere des transactions avec les proprietesACID.

Pour le passage a l’echelle en mode distribue, utiliser Neo4jHA (pour High Availability) : available et partition tolerant(A+P du theoreme CAP)

Peut gerer plus de 30 milliards de sommets, et plus de 30milliards de relations (arcs).

Pas de support pour de la programmation MapReduce

61/83

Exemples de systemes NoSQL

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 donnees

MySQL CassandraEcriture 300ms 0.12msLecture 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)

Ecrit en C++

64/83

MongoDB

MongoDB

SGBD

oriente documentslibrescalable : replication, auto-shardingflexible : pas de schema de donnees, full-text indexecrit en C++.

Il fait partie de la mouvance NoSQL et vise a fournir desfonctionnalites avancees. Utilisee par Foursquare, bit.ly,Doodle, Disqus

65/83

MongoDB

Mongo DB

Modele logique

BD = ensemble de collectionsCollection = ensemble de documents

Taille variableTaille fixe (capped) : LRU

Document = objet BSON

Modele physique

Index : attributs, geo-spatialMapReduceSharding (partitionnement horizontal)

66/83

MongoDB

Langage MongoDBLMD

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 odoc = { ”nom” : ” t o t o ” ,

” i n f o ” : {” t w i t t e r ” : ” @toto5646 ” ,” e m a i l ” : ” toto@upmc . f r ” } ,

” amis ” : 87687 ,” photo ” : 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 : requete

update : modifications

upsert (booleen) :

false (defaut) : updatetrue : update or insert if not exists

multi (booleen) :

false (defaut) : maj de la 1ere occurrence trouveetrue : maj toutes les occurrence

69/83

MongoDB

Update

db . p r o d u c t s . update ( { i t em :” book ” , qty : { $gt : 5 } } , { $ s e t :{ x : 6 } , $ i n c : { y : 5} } )

db . p r o d u c t s . update ( { i t em :” book ” , qty : { $gt : 5 } } , { x : 6 ,y : 15 } )

db . p r o d u c t s . update ( { i t em :” book ” , qty : { $gt : 5 } } , { $ s e t :{ x : 6 , y : 15 } } , { m u l t i : t r u e } )

db . p r o d u c t s . update ( { i t em :” book ” , qty : { $gt : 5 } } , { $ s e t :{ x : 6 , y : 15 } } , f a l s e , t r u e )

db . p r o d u c t s . update ( { i t em :” magazine ” , qty : { $gt : 5 } } ,

{ $ s e t : { x : 25 , y : 50 } } ,{ u p s e r t : t r u e } )

70/83

MongoDB

Requetes

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 indOne ({ ”nom” : ” t o t o ” } ) ;db . c o n t a c t i n f o . f indOne ({ ” 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 ” : {

” $gt ” : 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 ) . s k i p ( 1 0 0 )

71/83

MongoDB

Requetesdb . employee . i n s e r t ({

”name” : ” John Smith ” ,” a d d r e s s ” : {

” s t r e e t ” : ” L i l y Road” ,”number” : 32 ,” c i t y ” : ”Owatonna” ,” z i p ” : 55060

} ,” h o b b i e s ” : [ ” y o d e l i n g ” , ” i c e s k a t i n g ” ]

})

db . employee . FindOne ({”name” : ” John Smith ”})

db . employee . f i n d ({” a d d r e s s . c i t y ” : ”Owatonna”} ,{”name” : 1})

db . employee . f i n d ({” a d d r e s s . c i t y ” : ”Owatonna”} ,{”name” : 1})

db . employee . f i n d ({” 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 auth = 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 ( ) ;f o r ( S t r i n g s : c o l l s ) {

System . out . p r i n t l n ( s ) ;}

Acces 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

i m p o r t com . mongodb . Mongo ;i m p o r t com . mongodb .DB;i m p o r t com . mongodb . D B C o l l e c t i o n ;i m p o r t com . mongodb . BasicDBObject ;i m p o r t com . mongodb . DBObject ;i m p o r t com . mongodb . DBCursor ;

Mongo m = new Mongo ( ) ;// orMongo m = new Mongo ( ” l o c a l h o s t ” ) ;// orMongo 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) :

BasicDBObject doc = new BasicDBObject ( ) ;

doc . put ( ”name” , ”MongoDB” ) ;doc . put ( ” t y p e ” , ” d a t a b a s e ” ) ;doc . put ( ” count ” , 1 ) ;

Bas icDBObject i n f o = new BasicDBObject ( ) ;

i n f o . put ( ” x ” , 2 0 3 ) ;i n f o . put ( ” y ” , 1 0 2 ) ;

doc . put ( ” 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

Requetes :

// get f i r s t documentDBObject doc = c o l l e c t i o n . f indOne ( ) ;System . out . p r i n t l n ( dbObject ) ;

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 . out . p r i n t l n ( c u r s o r . next ( ) ) ;}

BasicDBObject q u e r y = new BasicDBObject ( ) ;q u e r y . put ( ”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 ) ;w h i l e ( c u r s o r . hasNext ( ) ) {

System . out . p r i n t l n ( c u r s o r . next ( ) ) ;}

76/83

MongoDB en Java

MongoDB en Java

Requetes :

BasicDBObject q u e r y = new BasicDBObject ( ) ;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 . put ( ”number” , new BasicDBObject ( ” $ i n ” , l i s t ) ) ;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 ) ;w h i l e ( c u r s o r . hasNext ( ) ) {

System . out . p r i n t l n ( c u r s o r . next ( ) ) ;}

77/83

MongoDB en Java

MongoDB en Java

Requetes :

BasicDBObject q u e r y = new BasicDBObject ( ) ;q u e r y . put ( ”number” ,

new BasicDBObject ( ” $gt ” , 5 ) . append ( ” $ l t ” , 8 ) ) ;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 ) ;w h i l e ( c u r s o r . hasNext ( ) ) {

System . out . p r i n t l n ( c u r s o r . next ( ) ) ;}

Creation d’un index :

// c r e a t e i n d e x on ” i ” , a s c e n d i n gc o l l . c r e a t e I n d e x ( new BasicDBObject ( ” i ” , 1 ) ) ;

78/83

MongoDB en Java

MongoDB : MapReduce

db . runCommand ({ mapreduce : <c o l l e c t i o n >,

map : <mapfunct ion >,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 emit 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 to r e t u r n from c o l l e c t i o n >][ , out : <s e e output 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 cope : <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 scope >][ , jsMode : t r u e ][ , v e r b o s e : t r u e ]

}) ;

79/83

MongoDB en Java

MapReduce : exempleCollection 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 photo ! ” }

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} ;v a l u e s . f o r E a c h ( f u n c t i o n ( v a l u e ) {

r e s u l t . count += v a l u e . count ;r e s u l t . l i k e s += v a l u e . l i k e s ;

} ) ;r e t u r n r e s u l t ;

Fonction Map :

f u n c t i o n ( ) {emit ( t h i s . username ,{count : 1 , l i k e s : t h i s . l i k e s } ) ; }

}

MapReduce incrementalMap/shuffle : [(C ,V )]→ [(C ′, [V ′])]Reduce : [(C ′, [V ′])]→ [(C ′,V ′)]

80/83

MongoDB en Java

MonoDB : Sharding

Notions :

shard : traitement de requetes (query, maj) sur un fragmentde collection (identifie par shardkey)

mongos : routage de requetes

config server : surveillance des shards (metadonnees)

81/83

MongoDB en Java

Conclusion

On a besoin de SQL et de NoSQL

NoSQL = not only SQLPrincipe CAP

Importance de noSQL

Analyse de donneesPassage a l’echelleParallelisation / partionnement verticale

82/83

MongoDB en Java

ConclusionLes SGBDR en font trop, alors que les produits NoSQLfont exactement ce dont vous avez besoin (Travis, 2009)

Gestion des BD geantes des sites web de tres grande audienceExemple des SGBD d’annuaires : grande majorite des acces aux BDconsistent en lectures sans modification (ainsi, seule la persistancedoit etre verifiee)

� Consensus � actuel :

Les SGBD NoSQL ne replacent pas les SGBDR mais les completenten palliant leurs faiblesses

A venir :

UnQL (Unstructured Query Language)2011 : debut d’une specification d’un langage de manipulationstandardise (pour formaliser le requetage des collections des BDNoSQL)

83/83