BigData& Bases NoSQL - Chewbii.com...formation Ontologie id Nicolas Régis Luc Céline Nicolas NoSQL...

Introduction aux NoSQL

Nicolas - TraversDépartement Informatique [email protected]

BigData & Bases NoSQLNicolas Travers

1



Plan

I. Contextea. Les 3V et le Décisionnelb. Limites des SGBDRc. ACID vs BASE

II.NoSQLa.Distributionb.Les 4 famillesc. Théorème de CAPd.Map/Reduce

III.NoSQL vs JointuresIV.Modélisation avec JSon

2



Contexte

• Croissance de la quantité des données exponentielle

3



Contexte (2)

• La quantité de données digitales produites double tous les 2 ans. • En d'autres termes, on a produit autant de données digitales ces 2

dernières années que tout ce qui a été produit auparavant.

4



Volume et Variété

5



Décisionnel : ancienne méthode

6



Décisionnel vs 3V• L’approche classique incompatible avec les 3V du BigData :

• Le Volume: les entrepôts sont conçus pour gérer des Go ou To de données alors que la croissance exponentielle des données nous conduit aux Po ou Eo

• Le type (Variety): le nombre de types, incluant les données textuelles semi ou non structurées, augmente

• La vitesse (Velocity): les données sont créées de plus en plus vite et nécessitent des traitements en temps-réel

7



Compagnies Données traitées (2014)

Données stockées (2014)

Google 100 Po 15 000 Po

Ebay 100 Po 90 Po

Facebook 600 To 300 Po

Twitter 100 To 100 To

Baidu 10-100 Po 2 000 Po

NSA 29 Po 10 000 Po

Contexte (3) : encore des chiffres

8



Contexte : et le business• On estime que le volume de données

professionnelles double tous les 1,2 ans

• Les ¾ des décideurs estiment que les Big Data vont affecter significativementleurs systèmes de stockage

• Le Big Data serait un marché à 50 milliards de $ en 2017

• En Europe, l'utilisation du Big Data pour améliorer l'efficacité des “traitements” permettrait d'économiser100 milliards de $ 9



Contexte : Conséquences

• Les volumes à gérer sans précédents impliquent :• Données hétérogènes, complexes et souvent liées

• produites par des applications parfois différentes,• par des utilisateurs différents,• avec des liens explicites (par exemple citations, ancres url, etc) ou implicites (à extraire ou à

apprendre)

• Nombreux serveurs/clusters• un serveur unique ne peut stocker cette quantité d'information, garantir des temps d'accès

pour grand nombre d'utilisateur, faire des calculs rapides, etc

• Besoin de distribuer les calculs et les données• comme plusieurs serveurs/clusters, besoin d'algorithmes permettant le calcul et la distribution

des données à large échelle

10



DataCenters

• Data centers de quelques grands acteurs du Big Data• Google DataCenter : 70000 servers/data center et 16 data centers, ~1M de serveurs• Facebook : 5 data centers• Amazon : 7 data centers, 450 000 severs• Microsoft : ~1M serveurs

11



Big Data : Exemples d’utilisation

• Décodage du génôme humain: le génôme d’une personne (env. 100Go) décodé en 30mns

• Prédiction des résultats des élections US en 2012 à partir de l’analyse de tweets

• Découverte d’un effet secondaire dû à la prise de deux médicaments par analyse des requêtes d’internautes (Yahoo)

• Étude des déplacements de population (migration, tourisme, circulation urbaine, etc)

12



NoSQL ne remplace pas les SGBDR

13



SGBDR vs Distribution

• Fonctionnalités▫ Jointures entre les tables▫ Langage d’interrogation riche▫ Contraintes d’intégrité solides

• Limites dans le contexte distribué :• Comment distribuer/partitionner les données▫ Liens entre entités -> Même serveur▫ Mais plus on a de liens, plus le placement des données est complexe

14



SGBDR vs Distribution

• Propriétés ACID pour les transactions• Atomicité : une transaction s’effectue

entièrement ou pas du tout• Cohérence : le contenu d’une base doit être

