Chapitre 3: Big Data: Nosql

Chapitre 3
Big data : NoSQL
Big Data – 3TEL ENIT – Novembre 2017

Web analytics application
Tracks the number of pageviews for any URL a customer wishes to

track.
Pageview The customer’s web page pings the application’s web
server with its URL.
Additionally, shows Top 100 URLs.
Solution:
RDBMS with a table
Each ping  Increment in the DB Column name Type
Id integer
user_id integer
url varchar(255)
pageviews bigint
Big Data – 3TEL 2 ENIT – Novembre 2017

Problems !
Timeout error on inserting to the database
Solution: Scaling with a queue
Create a worker process
reads 100 events at a time

off the queue
and batches them into a
single database update

Problem, again!
The application is getting more and more popular
Again the database gets overloaded
The worker can’t keep up with the writes
Add more workers to parallelize the updates.
Unfortunately that doesn’t help

The database is the bottleneck.

Scaling by sharding the database
Horizontal partitioning or Sharding

spreads the write load across multiple machines
Fault-tolerance issues
the disk on one of the database machines goes bad
update the queue system to put increments for unavailable shards on a
separate “pending” queue
use the database’s replication capabilities to add a slave to each shard
(backup in case the master goes down)
don’t write to the slave, but at least we can read (consistency issues)

Big Data to the rescue
Databases and computation systems aware of their distributed nature.

sharding and replication are handled for you
easy horizontal scalability
Make data immutable

Instead of storing the pageview counts
store the raw pageview information (never modified)
in case of mistake, you might write bad data, but at least you won’t
destroy good data.
human-fault tolerance guarantee

SGBD traditionnel
Un système de gestion de base de données (SGBD) fournit à une

application l’accès et le stockage :
efficaces
fiables,
pratiques
sécurisés
multi-utilisateur
à des quantités massives de données persistantes
Tout problème d'analyse (ou de gestion) de données est mieux résolu

en utilisant un SGBD traditionnel ? (un SGBD est-il la meilleure solution
dans tous les cas ?)

Pourquoi le NoSQL ?
Big data
Scalabilité
Format de données
Maniablilité

Big Data
Collecter
Stocker
Organizer
Analyzer
Partager
La croissance des données surpasse la capacité de

gestion
nous avons besoin de solutions scalables

NoSQL : signification
▪ “SQL” = SGBD relationnel traditionnel

▪ Constat depuis une dizaine d’années :
▪ Certains problèmes d'analyse (ou de gestion)
de données peuvent être mieux résolus en
utilisant un SGBD non traditionnel
▪ “NoSQL” = Non SQL = Not using SQL

▪ “NoSQL” = “Not Only SQL”

Bases de données NoSQL
Synonyme de Not Only SQL
Caractéristiques communes :
non-relationnelles
habituellement ne nécessitent pas de fixer un
schéma de table
scalablité horizontale
généralement open source

D’autres cractéristiques
Relaxer une ou plusieur propriétés ACID
 Atomicité
– une transaction se fait au complet ou pas du tout
Cohérence
– une transaction amène le système d'un état valide à un
autre état valide
Isolation
– toute transaction doit s'exécuter comme si elle était la
seule sur le système
Durabilité
– les résultats doivent être enregistrés de façon permanente
Supporter la réplication
Offre une API simple

Ne supporte pas la totalité des caractéristiques des BD

relationnelles
pas d’opérations de jointures (sauf dans les
partitions),
pas de contraintes d'intégrité référentielle entre les
partitions.

Exemple 1 : Analyse de Web log
▪ Analyser le fichier log d’un serveur Web
Entrée : UserID, URL, timestamp, info-

additionnelles
Tâche : trouver tous les enregistrements pour …

▪ un UserID donné
▪ une URL donnée
▪ un timestamp donné
▪ Quelques concepts qui apparaissent dans info-additionnelles

Exemple 1 : Analyse de Web log
Entrée : UserID, URL, timestamp, info-
additionnelles
Sotrie: UserID, nom, age, genre, …
Tâche : Trouver la moyenne d’âge des

utilsateurs qui ont accédé à une URL donnée

Exemple 2 : graphe social
Entrée : UserID1, UserID2

Sortie : UserID, nom, age, genre etc
Tâche : Trouver tousles amis des amis des
amis des … amis d’un utilisateur donné

Exemple 3 : Pages de Blog
Large collection de documents

