Le document traite des bases de données NoSQL, expliquant leur historique, leurs avantages aux systèmes relationnels, ainsi que les concepts de scalabilité, ACID et BASE. Il présente différents types de bases de données NoSQL, y compris les bases de données clé/valeur, orientées document, orientées colonne et orientées graphe, tout en soulignant les cas d'utilisation de chacune. En conclusion, le passage aux bases de données NoSQL est motivé par les exigences modernes en matière de big data et de performance, soulignant l'importance de choisir le bon type de base de données selon les besoins spécifiques.

1. Les BDD NOSQL
République Algérienne démocratique et populaire.
Université Dr. Tahar Moulay – Saïda
Département d’informatique
Matière : BDD Avancé
M1 RISR
Présenté par : Enseigné par :
• Kamar MEDDAH
• Abderrahmane KAFI
• Mr. Miloud BENAYHIYA
2018/2019

2. Plan
I. INTRODUCTION,
II. HISTORIQUE,
III. BDD RELATIONNEL,
IV. LES BDD NOSQL,
V. POURQUOI LES BDD NOSQL,
VI. THÉORÈME DE CAP ET ACID & BASE,
VII. SQL VS NO SQL,
VIII. TYPE DES BDD NOSQL CONCLUSION.
BDD NOSQL 2

3. I. Introduction

4. Historique
BDD NOSQL 4

5. Historique
BDD NOSQL 5

6. BDD Relationnel
BDD NOSQL 6

7. BDD
Relationnel
 Existe depuis plus de 48 ans,
 Utilise l’Algèbre relationnelle,
 Forte consistance, concurrence, récupération,
 Populaire,
 Langage de requête standard (SQL),
 Fonctionne très bien dans la plupart des cas
BDD NOSQL 7

8. BDD
Relationnel
BDD NOSQL 8

9. Exemple
 MySQL,
 Maria DB,
 Oracle,
 SQL Server,
 PostgreSQL,
 IBM/DB2,
 H2,
 Apache Derby,
 webSQL,
 Sqlite.
BDD NOSQL 9

10. Avantages
 Les transactions ACID,
 Contexte mathématique (Algèbre relationnelle),
 Langage de requête standard (SQL),
 Évitez la duplication de données ,
 Taux de compression élevé (le disque était plus cher)
 SQL et SGBDR ont rendu les requêtes flexibles avec des
schémas rigides
 Un écosystème massif d’outils, de bibliothèques et
d’intégrations
 Existe depuis plus de 48 ans,
BDD NOSQL 10

11. Inconvénient
 Schéma défini, attributs optionnels (NULL),
 les requêtes sont parfois très complexes (jointure),
 Utiliser des jointures pour agréger des données liées,
 Difficile pour la Mise à l'échelle horizontale (horizontal
scaling),
 Les jointure son couteuse,
 Un peut lent a cause des transaction ACID.
BDD NOSQL 11

12. Cas
d'utilisation
 Dans un system ou il faut des transaction solide et
cohérente (une banque ),
 Pour un projet simple,
 on a besoins des relation (clés étranger),
 on est besoin des schémas,
 on veut économiser l’espace disque.
BDD NOSQL 12

13. C’est quoi une BDD
NOSQL ?
BDD NOSQL 13

14. BDD
NOSQL
 La théorie et les offres NoSQL modernes ont débuté au début
des années 2000
 L’usage moderne du terme NOSQL introduit en 2009
 NoSQL = Not Only SQL (pas seulement SQL)
 Une collection de produits très différents
 Alternatives aux bases de données relationnelles quand elles
sont un mauvais ajustement
 À présent, nosql-database.org répertorie plus de 225 bases
de données NoSQL.
BDD NOSQL 14

15. Pourquoi les BDD
NOSQL ?
BDD NOSQL 15

16. Big Data
BDD NOSQL 16

17. Big Data
 Big Data signifie que les données sont
suffisamment volumineuses pour que vous deviez
y réfléchir afin d’extraire l'information.
 Big Data lorsqu'il cesse de monter sur une seule
machine
 Le Big Data, est une façon de penser
fondamentalement différente sur les données et la
manière dont elles sont utilisée.
BDD NOSQL 17

18. Big Data
 Gartner utilise les 3V pour définir:
 Volume
 Volume important / difficile / extrême relatif
 Variété
 données changeantes ou évolutives
 Formats non contrôlés
 N'adhère pas facilement à un seul schéma
 Inconnu au moment de la conception
 Rapidité
 Données entrantes élevées ou volatiles
 Hautes requêtes et lectures
 Faible latence
BDD NOSQL 18

19. L’é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,
 Ce qui a introduit la terminologie horizontal scaling,
 L’apparition du théorème de CAP.
BDD NOSQL 19