cohérent au début et à la fin d’une transaction• Isolation : les modifications d’une transaction

ne sont visibles/modifiables que quand celle-ci a validé

• Durabilité : une fois la transaction validée, l’étatde la base est permanent (non affecté par les pannes ou autre)

• Systèmes distribués : modèle BASE• Basically Available : garantie minimale pour

taux de disponibilité face grande quantité de requêtes

• Soft-state : l’état du système peut changer au cours du temps même sans nouveaux inputs (cela est du au modèle de consistance).

• Eventually consistent : tous les réplicas atteignent le même état, et le système devient à un moment consistant, si on stoppe les inputs

15

ACID vs BASE

0 141 2 3 4 5 6 7 8 9 10 11 12 13

ACID BASEAtomicityConsistencyIsolationDurability

Basically AvailableSoft-StateEventually Consistent

NoSQLSGBDR VS



NoSQL : une solution

• NoSQL : Not Only SQL• Nouvelle approche de stockage et de gestion de données• Permet le passage à l’échelle via un contexte hautement distribué• Gestion de données complexes et hétérogènes

� Pas de schéma pour les objets

• Ne remplace pas les SGBDR !!• Quantité de données énorme (PétaBytes)• Besoin de temps de réponse• Cohérence de données faible

16



Les bases de données NoSQL

17



BD NoSQL : Caractéristiques

• Pas de relations• Pas de schéma physiques ou dynamiques• Notion de “collections”

• Données éventuellement complexes• Imbrication, tableaux

• Distribution de données (milliers de serveurs)• Parallélisation des traitements (Map/Reduce)

• Replication des données• Disponibilité vs Cohérence (pas de transactions)• Peu d’écritures, beaucoup de lectures

18



Sharding : Passage à l’échelle

• Distribution des blocs de données sur un ensemble de serveurs• Partitionnement horizontal• Trois types de techniques :

1. Basée sur l’allocation de ressources : HDFS2. Basée sur une structure arborescente : Index non-dense3. Basée sur le hachage : Hachage Cohérent

19



Sharding : HDFS

• HDFS1

• Système de fichier distribué• Dépend de la charge des serveurs• Distribution, tolérance aux pannes• Allocation dynamique et optimisée

20

Allocation de ressources

(1) Voir cours sur Hadoop Distributed File System http://chewbii.com/transparents-hdfs-hadoop/



Sharding : HDFS

21

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

NameNode

DataNode

DataNodeRack Rack

DataNode

DataNode

DataNode

DataNode

DataNode

DataNodeRack

DataNode

NameNode

DataNode

DataNode

switch

switch

switch

Rack Rack

DataNode

DataNode

DataNode

DataNodeChunk 3

DataNode

DataNodeRack

DataNode

NameNode

Chunk 1

DataNodeChunk 4

DataNode

Chunk 2

Chunk 5

Chunk 6

switch

switch

switch

Rack Rack

DataNode

DataNode

DataNode

DataNodeChunk 3

DataNode

DataNodeRack

DataNode

NameNode

Chunk 1 Chunk 2

DataNodeChunk 4

Chunk 5DataNode

Chunk 2

Chunk 1 Chunk 3Chunk 4

Chunk 6Chunk 5

Chunk 6

switch

switch

switch

Rack Rack

DataNode

DataNode

DataNode

DataNodeChunk 3

DataNode

DataNodeRack

DataNode

NameNode

Chunk 1 Chunk 2

DataNode

Chunk 5

Chunk 4Chunk 1

Chunk 2

Chunk 3

Chunk 5DataNode

Chunk 2

Chunk 1 Chunk 3

Chunk 4

Chunk 4

Chunk 6Chunk 5

Chunk 6

Chunk 6

switch

switch

switch

Rack Rack

DataNode

DataNode

DataNode

DataNodeChunk 3

DataNode

DataNodeRack

DataNode

NameNode

Chunk 1

Secondary NameNode

Chunk 2

DataNode

Chunk 5

Chunk 4Chunk 1

Chunk 2