Combinaison de données structurées et non
structurées
Tâche : Extraire les paragraphes de texte et
les images

Efforts programmation/gestion BD
Alternative aux SGBD relationnels

+ Schéma flexible
+ Plus rapide te moins coûteux à mettre en oeuvre
+ Scalabilité massive
+ Contrainte de cohérence relaxée  meilleures
performances et disponibilité
– Pas de langage de requête déclaratif  beaucoup

de programmation
– Contrainte de cohérence relaxée  moins de
garanties

Challenge: Coordination
La solution à la disponibilité et à la scalabilité est de
décentraliser et répliquer
les données et les fonctions
Problèmes reliés à la coordination des nœuds
cohérence des données
propagation de la m.à.j
exclusion mutuelles
communication
ordre des événements
consensus distribué

Théorème CAP
Consistency : Cohérence
Dans un système distribué
si on écrit une donnée dans un nœud A
et, on lit la même donnée depuis un nœud B
le résultat de doit être ce qu’on a écrit sur le nœud A
Availability : Disponibilité
Chaque nœud du système distribué doit répondre à la requête
sauf si, il est en panne
Partition-Tolerence : Tolérance au Partitionnement

Assurer que les opérations d’écriture et de lecture sont redirigées vers les
répliques disponibles quand les segments du réseau deviennent
déconnectés

Théorème CAP
Consistency
Fox&Brewer 2000
C Cohérence
“CAP Theorem”:
C-A-P: choisir 2
CP: Toujours cohérente, même
dans une partition.
Stipule : chaque système Mais une réplique accessible
distribué est sur un côté peut refuser le service sans
du triangle l'accord des autres (ex. quorum)
AP: a reachable replica provides

service even in a partition, but may be
inconsistent if there is a failure.
A AP : une réplique accessible offre P

Availability un service, de même dans une
partition. Mais peut être incohérent Partition-Tolerence
Disponibilité si il y a une panne d’un noeud.

Théorème CAP
Soient 3 propriétés d’un système
Cohérence (toutes les copies ont les mêmes valeurs)
Availability : disponibilité (le fonctionnement du système
continue même si des noeuds sont en panne)
Partitions (réseau peut se rompre en deux ou plusieurs parties,
chacune avec des systèmes actifs qui ne peuvent pas influencer
les autres parties)
Brewer’s CAP “Theorem”: for any system sharing
data it is impossible to guarantee simultaneously all
of these three properties
Pour tout système partageant des données, il est
impossible de garantir simultanément ces trois
propriétés

Théorème CAP
Big Data  on doit partitionner les données
Il est nécessaire de décider entre C et A
SGBD traditional préfére C à A et P
La plus part des applications Web choisissent A (excepté pour
des applications spécifiques comme le traitement des
commandes)
Abandonner A ou C de ACID
relaxer C rend la replication facile, facilitater la tolerance aux
fautes,
relaxer A réduit (ou élimine) la nécessité de contrôle de la
concurrence distribuée.

Catégories de BD NoSQL

Catégories de BD NoSQL
Base de données clé / valeur
Key-value stores
Base de données document
Document-based
Base de données colonnes
Column NoSQL databases
Base de données graphes
Graph database
Base de données XML
XML databases
BD clé / valeur
Modèle de données : paires (clé, valeur)
associer un identifiant unique à chaque valeur dans la BD
valeur de type simple/objet sérialisé
Opérations :
Insert(clé, valeur), Fetch(clé), Update(clé), Delete(clé)
création, lecture, modification, suppression
Implémentation :
efficacité, scalabilité, tolérance aux fautes, réplication
enregistrements distribuées sur les nœuds selon leurs clés
Contarainte de cohérence relaxée (assurée par l’application)
L’intelligence de la manipulation des données se situe
dans l’applicatif client
SimpleDB : BD clé / valeur
Modèle de données
Domaine
 Item
– Nom
» attributs
Tout est chaine de caractères
Opérations conditionnnelles
PUT/DELETE
Au niveau item
Basées sur les attributs de l’item

SimpleDB : BD clé / valeur
Les opérations sont émises en tant que
des requêtes HTTP GET (REST)
Les réponses sont en XML
Prend en charge une syntaxe SQL-like pour extraire les
éléments du domaine
SELECT <speciﬁcation> FROM <domain> WHERE <condition>
Speciﬁcations
 * (tous les attributs)
 itemName()
 count(*)
 attributs spécifiques