20. Théorème
de CAP
Un système distribué ne peut prendre en charge que
deux des caractéristiques suivantes:
 Consistency (toutes les nœuds dans un system distribué renvoie la
même valeur)
 Availability (Chaque nœud non défaillant renvoie une réponse pour
toutes les demandes de lecture et d'écriture dans un délai
raisonnable )
 Partition Tolerance (Le système continue de fonctionner et
maintient sa cohérence malgré les partitions de réseau )
BDD NOSQL 20

21. BDD NOSQL 21

22. ACID & BASE
BDD NOSQL 22

23. ACID
 Atomicity (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 (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).
 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 (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).
BDD NOSQL 23

24. BASE
 Basic Availability (le système garantit la disponibilité des
données et il y aura une réponse à toute demande. Mais cette
réponse pourrait être un "échec" pour obtenir les données
demandées ou les données peuvent être dans un état incohérent)
 Soft-state (L’état du système peut changer avec le temps, même
pendant les périodes sans demande d’écriture, des changements
peuvent survenir en raison de la «cohérence éventuelle», ainsi l’état
du système est toujours «souple»)
 Eventual consistency (Au fur et à mesure que des données sont
ajoutées au système, son état est progressivement répliqué sur tous
les nœuds)
BDD NOSQL 24

25. Les Limites
du BDD
Relationnel
 N’est pas conçu pour les system distribué,
 Difficile de le scale horizontalement,
 Très difficile/impossible pour la répartition.
 Il est faible en:
 Vitesse (performance)
 Haute disponibilité
 Tolérance de partition
BDD NOSQL 25

26. Avantages
 Conçu pour les systèmes distribués,
 Elle n’a pas de schéma (flexible),
 Base transactions,
 Les requête sont simple (pas de jointure),
 Mise à l'échelle horizontale (scale out) ,
 Développement rapide .
BDD NOSQL 26

27. Alors devrions-nous
abandonner les base de
données relationnelles et
basculer vers les bases de
données NOSQL ?
BDD NOSQL 27

28. Inconvénient
 Elle n’a pas de schéma,
 Pas un langage de requête standard,
 Pas des transaction ACID.
BDD NOSQL 28

29. SQL vs NOSQL
BDD NOSQL 29

30. 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
BDD NOSQL 30

31. Les type du BDD
NOSQL
BDD NOSQL 31

32. BDD
Clé / valeur
BDD NOSQL 32

33. BDD
Clé / valeur
BDD NOSQL 33
 Ces SGBD stockent les éléments sous forme d'identificateurs
alphanumériques faisant référence aux clés. Chaque clé a
des valeurs associées.,
 La valeur peut être simples chaînes de texte ou
plus complexes listes et ensembles et(blob, json,
image..etc.),
 Leger et compact.

34. BDD
Clé / valeur
BDD NOSQL 34

35. Exemple
 Dynamo (Amazon),
 Voldemort (LinkedIn),
 BerkeleyDB
 MemcacheDB,
 Redis,
 Riak,
 IndexedDB.
BDD NOSQL 35

36. Avantages
 Pas des données dupliquer,
 Très rapide,
 La simplicité de clé/ valeur les rend très rapides et
léger,
 hautement évolutive (Highly Scalable),
 hautement disponible (Highly availability),
 Peut stocker n’importe quel type de valeur,
 Des operations basic : Insert(key,
value),Update(key), Delete(key).
BDD NOSQL 36

37. Inconvénient
 Recherche effectuée uniquement avec les
clés et limitée aux correspondances
exactes,
 La recherche ne peut pas être effectuée
avec les valeurs,
 Pas de requête,
 nombreuses structures de données (objets)
ne peuvent pas être facilement modélisées
comme des paires clé/valeur.
BDD NOSQL 37

38. Cas
d'utilisation
 requises pour les tâches d'application telles que
l'extraction de noms de produits,
 C’est pourquoi Amazon utilise le système
clé/valeur dans son chariot,
 Le dynamo est une valeur-clé hautement
disponible système de stockage,
 Pour le cache,
 Pour l’indexation.
BDD NOSQL 38

39. BDD Orienté
Document
BDD NOSQL 39

40. BDD
Orienté
Document
 Conçu pour gérer et stocker les documents,
 Pas de schéma,
 Ces documents sont encodés dans une format
standard d'échange de données tel que XML,
JSON (notation d'option JavaScript) ou BSON
(JSON binaire),
 Généralement, un modèle d’échange de type
JSON (BSON), qui prend en charge les listes,
cartes, dates, objets avec imbrication,
 Modèle de requête: JavaScript ou personnalisé,
 Agrégations: map / reduce.
BDD NOSQL 40

41. BDD
Orienté
Document
BDD NOSQL 41

42. Exemple
 MongoDB,
 CouchDB,
 CouchBase,
 ElasticSearch,
 RethinkDB.
BDD NOSQL 42

43. Avantages
 Simple
 Pas des jointures,
 Pas de schéma,
 Consistante,
 Contrairement au simple stockage clé/valeur, les
clés et les valeurs sont entièrement interrogeables.
 Les requête sont simple que le SQL.
 Proche des BDD relationnel.
BDD NOSQL 43

44. Inconvénient
 Les données sont dupliquer,
 Pas des transaction ACID,
 Pas de model,
BDD NOSQL 44

45. Cas
d'utilisation
 Quand on a plus que 10 jointures,
 Quand on est besoin d’un system Scalable
horizontalement,
 Quand on a des champs de données vide,
 Quand on a pas besoin des schéma.
 Utiles pour stocker et gérer des collections des
documents littéraux d’une grande taille, tels que
des documents texte, des messages électroniques.
BDD NOSQL 45

46. BDD Orienté
Colonne
BDD NOSQL 46

47. BDD
Orienté
Colonne
 Elle consiste en une paire clé/valeur dans laquelle
la valeur consiste en un ensemble des colonnes,
 Les bases de données de familles de colonnes
sont représentées dans des tables, chaque paire
clé/valeur étant une ligne,
 Toutes les données associées peuvent être
regroupées dans une même famille,
 Conçu pour stocker une quantité énorme des
données,
 Facile pour le scaling horizontale,
BDD NOSQL 47

48. BDD
Orienté
Colonne
BDD NOSQL 48

49. Exemple
 Apache CassandraDB,
 Google BigTable,
 Apache HBase,
 Hypertable.
BDD NOSQL 49

50. Avantages
 Flexibilité,
 Temps de traitement,
 Non-stockage des valeurs null,
 Lecture Rapide,
 Conçu pour stocker une quantité énorme des
données,
 Langage de requête rapprocher de SQL (CQL3).
BDD NOSQL 50

51. 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.
BDD NOSQL 51

52. Cas
d'utilisation
 Traitement de données à grande échelle et par
lots: tri, analyse, conversion ,
 Analyse exploratoire et prédictive réalisée par des
statisticiens et des programmeurs experts,
 Lorsqu’on a une énorme quantité de données a
stocker,
 lorsque l’on doit stocker de très nombreux
évènements qui doivent être mis à jour très
régulièrement.
BDD NOSQL 52

53. BDD Orienté
Graph
BDD NOSQL 53

54. BDD
Orienté
Graph
 Elles remplacent les tables relationnelles par des
graph relationnels structurés d'appariements
interconnectés clé/valeur.
 La base de données relationnelle est une collection
de tables faiblement connectées alors que la base
de données orienté graph sont un graphe multi-
relationnel ,
 Elles sont utiles lorsque vous êtes plus intéressé
par les relations entre données que par les
données elles-mêmes ,
 Elles son optimisé pour les relations traversantes
et non pas pour les requêtes.
BDD NOSQL 54

55. BDD
Orienté
Graph
BDD NOSQL 55

56. Exemple
 Neo4j
 Ggraph,
 OrientDB,
 Titan,
 InfoGrid,
 Sones GraphDB,
 AllegroGraph,
 InfiniteGraph.
BDD NOSQL 56

57. Avantages
 la performance des bases de données Graph
restent identiques quand le jeu de données
s'accroît par contre les BDD relationnel,
 Il y a des relations,
 identiques quand le jeu de données s'accroît.
 La flexibilité,
 L'agilité.
 Les algorithms des graph e.g. le Chemins le plus
court, relations de degré n ,… etc.
 Les transaction ACID
BDD NOSQL 57

58. Inconvénient
 Elle sont pas performantes pour calculer de
grandes agrégations de données,
 Une structure très complexe.
 parcourir le graphique entier pour obtenir une
réponse définitive.
 Pas facile pour la répartition.
BDD NOSQL 58

59. Cas
d'utilisation
 Fonctionne parfaitement pour les réseaux sociaux,
 Avec cette technologie également que eBay peut
optimiser ses livraisons en un temps cours,
BDD NOSQL 59

60. Questions
BDD NOSQL 60

61. Questions
 Devrions-nous abandonner les base de données
relationnelles et basculer vers les bases de données
NOSQL ?
 Pourquoi existe il trop de types des BDD ?
 Quel type de BDD je dois choisir ?
BDD NOSQL 61

62. Conclusion
BDD NOSQL 62

63. Conclusion
 Les exigences en matière de calcul et de stockage des
applications telles que les analyses Big Data, la Business
Intelligence et les réseaux sociaux sur des jeux de données
péta-octets nous ont amenés à passer de la base de données
SQL à la base de données NoSQL,
 Cela a conduit au développement de bases de données NOSQL
non relationnelles distribuées, Scalable horizontalement,
 MongoDB est le plus demandé,
 Chaque Type de BDD a ses avantage et ses incovients il faut
choisir la BDD qui vous convient selon vos besoins (Le bon outil
pour le bon travail),
 Généralement vous allez vous trouver utiliser plusieurs BDD en
même temps.
 Il n’ y a pas des relations dans les BDD clé/valeur ,BDD orienté
document et BDD orienté colonne.
BDD NOSQL 63

64. Merci pour votre
attention
BDD NOSQL 64

65. N'hésitez pas
à poser des questions
BDD NOSQL 65