Chunk 3

Chunk 5DataNode

Chunk 2

Chunk 1 Chunk 3

Chunk 4

Chunk 4

Chunk 6Chunk 5

Chunk 6

Chunk 6

switch

switch

switch

Exemple



Distribution de calcul Tolérance aux pannes

Sharding : HDFS

22

Solutions



Sharding : Clustered index

• Index non-dense2 distribué • Données triées physiquement

• Découpées en blocs sur les nœuds (souvent 256Mo)• Distribution, tolérance�Requêtes par intervalles / regroupement⚠ Bien choisir la clé pour le tri

23

Technique arborescente

(2) Voir cours sur index dense vs non-dense http://chewbii.com/videos-optimisation-bases-de-donnees/ (Vidéo 4)




24

Exemple

Chunk-inf -> 10 000

Chunk10 001 -> 20 000

Chunk20 001 -> 30 000

Chunk30 001 -> 40 000

Chunk40 001 -> 50 000

Chunk50 001 -> 60 000

Chunk60 001 -> 70 000

Chunk70 001 -> 80 000

Chunk80 001 —> inf

Noeud

Chunk-inf -> 10 000

Chunk10 001 -> 20 000

Chunk20 001 -> 30 000

Chunk30 001 -> 40 000

Chunk40 001 -> 50 000

Chunk50 001 -> 60 000

Chunk60 001 -> 70 000

Chunk70 001 -> 80 000


Noeud Noeud Noeud NoeudNoeud + réplicas

Chunk-inf -> 10 000

Chunk10 001 -> 20 000

Chunk20 001 -> 30 000

Chunk30 001 -> 40 000

Chunk40 001 -> 50 000

Chunk50 001 -> 60 000

Chunk60 001 -> 70 000

Chunk70 001 -> 80 000


Noeud + réplicas Noeud + réplicas Noeud + réplicas Noeud + répl.Noeud + réplicas

Feuille-inf -> 30 000

Feuille60 001 -> +inf

Feuille30 001 -> 60 000

Chunk-inf -> 10 000

Chunk10 001 -> 20 000

Chunk20 001 -> 30 000

Chunk30 001 -> 40 000

Chunk40 001 -> 50 000

Chunk50 001 -> 60 000

Chunk60 001 -> 70 000

Chunk70 001 -> 80 000



Racine



Feuille30 001 -> 60 000

Chunk-inf -> 10 000

Chunk10 001 -> 20 000

Chunk20 001 -> 30 000

Chunk30 001 -> 40 000

Chunk40 001 -> 50 000

Chunk50 001 -> 60 000

Chunk60 001 -> 70 000

Chunk70 001 -> 80 000



RouteurRacine



Feuille30 001 -> 60 000

Chunk-inf -> 10 000

Chunk10 001 -> 20 000

Chunk20 001 -> 30 000

Chunk30 001 -> 40 000

Chunk40 001 -> 50 000

Chunk50 001 -> 60 000

Chunk60 001 -> 70 000

Chunk70 001 -> 80 000



Routeur x3Racine



Feuille30 001 -> 60 000

Chunk-inf -> 10 000

Chunk10 001 -> 20 000

Chunk20 001 -> 30 000

Chunk30 001 -> 40 000

Chunk40 001 -> 50 000

Chunk50 001 -> 60 000

Chunk60 001 -> 70 000

Chunk70 001 -> 80 000


Noeud + réplicas Noeud + réplicas Noeud + réplicas Noeud + répl.



Regroupement Dynamicité


25

Solutions



Sharding : Consistent Hashing

• Hachage cohérent (DHT3)• Technique de hachage unique et dynamique pour les données et les serveurs• Distribution en anneau (virtuel)• Pas de serveur centralisé (tout est client/serveur)• Autonomie de gestion

26

Une table de hachage distribuée

(3) Voir cours sur DHT http://chewbii.com/hachagedynamique/ (Vidéo 4 & 5)




27

Exemple0 = 264 = 4 x 262

262

263 = 2 x 262

3 x 262

