NoSQL

Introduction aux bases de données NoSQL
Khaled Tannir
[email protected]
Montréal - 01 Décembre 2015
Qui suis-je?
Khaled TANNIR
Big Data Architect Lead
20 ans d’expérience
Auteur / Author
[email protected]
01 Décembre 2015
Relecteur Technique / Technical reviewer
Introduction aux base de données NoSQL
Sommaire
Les besoins en gestion des données
Modèles des données des bases NoSQL
Le NoSQL et la Consistance
NoSQL – Atouts et Faiblesses
Les besoins en gestion de données
Demande au niveau des données
Beaucoup de données
Solutions possibles
SQL
SQL
Limites des SGDBR
Le volume des données augmente considérablement
Les données sont souvent de nature hétérogène
Cette volumétrie nécessite une distribution des
données
Difficulté d’intégration dans les SGDBR existant
Complexité ascendante de la mise à l’échelle
Il faut trouver une solution
Un nouveau système permettant :
Une meilleure mise à l’échelle (scalabilité) dans des
contextes fortement distribués
Permettre une gestion simplifiée et meilleure de
données hétérogènes
Création de systèmes complémentaires aux SGDBR
adressant leurs limites sans pour autant les remplacer
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)
« Graphe / Graph » : pour gérer des relations multiples entre les objets
(adaptés au données issues de réseaux sociaux, …)
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
Fournir un accès rapide aux informations
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 capteur
Les logs de données
…
« 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 sur la
couche application elle-même
2- Type orienté « Document »
Exemple : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (.Net)
(1)
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 ensemble
d’informations structurées de manière hiérarchique
Dans un SGDBR, cela impliquerait plusieurs jointures
2- Type orienté « Document »
Exemple : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (.Net)
(3)
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 à des clés (et indexes)
Peut alors être lent pour les grandes requêtes (avec MapReduce)
« Document » vs « Clé-Valeur »
3- Type orienté « Colonne »
Exemple : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google)
(1)
3- Type orienté « Colonne »
Exemple : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google)
(2)
3- Type orienté « Colonne »
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 autre
ce qui évite de retrouver des colonnes ayant
des valeurs NULL
(3)
3- Type orienté « Colonne »
Exemple : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google)
(4)
« 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 capteur
Les logs de données
…
« 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 :
A éviter pour des données interconnectés (comme la distance ou
calculs de la trajectoire)
A éviter pour les lectures de données complexes
Exige de la maintenance - lors de l'ajout / suppression de colonnes et
leur regroupements
4- Type orienté « Graph »
Exemple : Neo4J et InfiniteGraph, OrientDB
(1)
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
Utilisent un mécanisme de description dʼarcs (relations entre les
noeuds), arcs orientés et avec propriétés (nom, date, ...)
4- Type orienté « Graph »
Exemple : Neo4J et InfiniteGraph, OrientDB
(3)
« 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
Services de routage, d'expédition et de géolocalisation
Services financiers : chaîne de financement, dépendances, gestion des
risques, détection des fraudes, …
…
« 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
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 coupure totale du
réseau ne doit l'empêcher
de répondre correctement
(Brewer, 2000)
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 système de
stockage ne doit pas être partitionné. D’où violation de la Tolérance au
partitionnement.
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 : peu
d'écritures, beaucoup de
lectures
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 openclassrooms
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 du premier
document.
db.acteurs.insert({nom:"Johansson", prenom:"Scarlett"})
Rechercher un élément
db.acteurs.find(prenom:’Scarlett’)
Conclusion
Utilisez le bon modèle de données pour le bon
problème
Merci pour votre attention!