Chapitre 1 :

Bases de données NOSQL

Plan
 Forces des SGBD
 Propriétés ACID
 Limites des BDR
 BD NOSQL
 BDR vs BD NOSQL

2
Forces des SGBDR
 Indépendance entre :
 Modèle de données et structures de stockage
 Requêtes déclaratives et exécution

 Possibilité d’exécuter des requêtes complexes

 Optimisation très fine des requêtes, index permettant

un accès rapide aux données

 Logiciels mûrs, stables, efficaces, riches en

fonctionnalités et en interfaces
3
Forces des SGBDR
 Contraintes d’intégrité permettant d’assurer des
invariants sur les données.

 Gestion efficace de grands volumes de données

(gigaoctet, voire téraoctet).

 Gestion des transactions (ensembles

d’opérations atomiques) garantissant la gestion
de la concurrence, la reprise sur panne.

4
Propriétés ACID

Les transactions des SGBD relationnels classiques

respectent les propriétés ACID.

Atomicité – Cohérence – Isolation – Durabilité

5
Limites des BDR
 Incapable de gérer de très grands volumes de données
(de l’ordre du péta-octets)

 Impossible de gérer des débits extrêmes (plus que

quelques milliers de requêtes par seconde)

 Le modèle relationnel est parfois peu adapté au

stockage et à l’interrogation de certains types de
données
Données hiérarchiques, semi-structurées

6
Limites des BDR
 Les propriétés ACID entraînent de sérieux surcoûts en
latence, accès disques, temps CPU (verrous,
journalisation, etc.)

 Performances limitées par les accès disque.

7
Bases de données NOSQL
 Not Only SQL

 SGBD avec d’autres compromis que ceux faits par les

systèmes classiques.

 Caractéristiques recherchées : modèle de données

différent, passage à l’échelle, performances extrêmes

 Caractéristiques abandonnées : ACID, (parfois) requêtes

complexes.

8
Bases de données NOSQL
Types des bases de données NOSQL :
 Clef/valeur
 Orientées colonnes
 Orientées documents
 Orientées graphes

9
Bases de données NOSQL
Modèle Clef-Valeur
 L’un des types les plus simples, sorte de Hashmap
distribuée.

 Conçues pour sauvegarder les données sans

définir de schéma.

 Toutes les données sont sous forme de clef/valeur

10
Bases de données NOSQL
 Communications se résumant surtout aux
opérations PUT, GET et DELETE

 Absence de typage a un impact sur le requêtage :

toute l’intelligence portée avant par les requêtes
devra être portée par l’applicatif qui interroge la BD

 Exemple : DynamoDB (Amazon), Azure Table

Storage (ATS), Redis, BerkeleyDB, Voldemort
(LinkedIn)
11
Bases de données NOSQL
Id Nom Humeur Date_naissance Couleur

12 Stella Heureuse 2007-04-01 NULL

13 Wimma Faim NULL Noire

9 Ninja NULL NULL NULL

Nom_$#_Stella~~Humeur_$#_Heureuse
Chien_12 ~~Date_naissance_$#_2007-04-01…

12
Bases de données NOSQL
BD orientées documents
 Étendent le paradigme clef/valeur, avec des «
documents » plus complexes à la place des données
simples, et une clef unique pour chacun d’eux.
 Documents de type JSON, XML…
 Chaque document est un objet, contient un ou
plusieurs champs, et chaque champ contient une valeur
typée (string, date, binary ou array)

13
Bases de données NOSQL
 Permettent de stocker, extraire et gérer les informations
orientées documents (données semi-structurées)

Avantage : pouvoir récupérer, via une seule clef, un ensemble

d’informations structurées de manière hiérarchique.
Dans les bases relationnelles, cela impliquerait plusieurs
jointures

Exemples : Mongo DB (SourceForge), Couch DB (Apache),

RavenDB (destiné aux plateformes .Net/Windows,
interrogation via LINQ)

14
 Bases de données NOSQL
Id Nom Humeur Date_naissanc Couleur
e
12 Stella Heureuse 2007-04-01 NULL
13 Wimma Faim NULL Noire
9 Ninja NULL NULL NULL

Document(V2)
{
type : « Chien »,
nom : « Stella »,
Document(V1) humeur : « Heureuse »,
date_naissance : 2007-04-01
{ aboiement : [
{ texte : « j’ai mangé
Clef type : « Chien », de la pâtée »
nom : « Stella », commentaires : [
Chien_12 humeur : « Heureuse », { id_chien : «
chien_4 »,
date_naissance : 2007-04-01 }
texte : « on
]
} } s’en fout! »

}
]

15
Bases de données NOSQL
BD orientées colonnes
 Évolution des BD clef/valeur

 Ressemble aux SGBDR, mais avec un nombre de colonnes

dynamique, différent d’un enregistrement à un autre (pas de
colonnes portant les valeurs NULL)

 Offrent de très hautes performances et une architecture

hautement évolutive.

16
Bases de données NOSQL
Exemples : Hbase (Hadoop), Cassandra (Facebook,
Twitter), BigTable (Google)
ID  Nom  Prénom  Prime
1  Doe  John  8000
2  Smith  Jane  4000
3  Beck  Sam  1000

Dans une BD orientée Colonnes les données sont stockées comme suit :
1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;

17
Bases de données NOSQL
BD orientées Graphes
 Basées sur les théories des graphes
 S’appuient sur les notions de nœuds, de relations et des
propriétés qui leur sont rattachées
 Conçues pour les données dont les relations sont représentées