0 = 264 = 4 x 262

Portion du

serveur S1

Portion duserveur S2

Portion du serveur S3

Port

ion

duse

rveu

r S4

Portion du

serveur S5

S3

S4

S5

S1

S2

262

263 = 2 x 262

3 x 262

0 = 264 = 4 x 262

Portion du

serveur S1



Port

ion

duse

rveu

r S4

Portion du

serveur S5

S3

S4

S5

S1

S2

262

263 = 2 x 262

3 x 262

d1

d2

d3

d4

d5

d6

d7

0 = 264 = 4 x 262

Portion du

serveur S1



Port

ion

duse

rveu

r S4

Portion du

serveur S5

S3

S4

S5

S1

S2

262

263 = 2 x 262

3 x 262

d1

d2

d3

d4

d5

d6 Chunk S1d1

d5 d2 d4réplicas

resp

Chunk S2d5 d2

d4réplicas

resp

d3

Chunk S3d4

réplicas

resp

d3 d6

d7

d7

Chunk S4d3

réplicas

resp

d6 d1

Chunk S5d6

réplicas

resp

d1 d5 d2

d7

d7

0 = 264 = 4 x 262

Portion du

serveur S1



Port

ion

duse

rveu

r S4

Portion du

serveur S5

S3

S4

S5

S1

S2

262

263 = 2 x 262

3 x 262

d1

d2

d3

d4

d5

d6 Chunk S1d1

d5 d2 d4réplicas

resp

Chunk S2d5 d2

d4réplicas

resp

d3

Chunk S3d4

réplicas

resp

d3 d6

d7

d7

Chunk S4d3

réplicas

resp

d6 d1

Chunk S5d6

réplicas

resp

d1 d5 d2

d7

d7

0 = 264 = 4 x 262d3 ?

Portion du

serveur S1



Port

ion

duse

rveu

r S4

Portion du

serveur S5

S3

S4

S5

S1

S2

262

263 = 2 x 262

3 x 262

d1

d2

d3

d4

d5

d6 Chunk S1d1

d5 d2 d4réplicas

resp

Chunk S2d5 d2

d4réplicas

resp

d3

Chunk S3d4

réplicas

resp

d3 d6

d7

d7

Chunk S4d3

réplicas

resp

d6 d1

Chunk S5d6

réplicas

resp

d1 d5 d2

d7

d7

0 = 264 = 4 x 262d3 ?

Portion du

serveur S1



Port

ion

duse

rveu

r S4

Portion du

serveur S5

S3

S4

S5

S1

S2

262

263 = 2 x 262

3 x 262

d1

d2

d3

d4

d5

d6 Chunk S1d1

d5 d2 d4réplicas

resp

Chunk S2d5 d2

d4réplicas

resp

d3

Chunk S3d4

réplicas

resp

d3 d6

d7

d7

Chunk S4d3

réplicas

resp

d6 d1

Chunk S5d6

réplicas

resp

d1 d5 d2

d7

d7

0 = 264 = 4 x 262d3 ?



Elasticité Auto-gestion


28

solutions



NoSQL : une grande famille

29

4 famillestype lieu spec intérêts

prof CNAM BDD, NoSQL BZH, Star Wars

OC Machine Learning, Dev escalade, nouilles chinoises

resp formation OC OC formation, audiovisuel

prof CentraleSupelec Ontologie, logique formelle, visualisation

id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas

nouilles chinoisesRégis

Stockage orienté lignes Stockage orienté colonnes

Nicolas Régis Luc Céline

{ "_id": "Nicolas", "type": "prof", "lieu": { "nom": "CNAM", "adresse":"rue saint martin", "ville": "Paris" }, "spec": ["BDD","NoSQL"], "intérêts": ["BZH", "Star Wars"]}

clés

documents

{ "_id": "Régis", "lieu": { "nom": "OC", "adresse":"rue cité Paris", "ville": "Paris" }, "spec": ["Machine Learning", "dev"], "intérêts": ["escalade", "nouilles"]}

