1.
Introduction à
NoSQL databases
Dec 2019
1

2.
 Stocke les données dans les tableaux
 Prend en charge la jointure entre les tables pour
interroger des données
Langage de requête standard (SQL)
Utilise l’Algèbre relationnelle
Évitez la duplication de données (Principe de Normalization)
Les transactions ACID
 (Atomicité, Cohérence, Isolation, Durabilité)
Bases de données relationnelles
 Avantages des bases de données
relationnelles:
2

3.
Exemple 3

4.
Pour un projet simple
on a besoins des relation (clés étranger)
on a besoin des schémas
on veut économiser l’espace disque.
Cas d’utilisation 4

5.
ACID
Atomicity (Atomicité): Les tâches d'une transaction est
exécutée ou aucune d'entre elles. C'est le principe du tout ou rien.
Si un élément d'une transaction échoue, toute la transaction
échoue.
Consistency (Cohérence): La BDD doit rester dans un état cohérent
au début et à la fin d'une transaction. il n'y a jamais de transactions à
moitié terminées.
Isolition (Isolation): Aucune transaction n'a accès à une autre
transaction dont l'état n'est pas terminé. Ainsi, chaque transaction est
indépendante en soi. Cela est nécessaire pour la cohérence des
transactions dans une base de données.
Durability (Durabilité): Une fois la transaction terminée, elle
persistera et ne pourra plus être annulée, Elle survivra aux pannes du
système, aux coupures de courant et à d'autres types de pannes du
système.
5

6.
BASE
Presque l'opposé d'ACID.
Basically Available: les nœuds d’un environnement
distribué peuvent tomber en panne, mais l’ensemble du
système ne doit pas être affecté.
Soft State (scalable): L'état du système et les données
changent avec le temps.
Eventual Consistency: si les délais sont suffisants, les
données seront cohérentes sur l'ensemble du système
distribué.
6

7.
BASEvsACID 7
ACID:
• Cohérence forte
• Moins de disponibilité
• Complexe
BASE:
• La disponibilité.
• Cohérence plus faible (éventuelle)
• Meilleur effort
• Simple et rapide

8.
Montée du Big Data
Wallmart: 1 million de transactions par
heure
Facebook: 40 billionphotos
Les personnes parlent plus que des
petabyte
8

9.
Ère des Système distribué
A cause de la quantité énorme des données qui a apparue la
seule solution pour remédier a ce problème été les system
distribués
L’apparition du théorème de CAP.
Ce qui a introduit la terminologie horizontal scaling
9

10.
10Ère des Système distribué

11.
Mais...
 Les bases de données relationnelles n'ont pas
été construites pour applications distribuées.
Car...
 Les jointures sont chères
 Difficile pour la Mise à l'échelle horizontale
(horizontal scaling)
 Une inadéquation d'impédance se produit
 les requêtes sont parfois très complexes
(jointure)
 Un peu lent à cause des transaction ACID.
11
Ère de l'informatique distribuée
(Distributed Computing)

12.
Mais...
 Les bases de données relationnelles n'ont pas
été construites pour applications distribuées.
Car...
 Les jointures sont chères
 Difficile pourlaMiseàl'échelle horizontale
(horizontal scaling)
 Une inadéquation d'impédance se produit
 les requêtes sont parfois très complexes
(jointure)
 Un peu lent à cause des transaction ACID.
Et....
Il est faible en:
 Vitesse(performance)
 La haute disponibilité
12
Ère de l'informatique distribuée
(Distributed Computing)

13.
‘‘NoSQL’’
13

14.
NoSQL?
Google & Amazon construisent leurs
propres bases de données
Facebook a inventé Cassandra et en
utilise des milliers
Le nom n’indique pas ses
caractéristiques
Il n'y a pas de définition stricte pour les bases
de données NoSQL
Il y a plus de 225 bases de données NoSQL
(nosql-database.org)
14

15.
3 V(s) de Bigdata:
Data Velocity
 Beaucoup de données arrivant très rapidement, éventuellement de
différents endroits
Data Variety
 Stockage de données structurées, semi-structurées, non
structurées
Data Volume
 Données comportant plusieurs téraoctets ou pétaoctets
Data Complexity
 Données stockées et gérées dans différents emplacements ou
centres de données
153v1c?

16.
C’est pourquoi nous avons besoin de NoSQL
16

17.
Caractéristiques des bases de données
NoSQL
Non relationnel
Moins de schéma
Open-source
17