https://sdb.amazonaws.com/
?Action=PutAttributes
&Attribute.1.Name=Color
&Attribute.1.Value=Blue
&Attribute.2.Name=Size
&Attribute.2.Value=Med
&Attribute.3.Name=Price
&Attribute.3.Value=0014.99
&Attribute.3.Replace=true
&AWSAccessKeyId=[valid%20access%20key%20id]
&DomainName=MyDomain
&ItemName=Item123
&SignatureVersion=2
&SignatureMethod=HmacSHA256
&Timestamp=2015-10-12T22%3A03%3A05-07%3A00
&Version=2009-04-15
&Signature=[valid%20signature]

<PutAttributesResponse>
<ResponseMetadata>
<RequestId>490206ce-8292-456c-a00f-61b335eb202b</RequestId>
<BoxUsage>0.0000219907</BoxUsage>
</ResponseMetadata>
</PutAttributesResponse>
<Response>
<Errors>
<Error>
<Code>InvalidClientTokenId</Code>
<Message>The AWS Access Key Id you provided does not exist in
our records.</Message>
</Error>
</Errors>
<RequestID>3d33c322-d9fd-927c-37d4-9683d9d671e9</RequestID>
</Response>

Cas d’utilisation
Stockage des informations de session
Profiles utilisateurs, Préférences
Chaque utilisateur dispose
d'un userID unique
des préférences telles que la langue, la couleur, le fuseau
horaire, etc.

BD Documentaires
Similaires aux BD clé/valeur sauf que la valeur est un

document
Modèle de données : paires (clé, document)
Document : JSON, XML, ou autres formats semi-
structures
Operations
Insert(clé,document), Fetch(clé), Update(clé), Delete(clé)
La recherche est basée sur le contenu du document
Exemples de systems
CouchDB, MongoDB, SimpleDB etc

BD Documentaires
Basées sur le format JSON
un modèle de données qui prend en charge
des listes, des cartes, des dates, Boolean avec
imbrication
Effectivement : documents semi-structurés
indexées
Exemple: Mongo
{Nom:“Tounsi",
Addresse :“ 13 Rue de l’indépendance, 2003, Tunis“
Petits-enfants : [Rym: "7", Karim: "6", "Majdi: "3", “Inès:
"1", “Anis: "3", Lakhdher: "1"]
}

Opérations CRUD MongoDB
CRUD : create, read, update et delete

MongoDB stocke les données sous forme de documents, qui sont des
paires (champs JSON-like : valeur).

Une collection de documents MongoDB

Opération d’insertion

Opération de recherche (query)

