Bases de données NoSQL

publicité
Bases de données
NoSQL
Raja CHIKY
[email protected]
2016-2017
Institut Mines-Télécom
Plan
§ 
§ 
§ 
§ 
§ 
Typologie des bases de données NoSQL
Bases de données clé-valeur
Bases de données orientées colonne
Bases de données orientées document
Bases de données orientées graphe
Institut Mines-Télécom
Fausses et vraies idées autour du
NoSQL
Not
Only
NO SQL
Relational
Institut Mines-Télécom
NoSQL?
§  No SQL => Not Only SQL
§  SQL ne doit pas mourir mais des solutions de
stockage doivent être envisagées pour des
applications particulières (applications web en
particulier)
§  Nom exact: Bases de données non relationnelles
§  Le modèle ACID ne permet pas un passage à
l'échelle dans un environnement distribué, limitant
par exemple les débits en écriture (les plus
coûteux)
• 
• 
• 
• 
Atomicity
Consistency
Isolation
Durability
Institut Mines-Télécom
RDBMS
§  MySQL, PostgreSQL, SQLite, Oracle, etc.
§  Besoins:
• 
• 
• 
• 
• 
Schémas
Cohérence forte
Transactions
Matures et opérationnelles
Expertise disponible
Institut Mines-Télécom
Quand utiliser NoSQL
§  Grand volume de données
•  Besoin d'utiliser une architecture fortement distribuée
•  Google, Amazon,Yahoo, Facebook -10-100K serveurs
§  Requêtes massives
•  Eviter les jointures car très gourmandes en temps de
traitement
§  Schéma évolutif
•  Flexibilité et évolutivité du schéma à grande échelle
Institut Mines-Télécom
Nouveaux besoins
§  Applications web: explosion des données et des
requêtes
§  Latence: temps de réponse faible et prévisible
§  Passage à l'échelle et élasticité
§  Haute disponibilité
§  Schémas flexibles / données semi-structurées
§  Distribution géographique (multitude de
datacenters)
§  Pas besoin de : transaction/ forte cohérence/
intégrité/ requêtes complexes
Institut Mines-Télécom
NoSQL
§  Avantages
• 
• 
• 
• 
• 
• 
Passage à l'échelle
Haute disponibilité
Elasticité
Flexibilité du schéma
Gestion des données éparses (NULL) et semi-structurées
Evolutivité horizontale
§  Inconvénients
• 
• 
• 
• 
Pas de standards
Contrôle d'accès insuffisant
Requêtage limité
Applications client compliquées à cause de « Eventual
consistency »
Institut Mines-Télécom
Taxonomie NoSQL
Clé-Valeur
Graphe
Données
Colonnes
Institut Mines-Télécom
Document
Complexité
Institut Mines-Télécom
Comment peut-on faire des requêtes
dans une BD NoSQL?
§  Interfaces REST
•  HTTP via une API
§  Langages de requêtes basées sur SQL
• 
• 
• 
• 
• 
GQL – SQL-Like QL pour Google BigTable
CQL – Cassandra Query Language
SPARQL – langage de requête pour le Web sémantique
Gremlin, Cypher – langage de parcours d'un graphe
Sones Graph Query Language
§  API's de requêtage de données
•  GAE (Google Application Engine) API
•  Thrift API
•  Etc.
§  Map reduce
•  Pig, Hive, etc.
Institut Mines-Télécom
Rappels
§  SQL
} 
•  Universalité « One size
fits all »
•  Logique : schémas,
contraintes
•  Cohérence forte
•  Ressources limitées
•  Langage standard: SQL
•  Traitements centralisés
NoSQL
} 
Systèmes sur mesure
} 
Pas de schémas ni
contraintes
Cohérence « à terme »
Ressources « illimitées »
Langages spécialisés,
API
Traitements distribués
(mapReduce)
} 
} 
} 
} 
Institut Mines-Télécom
Limites du SGBDR
“ If the only tool you have is a hammer, you
tend to see every problem as a nail.”
Abraham Maslow
Institut Mines-Télécom
Limites du SGBDR
Institut Mines-Télécom
Bases de données clévaleur
Dynamo, Redis, Voldemort, …
Institut Mines-Télécom
Modèle clé-valeur
§  identification par une clé
unique, seule façon de
requêter les objets
§  structure de l’objet libre :
•  binaire, JSON, XML, chaine de
caractères
•  absence de structure ou de
typage
§  modèle de type table de
hachage distribuée
Institut Mines-Télécom
…
Clé
1
valeur
Clé
2
valeur
Clé
3
valeur
…
Clé/Valeur
§  Avantages
• 
• 
• 
• 
Très rapide
Passage à l’échelle
Modèle simple
Distribution horizontale très facile
§  Inconvénients
•  Interrogation seulement sur clé
•  Modèle de données trop pauvre pour les données
complexes
•  Déporte une partie de la complexité au niveau de
l’application
Institut Mines-Télécom
Cas d’usage
§  Adapté pour les applications « data intensive »:
•  le stockage des données avec identifiant unique :
─  sessions
─  profils, préférences utilisateur
─  panier d’achat
•  données avec des besoins de requêtage très simples (get
et put) avec des temps de réponse très rapides
§  Non adapté pour :
•  relations entre données, corrélations entre différents
ensembles de clés
•  opérations sur des ensembles (opérations limitées sur
une clé à la fois – déporté au niveau du client)
•  requêtes sur les données autre que la clé
•  transactions sur des opérations multiples
Institut Mines-Télécom
Dynamo
§  Amazon, 2007
§  Architecture P2P: DHT (Distributed Hash Table)
•  Versioning des objets
•  Algorithme de « Gossiping » (détection des échecs et des
adhésions)
•  Hachage cohérent
§  Exigences et hypothèses
• 
• 
• 
• 
• 
Modèle de requêtes simple (clés unique, blobs, pas de schéma)
Architecture décentralisée (P2P) et hétérogène
Faible latence / haut débit
Service interne (pas de modèle de sécurité)
Haute disponibilité
§  Dynamo est utilisé pour:
•  Le panier des achats, préférences des utilisateurs, gestion des
sessions, gestion des ventes, catalogue de produits
Institut Mines-Télécom
Partitionnement
§  Nœuds en cercle: position affectée aléatoirement
aux nœuds
§  Connexion/déconnexion d'un nœud n'affecte que
ses 2 voisins
§  Réplication: N réplicas (successeurs dans le cercle)
§  Versioning:
•  Stockage des mises à jour
•  Eventual consistency
•  Réconciliation des conflits effectuée par les clients (vector
clock)
Institut Mines-Télécom
Principales caractéristiques
§ 
Opérations :
• 
• 
• 
• 
Create (key, value) : créé un objet
Read (key) : lit un objet à partir de sa clé
Update (key, value) : met à jour un objet à partir de sa clé
Delete (key) : supprime un objet à partir de sa clé
§ 
Consistance : en général, consistance éventuelle
§ 
Transactions
• 
• 
pas de garantie sur les écritures
utilisation du concept de quorum (Exemple : facteur de réplication = 5, valeur
de W=3, on tolère que deux nœuds sur les 5 ne soient pas accessibles pour
l’opération d’écriture)
§ 
Requêtes sur clé uniquement
§ 
Très bonne scalabilité
• 
• 
scalabilité horizontale par sharding (répartition des données sur plusieurs
serveurs, chacun gérant ses propres données)
la valeur de la clé détermine le nœud où elle est stockée
Institut Mines-Télécom
Noeuds virtuels
§ 
Le problème avec les DHT
• 
• 
§ 
Noeuds placés alétoirement autour du cercle
Données non uniformément distribuées sur les noeuds
Dans Dynamo
• 
• 
• 
Utilise des noeuds virtuels
Chaque noeud physique dispose d’un certain nombre de noeuds
virtuels, le nombre dépend de sa capacité
Les noeuds virtuels sont distribués autour du cercle
Institut Mines-Télécom
Interface de requêtage Dynamo
§ 
§ 
Seulement 2 opérations implémentées
put (key, context, object)
• 
• 
• 
§ 
key: clé associée à un objet
context: vector clocks (historique)
object: l’objet à stocker
get (key)
Institut Mines-Télécom
Autre système: REDIS
Remote Dictionary Server
Projet open-source
Redis stocke les données en mémoire (In memory DB)
Possibilité de stocker des données sur disque (snapshot)
Au démarrage du service, dernier snapshot mis en
mémoire
§  Très performant
§  Utilisé par Twitter, Instagram, Stackoverflow, ask.fm, etc
§  Cas d’utilisation: Préférences des utilisateurs, stockage
des sessions, Statistiques et scores dans un jeu par
exemple, …
§ 
§ 
§ 
§ 
§ 
Institut Mines-Télécom
Installation
>wget http://download.redis.io/redis-stable.tar.gz
>tar xvzf redis-stable.tar.gz
>cd redis-stable
>make
>redis-server
>redis-cli redis 127.0.0.1:6379
> ping
PONG
>redis 127.0.0.1:6379> set mykey somevalue
OK
>redis 127.0.0.1:6379> get mykey
"somevalue"
http://try.redis.io/
Institut Mines-Télécom
Commandes utiles
§ 
Toutes les clés
>KEYS *
§ 
} 
>SET MyVar 10
>GET MyVar
>INCR MyVar
>INCRBY MyVar 10
Effacer toutes les clés
>FLUSHALL
§ 
Sauvergarder les données sur
disque
>SAVE
§ 
Expiration
>set a 1
>expire a 5
>get a
(…5secondes après)
§ 
Incrémentation
Multi-get
>set a 1
>set b 12
>mget a b
Institut Mines-Télécom
} 
Sauvegarde
>SAVE 30 1
- -sauvegarder après 30
secondes si au moins 1
clé est modifiée
Types de données: Strings
§  Max 512 MO
>SET counter 10
>INCRBY counter 100
>DECR counter
>APPEND counter 01
>GET counter
>INCR counter
Institut Mines-Télécom
Types de données: LIST
§  Liste de « Strings » triés
par ordre d’insertion
§  Longueur max: 2^32-1
§  Quelques commandes:
LPUSH, LRANGE,
RPUSH, LLEN
Institut Mines-Télécom
>DEL myList
>LPUSH myList un
>LPUSH myList deux
>LPUSH myList trois
>LPUSH myList quatre
>LRANGE myList 0 1
Types de données : SET
>SADD myset Hello
>SADD myset World
>SADD myset World
>SMEMBERS myset
>SISMEMBER myset World
>SISMEMBER myset Bonjour
Quelques commandes: SCARD, SDIFF,
SDIFFSTORE, SINTER, SINTERSTORE,
SMOVE,
Institut Mines-Télécom
Type de données: Hash
§  Map entre une chaîne de caractère et sa valeur
§  Par exemple: on veut stocker un utilisateur (son
id, login, mdp, age)
>HSET user1 ID "001"
>HSET user1 login "pseudo1"
>HSET user1 mdp "azerty"
>HSET user1 age "35"
>HGETALL user1
>HMSET user2 ID "002" login "pseudo2"
>HGET user2 login
Institut Mines-Télécom
Types de données: Sorted Set
§  Ensemble de données triées selon un score prédéfini
>ZADD myzset 1 "one"
>ZADD myzset 1 "uno "
>ZADD myzset 2 "two" 3 "three "
>ZRANGE myzset 0 -1 WITHSCORES
>ZINCRBY myzset 3 "one"
>ZRANGE myzset 0 -1
Institut Mines-Télécom
Autres caractéristiques
§  Publish/Subscribe
From: Kris Jeong, REDIS Intro
Institut Mines-Télécom
Autres systèmes
§  Voldemort: http://project-voldemort.com/
•  Créé en 2008 par LikedIn – Open-source
•  Implémenté en java, fournit des plugins pour Berkeley DB et
MySQL
•  Méthodes d’accès: Thrift, Avro et protobuf. Utilisable avec
Hadoop
§  Kyoto Cabinet: http://fallabs.com/kyotocabinet/.
•  Implémenta en C++, Licence GNU-GPL
•  Système de fichiers avec des paires (clé-valeur)
•  Méthods d’accès: API pour C, C++, Java, C#, Python, Ruby,
Perl, Erlang, Ocaml,…
§  Et aussi Riak, Kai, Membase, …
Institut Mines-Télécom
Principales caractéristiques
§ 
Opérations :
• 
• 
• 
• 
Create (key, value) : créé un objet
Read (key) : lit un objet à partir de sa clé
Update (key, value) : met à jour un objet à partir de sa clé
Delete (key) : supprime un objet à partir de sa clé
§ 
Cohérence : en général, consistance éventuelle
§ 
Transactions
• 
• 
pas de garantie sur les écritures
utilisation du concept de quorum (Exemple : facteur de réplication = 5, valeur de W=3,
on tolère que deux nœuds sur les 5 ne soient pas accessibles pour l’opération d’écriture)
§ 
Requêtes sur clé uniquement
§ 
Très bonne scalabilité
• 
• 
scalabilité horizontale par sharding (répartition des données sur plusieurs serveurs,
chacun gérant ses propres données)
la valeur de la clé détermine le nœud où elle est stockée
Institut Mines-Télécom
Téléchargement