Introduction aux bases de données NoSQL
Sommaire
Les besoins en gestion de données
Demande au niveau des données
Beaucoup de données
Solutions possibles
SQL
SQL
Limites des SGDBR
Il faut trouver une solution
Solutions propriétaires
Naissance du mouvement NoSQL
Le terme NoSQL a été créé par Johan
Oskarsson en 2009 au cous d’un
meeting à San Fransisco
Il lui fallait trouver un hashtag Twitter
pour exprimer les produits tels que
BigTable et Dynamo
Johan Oskarsson
Caractéristiques des bases NoSQL (1)
Ce sont des bases de données Non-relationnelles
Open source pour la plupart
Souvent installées sur un cluster (grappe de serveurs)
Acceptent les données de structures complexes ou
imbriquées
Caractéristiques des bases NoSQL (2)
Pas de schéma pour les données ou schéma
dynamique
Partitionnement horizontal des données
(sharding) sur plusieurs noeuds (serveurs)
généralement par utilisation d'algorithmes tel
que « MapReduce »
Réplication des données sur plusieurs noeuds
Atouts des bases NoSQL
•Évolutivité
•Disponibilité
•Tolérance aux pannes
Modèles des données des bases NoSQL
Bases de données NoSQL
Les familles des BDDs NoSQL
Familles des BDDs NoSQL
Stocker les informations de la façon la mieux adaptée à leur
représentation :
« Clé-valeur / Key-value » : chaque objet est identifié
par une clé unique constituant la seule manière de le
requêter
« Colonne / Column » : permet de disposer d'un très grand
nb de valeurs sur une même ligne, de stocker des relations «
one-to-many », d'effectuer des requêtes par clé (adaptés au
stockage de listes : messages, posts, commentaires, ...)
« Document » : gestion de collections de documents,
composés chacun de champs et de valeurs associées,
valeurs pouvant être requêtées (adaptées au stockage
de profils utilisateur)
1- Type orienté « Clé / Valeur » (1)
Exemple : DynamoDB (Amazon), Azure Table Storage (ATS), Redis, BerkeleyDB, Voldemort (LinkedIn)
1- Type orienté « Clé / Valeur » (2)
Chaque objet est identifié par une clé. 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 clé/valeur
La valeur peut être une chaîne de caractères, un objet
sérialisé, blob…
La donnée est opaque au système: il n’est pas possible d’y
accéder sans passer par la clef
L’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
Opérations se résumant surtout aux PUT, GET et DELETE
1- Type orienté « Clé / Valeur » (3)
Exemple : DynamoDB (Amazon), Azure Table Storage (ATS), Redis, BerkeleyDB, Voldemort (LinkedIn)
« Clé / Valeur » Usage principal
Dépôt de données avec besoins de requêtage très
simples
Système de stockage de cache ou d'information de
sessions distribuées
Persister des données
Les profils, préférences
d'utilisateur Les données de
panier d'achat
Les données de
« Clé / Valeur » Forces et Faiblesses
Forces :
modèle de données simple
bonne mise à l'échelle horizontale pour les lectures et
écritures : évolutivité (scalable)
disponibilité
pas de maintenances requises lors d'ajout/suppression
de colonnes
Faiblesses :
modèle de données TROP simple :
pauvre pour les données complexes
interrogation seulement sur clé
déporte une grande partie de la complexité de l'application
2- Type orienté « Document » (1)
Exemple : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (.Net)
2- Type orienté « Document » (2)
Étendent le paradigme clef/valeur, avec des « documents
» plus complexes à la place des données simples, et une
clef unique pour chacun d’eux
Un « Document » est de type JSON ou XML
Chaque Document est un objet, contient un ou plusieurs
champs, et chaque champs contient une valeur typée (string,
date, binary ou array)
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
2- Type orienté « Document » (3)
Exemple : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (.Net)
2- « Document » et Schema-less
uneCommande[« prix »] * uneCommande[« quantité »]
Schéma implicite
« Document » Usage principal
Enregistrement d'événements
Systèmes de gestion de contenu
Web analytique ou analytique
temps-réel Catalogue de produits
…
« Document » Forces et Faiblesses
Forces :
Modèle de données simple mais puissant (expression de
structures
imbriquées)
Bonne mise à l'échelle (surtout si le sharding est pris en
charge) Pas de maintenance de la BD requise pour
ajouter/supprimer des
«colonnes»
Forte expressivité de requêtagé (requêtes assez
complexes sur des structures
Faiblesses :
Inadaptée pour les données
interconnectées Modèle de requête limitée
« Document » vs « Clé-Valeur »
3- Type orienté « Colonne » (1)
Exemple : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google)
3- Type orienté « Colonne » (2)
Exemple : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google)
3- Type orienté « Colonne » (3)
Les données sont stockées par colonne,
non par
ligne
On peut facilement ajouter des colonnes
aux tables, par contre l'insertion d'une
ligne est plus coûteuse
Quand les données d'une colonne se
ressemblent, on peut facilement
compresser la colonne
Modèle proche d'une table dans un
SGBDR mais
ici le nombre de colonnes :
est dynamique
peut varier d'un enregistrement à un
3- Type orienté « Colonne » (4)
Exemple : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google)
« Colonne » Usage principal
Dépôt de données avec besoins de requêtage très
simples
Système de stockage de cache ou d'information de
sessions distribuées
Persister des données
Les profils, préférences
d'utilisateur Les données de
panier d'achat
Les données de
« Colonne » Forces et Faiblesses
Forces :
Modèle de données supportant des données semi-
structurées
Naturellement indexé
(colonnes) Bonne mise à
l'échelle à l'horizontale
Utilisation de MapReduce pour
le scaling horizontal, on peut
voir les
résultats de requêtes en temps
réel
Faiblesses :
4- Type orienté « Graph » (1)
Exemple : Neo4J et InfiniteGraph, OrientDB
4- Type orienté « Graph » (2)
Basées sur les théories des graphes
S’appuie sur les notions de noeuds, 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
Utilisent un moteur de stockage similaire à une base
documentaire
pour stocker les noeuds
4- Type orienté « Graph » (3)
Exemple : Neo4J et InfiniteGraph, OrientDB
« Graph » Usage principal
Moteurs de
recommandation
Semantic Web
Social computing
Données géo-
spatiales
Généalogie
Catalogue des
produits
Sciences de la Vie et calcul scientifique (bio-
informatique, …) Données liées, données
hiérarchiques
« Graph » Forces et Faiblesses
Forces :
Modèle de données puissant
Rapide pour les données liées, bien plus rapide que
SGBDR Modèles d'interrogation bien établis et
performants
Faiblesses :
Fragmentation (sharding) :
Même si elles peuvent évoluer assez bien
Le NoSQL et la Consistance
Caractéristiques SGDBR vs NoSQL
SGDBR :
ACID (Atomicité, Cohérence, Isolation, Durabilité)
(tout ou rien, les données doivent toujours être cohérentes entre
elles, pas d'interférences entre les transactions, les données
doivent être dans un état stable et cohérent)
NoSQL :
BASE (Basic Availability, Soft state, Eventually Consistent)
(le système doit toujours être accessible, l'état de la base de
données n'est pas garanti à un instant t, la cohérence des
données à un instant t n'est pas primordiale)
Exception NoSQL de type Graph (ACID)
Consistance vs Disponibilité
Consistance
Disponibilité
Le théorème de CAP (Brewer, 2000)
C : tous les nœuds
du système voient
exactement les
mêmes
données au même
moment
A : la perte de nœuds
n'empêche pas les
survivants de
continuer à
fonctionner
correctement, les
données restent
accessibles
P : le système
étant partitionné,
aucune panne moins
importante qu'une
Théorème de CAP expliqué
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 chances 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
Caractéristiques des bases NoSQL
Privilégient la Disponibilité
à la Cohérence (théorème
de CAP)
AP (Disponible + Résistant
au partitionnement) plutôt
que CP (Cohérent +
Résistant au
partitionnement)
Généralement n’intègrent
pas de gestion de
transactions
Mode d'utilisation :
NoSQL Atouts et Faiblesses
NoSQL - Atouts
Adapté au Big Data (grand volume, données structurées, semi-
structurées ou
non-structurées, données stockées et gérées à plusieurs endroits)
Disponibilité continue des données
Utilisent une architecture hautement distribuée
Indépendance de l’emplacement (Possibilité de consulter et
modifier une BD sans savoir où est-ce que ces opérations ont
réellement lieu)
Modèles de données flexibles
NoSQL - Faiblesses
Choix de NoSQL, en opposition aux bases de données
relationnelles, conduits par les contraintes du marché et les
besoins techniques
Il n’existe pas de langage de requêtage unifié (tel
que SQL) Requêtage moins expressif que SQL
Moins mature que les SGDBR (10aine d’années
vs 40+) Moins d’outils que les SGDBR
SQL est de retour - NewSQL
Exemple: SQL vs MongoDB
Exemple: MongoDB
Création d’une base de
données
use mabase ouvre la bdd ou la crée si elle n’existe pas
Créer une collections
d'acteurs
La création de la collection est
implicite, elle se fait à l'insertion
db.acteurs.insert({nom:"selmi", prenom:"mouna "})
du premier
document.
Rechercher un élément
db.acteurs.find(prenom:’mouna’)
Conclusion
Utilisez le bon modèle de données pour
le bon problème
