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