18.
NoSQLévite :
Complexité de la requête SQL
Charge de la conception initiale du schéma
Transactions (il devrait être traité à couche d'application)
Fournit :
Modifications faciles et fréquentes de la base de données
Horizontale scaling
Solution au mismatch d'impédance
Développement rapide
18Caractéristiques des bases de données
NoSQL

19.
NoSQL devient populaire 19

20.
Exemple 20

21.
Types du base de données NoSQL 21

22.
Key-value (Clés-valeurs )
Repose sur le couple clé-valeur
Les données peuvent avoir n'importe quel
format
Conçu pour gérer beaucoup de données
et une charge importante
Stockent les données sous forme de
table de hachage
22

23.
Avantages
Peut stocker n’importe quel type de valeur
Rapide
Hautement évolutive (Highly Scalable)
Hautement disponible (Highly availability)
Des operations de base: Insert(key,value),
Update(key), Delete(key).
23

24.
Inconvénient
La recherche ne peut pas être effectuée avec
les valeurs.
Pas de requête.
Pas des relations.
24

25.
Document
Repose sur la notion de clé-valeur
Stock les données dans un
document(JSON, XML)
Les valeurs sont structurées
Conçu pour gérer et stocker les
documents.
25

26.
Avantages
Simple
Pas des jointures
Pas de schéma
Consistante
Les requête sont simple que le SQL
26

27.
Inconvénient
Pas des transaction ACID
Pas de model
Les données sont dupliqués
27

28.
Exemple Insertion
28
SQL NoSQL
INSERT INTO book (
` Num ’,’Titre’, `Auteur’
)
VALUES (
’123456789′,
‘La blonde de pékin’,
‘James Hadley Chase’
);
db.book.insert(
{Num: “123456789″, Titre: “La blonde de
pékin”, Auteur: “James Hadley Chase”}
);
Ajoute un nouveau
livre

29.
Simple MongoDB query 29
SQL:
MongoDB:
Iln'yapasdejointuredanslarequêteMongoDB
Parcequenousutilisonsunmodèlededonnées

30.
Présentation d'un modèle de données basé sur
des documents 30

31.
Présentation d'un modèle de données basé
sur des documents 31

32.
Column family (Colonnes)
32
Les bases de données de familles de
colonnes sont représentées dans des
tables
Se focalise sur les attributs
Fournissent des performances élevées
sur les requêtes d'agrégation
Toutes les données associées peuvent
être regroupées dans une même famille
Utilisées pour gérer Data Warehouses,
BI

33.
Avantages
Flexibilité
Non-stockage des valeurs null
Lecture Rapide
Conçu pour stocker une quantité énorme des
données
33

34.
Inconvénient
Non-adaptée aux données interconnectées
Non-adaptée pour les données non-strucurées
Faible Taux de compression
Beaucoup de colonnes
Complexe
34

35.
Graph (Base graphique)
Elles remplacent les tables relationnelles par des graph
relationnels structurés.
Basé sur la théorie des graphes.
Vous pouvez facilement utiliser les algorithmes
graphiques
Elles sont utiles lorsque vous êtes plus intéressé par les
relations entre données que par les données elles -
mêmes
35

36.
Avantages
Il y a des relations
Identiques quand le jeu de données s'accroît
La flexibilité
Les transaction ACID
36

37.
Inconvénient
Une structure très complexe
Pas facile pour la répartition
Parcourir le graphique entier pour obtenir une
réponse définitive
37

38.
Donc…
Nous avons besoin d'un système de base de données
distribué ayant de telles fonctionnalités:
–Tolérancedepartition
–Lahautedisponibilité
–Cohérence
–L'évolutive
38

39.
Donc…
Nous avons besoin d'un système de base de données
distribué ayant de telles fonctionnalités:
–Tolérancedepartition
–Lahautedisponibilité
–Cohérence
–L'évolutivité
39

40.
Théorème CAP
Consistency (Cohérence): les
clients doivent lire les mêmes
données.
Availability (Disponibilité): Les
données doivent être
disponibles, et ne devrait pas
y avoir de temps d'arrêt.
Partition Tolerance(Distribution):Les
données à partitionné sur des
segments de réseau.
40

41.
Théorème CAP dans différentes bases de données SQL / NoSQL
We can not achieve all the three items
Indistributed database systems(center) Proven by Nancy Lynch et al. MIT labs.
41

42.
Le triangle de CAP
42

43.
43Conclusion : SQL vs NoSQL
SQL NOSQL
Scalabilité vertical et pas trop
horizontale
Scalabilité horizontale
Cohérent Consistante ou éventuelle
Scalable lecture Scalable Lecture / écriture
Transactions sur plusieurs tables Difficile de supporter la
transaction
Aucune tolérance de partition Tolérance de partition
Schéma / tables Pas de schéma
Requêtes flexibles (jointures) Requêtes limitées

44.
Avantdechoisir NoSQLcommesolution : 44

45.
Persistancepolyglot: l'avenirdessystèmesdebasede
données
 Les futures bases de données combinent SQL et NoSQL
 Nous avons toujours besoin de bases de données
relationnelles
45

46.
46

47.
Références :
 Présentation de Martin Fowler à la conférence de Goto
 www.mongodb.org
 Google, Youtube…
47

48.
THE END