Opérations de mise à jour et suppression
db.books.update(
{ stock: { $lte: 10 } },
{ $set: { reorder: true } },
{ multi: true }
)
db.inventory.remove()
db.inventory.remove( { type : "food“ } )

Cas d’utilisation
Journalisation d’événements (Event Logging)

Système de gestion de contenu (CMS)
Web Analytics (les pages vues, les visites, etc)
Analyses en temps réel
Applications de E-commerce

MongoClientURI uri = new
MongoClientURI("mongodb://moez:moez@ds039484.mongolab.com:3948
4/moez");
MongoClient client = new MongoClient(uri);
MongoDatabase database = client.getDatabase(uri.getDatabase());
MongoCollection<Document> songs = database.getCollection("songs");

songs.insertMany(seedData);

public static List <Document> createSeedData(){
Document seventies = new Document();

seventies.put("decade", "1970s");
seventies.put("artist", "Debby Boone");
seventies.put("song", "You Light Up My Life");
seventies.put("weeksAtOne", 10);
Document eighties = new Document();

eighties.put("decade", "1980s");
eighties.put("artist", "Olivia Newton-John");
eighties.put("song", "Physical");
eighties.put("weeksAtOne", 10);

BD orientées colonnes
Stockage des données dans l'ordre des colonnes
Stocker des paires clé-valeur (et extraire par clé) dans
un système massivement parallèle
modèle de données: familles des attributs définis
dans un schéma, de nouveaux attributs peuvent
être ajoutés
principe stockage: grandes tables de hachages
distribuées
propriétés: partitionnement (horizontal et / ou
vertical) et haute disponibilité complètement
transparents à l'application

Cassandra

Cassandra
Keyspace : espace de clés

généralement le nom de l’application
Exemples: “Twitter”, “Lapresse”
Famille de colonnes : structure contenant un nombre
illimité de rangées
Colonne : un tuple avec nom, valeur et time-stamp
Clé : nom de l’enregistrement
Super colonne : contient beaucoup de colonnes

Cassandra

Liste de valeurs
Une carte de paires nom/valeur

Famille de colonnes

Exemple

Famille de Super Colonnes

Système de recherch d’hotels (SGBDR)

Cassandra

Cas d’utilisation
Logging d’événements
Systèmes de gestion de contenu (CMS)
Platformes de blog

BD de Graphes
▪ Modèle de données : noeuds et arcs

▪ Noeuds devraient avoir des propriétés (incluant ID)
▪ Arcs may devraient avoir des labels ou des rôles

BD de Graphes
▪ Interfaces and languages de requêtes varient
▪ Exemples de systèmes
Neo4j, FlockDB, Pregel, …

Chapitre 3: Big Data: Nosql

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapitre 3: Big Data: Nosql

Uploaded by

Copyright:

Available Formats

Chapitre 3

Big data : NoSQL

Big Data – 3TEL ENIT – Novembre 2017

Tracks the number of pageviews for any URL a customer wishes to

Big Data – 3TEL 2 ENIT – Novembre 2017

Timeout error on inserting to the database

Solution: Scaling with a queue

Create a worker process

reads 100 events at a time

Big Data – 3TEL 3 ENIT – Novembre 2017

Unfortunately that doesn’t help

Big Data – 3TEL 4 ENIT – Novembre 2017

Horizontal partitioning or Sharding

Big Data – 3TEL 5 ENIT – Novembre 2017

Databases and computation systems aware of their distributed nature.

Make data immutable

Big Data – 3TEL 6 ENIT – Novembre 2017

Un système de gestion de base de données (SGBD) fournit à une

Tout problème d'analyse (ou de gestion) de données est mieux résolu

Big Data – 3TEL 7 ENIT – Novembre 2017

Big Data – 3TEL 8 ENIT – Novembre 2017

La croissance des données surpasse la capacité de

Big Data – 3TEL 9 ENIT – Novembre 2017

▪ “SQL” = SGBD relationnel traditionnel

▪ “NoSQL” = Non SQL = Not using SQL

Big Data – 3TEL 10 ENIT – Novembre 2017

Big Data – 3TEL 11 ENIT – Novembre 2017

Big Data – 3TEL 12 ENIT – Novembre 2017

Ne supporte pas la totalité des caractéristiques des BD

Big Data – 3TEL 13 ENIT – Novembre 2017

▪ Analyser le fichier log d’un serveur Web

Entrée : UserID, URL, timestamp, info-

Tâche : trouver tous les enregistrements pour …

Big Data – 3TEL 14 ENIT – Novembre 2017

Tâche : Trouver la moyenne d’âge des

Big Data – 3TEL 15 ENIT – Novembre 2017

Entrée : UserID1, UserID2

Big Data – 3TEL 16 ENIT – Novembre 2017

Large collection de documents

Big Data – 3TEL 17 ENIT – Novembre 2017

Alternative aux SGBD relationnels

– Pas de langage de requête déclaratif  beaucoup

Big Data – 3TEL 18 ENIT – Novembre 2017

Big Data – 3TEL 19 ENIT – Novembre 2017

Partition-Tolerence : Tolérance au Partitionnement

Big Data – 3TEL 20 ENIT – Novembre 2017

AP: a reachable replica provides

A AP : une réplique accessible offre P

Big Data – 3TEL 22 ENIT – Novembre 2017

Big Data – 3TEL 23 ENIT – Novembre 2017

Big Data – 3TEL 24 ENIT – Novembre 2017

Big Data – 3TEL 25 ENIT – Novembre 2017

Big Data – 3TEL 29 ENIT – Novembre 2017

Big Data – 3TEL 30 ENIT – Novembre 2017

Big Data – 3TEL 31 ENIT – Novembre 2017

Big Data – 3TEL 32 ENIT – Novembre 2017

Big Data – 3TEL 33 ENIT – Novembre 2017

Similaires aux BD clé/valeur sauf que la valeur est un

Big Data – 3TEL 34 ENIT – Novembre 2017

Big Data – 3TEL 35 ENIT – Novembre 2017

CRUD : create, read, update et delete

Big Data – 3TEL 36 ENIT – Novembre 2017