comme graphes, et ayant des éléments interconnectés, avec un
nombre indéterminé de relations entre elles.
 Adapté aux traitements des données des réseaux sociaux
 Exemples : Neo4J et InfiniteGraph, OrientDB

18
 Bases de données NOSQL
Id Nom Humeur Date_naissance Couleur

12 Stella Heureuse 2007-04-01 NULL

13 Wimma Faim NULL Noire

9 Ninja NULL NULL NULL

Chien_4

commente

Chien Commentaire
_ 83

Stella type Commentaire_à texte

nom
humeur aboiements Aboiement_
Heureuse Chien_12 « On s’en
5 9 fout! »
date_naissance
texte
« J’ai mangé de la
2007-04-01
pâtée! »

19
NOSQL vs BDR
Le choix de NOSQL plutôt que les bases de données
relationnelles est conduit par les contraintes du marché et les
besoins techniques suivants :
Big Data
Adaptation des BD NOSQL aux Big Data
o Vitesse (Velocity) : beaucoup de données qui arrivent
rapidement, à partir de plusieurs sources
o Variété (Variety) : données structurées, semi-structurées
ou non-structurées
o Volume (Volume) : données massives (To et Po)

20
NOSQL vs BDR
 Modèles de données flexibles
o Une des raisons majeures
o Dans le modèle relationnel :
 Les relations entre les tables sont prédéfinies, fixes et organisées dans
un schéma strict et uniforme
 Problèmes d’évolutivité et de performance en gérant de grands
volumes de données.
o Les BD NOSQL peuvent accepter tout type de données
(structurées, semi-structurées ou non-structurées) plus
facilement.
o Dans les BDR, les performances posent problème, surtout
quand des lignes « larges » sont utilisées et les actions de
modification sont nombreuses.
21
NOSQL vs BDR
 Disponibilité continue des données
◦ Le manque de disponibilité peut être fatal pour une
entreprise.

◦ BD NOSQL utilisent une architecture hautement distribuée :

pas de SPOF

◦ Redondance des données et traitements : tolérance aux fautes

◦ Toute mise à jour ou modification est faite sans déconnecter

la base

22
NOSQL vs BDR
 Indépendance de l’emplacement

o Possibilité
de consulter et modifier une BD sans savoir où
est-ce que ces opérations ont réellement lieu.

o Toute fonctionnalité d’écriture est propagée à partir d’un

emplacement, pour être disponible aux utilisateurs à partir
d’autres sites.

23
NOSQL vs BDR
 Capacité des bases NOSQL à exploiter les données
collectées pour dériver des idées
o Extraction d’informations décisionnelles à partir d’un
grand volume de données : difficile à obtenir avec des
bases relationnelles.

o Bases NOSQL permettent le stockage et la gestion des

données des applications métier, et fournissent une
possibilité de comprendre les données complexes, et de
prendre des décisions.

24
NOSQL vs BDR
 Capacités transactionnelles modernes
o Nouvelles définitions du principe de transaction

o Utilisation des propriétés BASE au lieu des propriétés

ACID

25
NOSQL vs BDR
Toutes les BDR supportent les transactions ACID.
Mais :

◦ Données de plus en plus volumineuses + Besoin de

systèmes évolutifs.

◦ Besoin de BD distribuées sur le réseau, pour une évolutivité

horizontale.

26
NOSQL vs BDR
Théorème CAP :
Dans les systèmes distribués, il est impossible de
satisfaire les trois propriétés CAP en même temps.

CAP = Consistency, Availability, Partition

Tolerance

27
NOSQL vs BDR
Pourquoi est-il impossible de satisfaire les 3 propriétés CAP en
même temps?
Soit un système distribué. On est entrain de modifier une donnée sur
le nœud N1 et d’essayer de la lire à partir du nœud N2 :
N2 peut retourner la dernière bonne valeur dont il dispose, ce qui
viole la Consistance.
N2 attend que la nouvelle valeur lui parvienne. Comme c’est un
système distribué, les risques d’un échec de transmission sont assez
importantes, ce qui provoquera une attente infinie de N2. D’où une
violation de la Disponibilité.
Si on veut satisfaire à la fois la consistance et la disponibilité, le
système de stockage ne doit pas être partitionné. D’où violation de la
Tolérance au partitionnement.

28
NOSQL vs BDR
BASE
Basically Available
Le système garantit la disponibilité, comme définie dans le
théorème CAP
Soft-State
L’état du système peut changer dans le temps, même sans
nouvelles entrées, et ce à cause du principe de consistance
éventuelle.
Eventual Consistency
Les modifications arriveront éventuellement à tous les
serveurs, si on leur donne suffisamment de temps.
29
NOSQL vs BDR - Synthèse
Bases de données NOSQL :
o Performances sur de gros volumes de données
o Performances sur des données non structurées
o Evolutivité très importante, même pour de faibles volumes

Cependant :
 Technologie assez jeune => Manque d’outils la supportant
 Encore en évolution, pas de standards
 Pas de langage de requête commun comme SQL, mais divers :
o Requêtes spécifiques au langage (Java, Python…)
o Requêtes spéciales pour la base (Cassandra Query Language)
o API basée sur Map Reduce…

30
NOSQL vs BDR
Quand utiliser NOSQL?
 Si l’évolutivité est une préoccupation
Mais attention, ce n’est pas toujours un MUST : Flickr et
Wikipédia utilisent des SGBDR
 Si l’absence de schéma est une préoccupation
 Si être IN et FASHION est une préoccupation
Pour un nombre important de personnes, l’utilisation d’un nouveau
paradigme ou technologie est nécessaire !

31