{ "_id": "Luc", "type": "resp formation OC", "lieu": { "nom": "OC", "adresse":"rue cité Paris", "ville": "Paris" }, "spec": ["formation", "audiovisuelle"]}

{ "_id": "Céline", "type": "prof", "lieu": { "nom": "CentraleSupelec", "adresse":"rue Joliot-Cury", "ville": "Gif-sur-Yvette » }, "spec": ["Ontologie", "Logique formelle", "Visualisation"]}

Nicolastype:prof

RégisLuc

type:resp formation

Célinetype:prof

CNAMadresse:…

OCadresse:…

CentraleSupélec

employeur

employeur

employeur

vacation

Paris Gif-sur-Yvette

siège social siège social siège social

vacation employeur

vacation

vacation


type: proflieu: CNAM

spec: BDD,NoSQLintérêts: BZH, Star Wars

lieu: OCspec: Machine Learning, devintérêts: escalade, nouilles

chinoises

type: resp formation OClieu: OC

spec: formation, audiovisuel

type: proflieu: CentraleSupelec

spec: Ontologie, logique formelle, visualisation

clés

valeurs

Clés-Valeurs

Orienté colonnes

Orienté documents Orienté graphes



I - NoSQL & Clé-Valeurs

•“HashMap” distribué•Couple Clé+Valeur▫ Pas de schéma pour la valeur (chaine, objet, entier, binaires…) qui peut donc

être différente pour chaque•Conséquences▫ Pas de structure ni de types▫ Pas d’expressivité d’interrogation (pré/post traitement pour manipuler

concrètement les données)

30




31

Exempletype lieu spec intérêts





id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas







chinoises





clés

valeurs





chinoises





clés

valeurs





chinoises





clés

valeurs





chinoises





clés

valeurs





chinoises





clés

valeurs

Relationnel




• CRUD▫ CREATE ( clé, valeur )

� CREATE ("Nicolas", "type:'prof',lieu:'CNAM',spec:'BDD,NoSQL',interets:'BZH,Star Wars' ") à OK▫ READ( clé )

� READ("Nicolas") à "type:'prof',lieu:'CNAM',spec:'BDD,NoSQL',interets:'BZH,Star Wars' "▫ UPDATE( clé, valeur )

� UPDATE("Nicolas", "type:'prof',lieu:'CNAM,CS',spec:'BDD,NoSQL' ") à OK▫ DELETE( clé )

� DELETE("Nicolas") à OK

32

interrogation





chinoises





clés

valeurs





chinoises





clés

valeurs



Efficacité Facilité de mise en œuvre


33

solutions




• Exemples d’utilisation:

• Logs de sites Web ou d’application

• Profils utilisateurs de site Web/réseaux sociaux

• Données de capteurs

• Cache Web ou BD

• Paniers sur sites de e-commerce

• …

34

applications



II - NoSQL & Colonnes

•Stockage des données par colonnes▫ SGBD : tuples (lignes)

•Facile d’ajouter une colonne (pas une ligne!)▫ Schéma peut être dynamique (d’un tuple à l’autre)

35




36

exemple

type lieu spec intérêts





id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas






• Requêtes sur les colonnes▫ Combien de professeurs (type) à

CentraleSupelec (lieu)

37

interrogation






id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas





Agrégations Corrélations


38

solutions





• Comptage (vote en ligne, compteur, etc)

• Journalisation

• Recherche de produits dans une catégorie (Ebay)

• Reporting large échelle (agrégats calculés sur une colonne)

39

applications



III - NoSQL & Documents

• Basé sur le modèle clé-valeur▫ Ajout de données semi-structurées (JSon ou XML)▫ Idem que “clé-valeur” mais “valeur = document”▫ Document composé de clés/valeurs▫ Types simples (Int, String, Date)▫ Schéma non nécessaire (peut varier d’un document à l’autre)▫ Imbrication de données (schéma arborescent)▫ Listes de valeurs

• Requêtes : Interface HTTP▫ Plus complexe que CRUD▫ Chaque clé du document peut être interrogée

40




41

exemple type lieu spec intérêts





id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas





clés

documents






clés

documents






clés

documents






clés

documents






clés

documents








clés

documents






clés

documents






clés

documents






clés

documents






clés

documents





• Requêtes sur le contenu des documents▫ Etablissement (lieu.nom) des professeurs (type) spécialisé en BDD (in spec)

42

interrogation



Requêtes riches Gestion d'objets


43

solutions





• Gestion de contenu: bibliothèques numériques, collections de produits, dépôts de logiciels « xxxStores », collections multimédia, etc

• Collection d’événements complexes

• Gestion de boîtes email

• Gestion des historiques d’utilisateurs sur réseaux sociaux

44

applications



IV - NoSQL & Graph

•Stockage des noeuds, relations et propriétés▫ Théorie des graphes▫ Interrogation par traversées de graphe▫ Appel des données sur demande (parcours performants)▫ Modélisation non triviale

45








id

Nicolas

Régis

Luc

Céline

type

prof

resp formation

OC

prof

id

Nicolas

Luc

Céline

lieu

CNAM

OC

OC

CentraleSupelec

id

Nicolas

Régis

Luc

Céline

spec

BDD

Machine Learning

formation

Ontologie

id

Nicolas

Régis

Luc

Céline

NoSQLNicolas

Dev

Régis

audiovisuelLuc

logique formelle

visualisation

Céline

Céline

intérêts

BZH

escalade

id

Nicolas

Régis

Star WarsNicolas



Nicolas RégisLuc CélineNicolas

type:profRégis

Luctype:resp formation

Célinetype:prof

Nicolastype:prof

RégisLuc

type:resp formation

Célinetype:prof

CNAMadresse:…

OCadresse:…

CentraleSupélec

Nicolastype:prof

RégisLuc

type:resp formation

Célinetype:prof

CNAMadresse:…

OCadresse:…

CentraleSupélec

employeur

employeur

employeur employeur

Nicolastype:prof

RégisLuc

type:resp formation

Célinetype:prof

CNAMadresse:…

OCadresse:…

CentraleSupélec

employeur

employeur

employeur

vacation

vacation employeur

vacation

vacation

Nicolastype:prof

RégisLuc

type:resp formation

Célinetype:prof

CNAMadresse:…

OCadresse:…

CentraleSupélec

employeur

employeur

employeur

vacation


vacation employeur

vacation

vacation

Nicolastype:prof

RégisLuc

type:resp formation

Célinetype:prof

CNAMadresse:…

OCadresse:…

CentraleSupélec

employeur

employeur

employeur

vacation



vacation employeur

vacation

vacation

IV - NoSQL & Graph

46

exemple



Nicolastype:prof

RégisLuc

type:resp formation

Célinetype:prof

CNAMadresse:…

OCadresse:…

CentraleSupélec

employeur

employeur

employeur

vacation



vacation employeur

vacation

vacation

IV - NoSQL & Graph

• Requêtes sur les graphes▫ Personnes faisant des vacations à Paris et à Gif-sur-Yvette

47

interrogation



FlockDB

Réseaux Recommandation

IV - NoSQL & Graph

48

solutions



IV - NoSQL & Graph

• Exemples d’applications:

• Calcul sur les graphes sociaux (recommandations, plus courts chemins, atteignabilité,…)

• Calculs sur les réseaux des SIG: réseaux routiers, canalisations, électricité, …

• Web social (linked data)

49

applications



DB-Engines

50



“Théorème de CAP”•Théorème de Brewer (2000) •3 propriétés fondamentales pour les systèmesdistribués

1.Consistency: Tous les serveurs voient la mêmedonnée (valeur) en même temps (ou Cohérence)2.Availability: Si un serveur tombe en panne, les données restent disponibles3.Partition Tolerance: Le système même partitionnédoit répondre correctement à toute requête (sauf en casde panne réseau)

Théorème : “Dans un système distribué, il estimpossible que ces 3 propriétés co-existent, vous devez choisir 2 d’entre elles”.

51

ConsistencyCohérence

AvailabilityDisponibilité

Partition ToleranceDistribution

CA AP

CP



CACohérence + Disponibilité

CPCohérence + Distribution

APDisponibilité + Distribution

v1 v1 v1 v1v1

écriture




v2v1 v1 v1 v1v1

L1écriture L2




v2v1 v1 v1 v1v1

v2 v2L1écriture L2




v2v1 v1 v1 v1v1

L1écriture L2 écriture




v2v1 v2v1 v1 v1v1

L1écriture L2 L1écriture L2




v2v1 v2v1 v1 v1v1





v2v1 v2v1 v1 v1v1

attenteL1écriture L2 L1écriture L2




synchrone

v2v1 v2v1 v2v1 v1v1

attente

ack





synchrone

v2v1 v2v1 v2v1 v1v1

v2 v2L1écriture L2 L1écriture L2




synchrone

v2v1 v2v1 v2v1 v1v1





synchrone

écriture

v2v1 v2v1 v2v1 v2v1 v1





synchrone

L1écriture L2






synchrone

L1écriture L2

asynchrone






synchrone

L1écriture L2

asynchrone

v2v1 v2v1 v2v1 v2v1 v2v1

v2 v1

“Théorème de CAP”

52

illustration



Availability(Disponibilité)

Consistency(Cohérence)

Partition tolerance(Distribution)

RelationnelOrienté Clé-ValeurOrienté ColonneOrienté DocumentOrienté Graphe

Modèle





OracleMySQL

SQLServer

DB2PostgreSQL

Modèle





RedisMemcached

CosmosDB

SimpleDB OracleMySQL

SQLServer

DB2PostgreSQL

Modèle





RedisMemcached

CosmosDB

SimpleDB

BigTableHBase

ElasticsearchSpark

OracleMySQL

SQLServer

DB2PostgreSQL

Modèle





MongoDB

RedisMemcached

CosmosDB

SimpleDB

BigTableHBase

ElasticsearchSpark

OracleMySQL

SQLServer

DB2PostgreSQL

CouchBase DynamoDB

Cassandra

Modèle





MongoDB

RedisMemcached

CosmosDB

SimpleDB

BigTableHBase

ElasticsearchSpark

OracleMySQL

SQLServer

DB2PostgreSQL

CouchBase DynamoDB

Cassandra

Neo4jOrientDBFlockDB

Modèle





MongoDB*

RedisMemcached*

CosmosDB*

SimpleDB*

BigTableHBase

ElasticsearchSpark

OracleMySQL

SQLServer

DB2PostgreSQL

CouchBase*DynamoDB*

Cassandra*

Neo4jOrientDBFlockDB

* Possibilité de changer le mode de cohérence

Cohérence <-> Disponibilité

Modèle

“Théorème de CAP”

53

Triangle de CAP



Map/Reduce (résumé)

• Framework de calcul distribué• Programme décomposé en 2 fonctions

• Map : transformation de données• Entrée : une donnée• Sortie : un ensemble de pairs - clé + valeur

• Reduce : agrège par clé un ensemble de valeurs• Entrée : liste de valeurs d’une clé - clé + liste(valeurs)• Sortie : une valeur - clé + valeur

• Passage à l’échelle et Tolérance aux pannes• Envoyé à tous les serveurs, appliquée à chaque donnée• Reprise de traitements en cas de panne

54



Map/Reduce : Principe

55



Conclusion

•NoSQL▫ Dédié à un contexte extrêmement distribué▫ Calcul fortement distribué▫ 4 types de calculs complexes(clé-valeur, document, colonnes, graphes)▫ Théorème de CAP

•Ne doit pas remplacer automatiquement un SGBD▫ Propriétés ACID▫ Requêtes complexes▫ Performance de jointure

56

BigData& Bases NoSQL - Chewbii.com...formation Ontologie id Nicolas Régis Luc Céline Nicolas NoSQL...

Documents

Transcript of BigData& Bases NoSQL - Chewbii.com...formation Ontologie id Nicolas Régis Luc Céline Nicolas NoSQL...