NoSQL : Not only SQL
๏ Inventé en 2009 pour les bases de données distribuées
๏ Terme vague et incorrect : certains sont des variantes du SQL
๏ Big Data : ensembles de données très volumineux
→ outils informatiques classiques dépassés
๏ Gestion et traitement des volumes de données
→ nouveau défi de l’informatique
Nouveaux besoins
๏
Essor des très grandes plateformes et applications Web
(Google, Facebook, Twitter, LinkedIn, Amazon, …)
๏
Distribution des données et leurs traitements sur de nombreux serveurs : « Data Centers »
๏
Objets complexes et hétérogènes
→
limites des SGBD R
๏
Nouvelles approches de stockage et de gestion des données
→ meilleure scalabilité dans des contextes distribués
→ objets complexes et hétérogènes
→ ne se substituant pas aux SGBD R mais comblant leurs faiblesses
Limites des SGBD
relationnels-transactionnels (1)
SGBD R
๏ Jointures entre tables pour des requêtes complexes impliquant plusieurs entités
๏ Intégrité référentielle permettant d’assurer la validité des liens entre entités
๏ Données liées entre elles placées sur le même nœud du serveur
๏ Si nombre de liens important, il est difficile de placer les données sur des nœuds différents
๏ → SQL : schéma fermé et performances faibles sur de gros volumes
Limites des SGBD
relationnels-transactionnels (2)
๏ SGBD R généralement transactionnels
๏ → Contraintes ACID
: Atomicité des transactions, Cohérence desdonnées, Isolation des modifications, Durabilité en cas de perte d’un disque
๏ Coût considérable pour les contextes fortement distribués
๏ ACID difficile à maintenir à l’échelle du système distribué tout en maintenant des performances correctes
→ La plupart des SGBD « NoSQL » relâchent les contraintes
ACID, ou même ne proposent pas de gestion de transactions
BD NoSQL
๏ Grande performance dans le contexte du Web avec des volumétries de données exponentielles
๏ Forte distribution des données et des traitements associés sur de nombreux serveurs ; réplication des données
๏ Pas de schéma pour les données ou schéma dynamique ; structures complexes ou imbriquées
๏ Peu d'écritures, beaucoup de lectures
Théorème de CAP
3 propriétés fondamentales pour les systèmes distribués :
๏ Consistence : les nœuds voient les mêmes données au même moment
๏ pour avoir une cohérence de 100%, les nœuds doivent communiquer
๏ plus il y a de répliques et plus les performances du système sont mauvaises
๏
Availability : la perte de nœuds n'empêche pas le fonctionnement๏ une réplication de la BD sur un autre serveur assure une disponibilité de 100%
๏ les répliques aident à équilibrer la charge d’opérations, notamment en lecture
๏ Partition tolerance : chaque sousréseau du système doit fonctionner de manière autonome
→ Théorème CAP (Brewer, 2000) : impossible d’avoir ces 3 propriétés en même temps
Théorème CAP
Fondements du NoSQL
๏ Sharding : partitionnement des données sur plusieurs serveurs pour assurer la scalabilité de l’architecture
๏ Consistent hashing : partitionnement horizontal dans lequel nœuds (serveurs) et objets (données) sont associés par une même fonction de hachage
๏ Map Reduce : (dvpé par Google) programmation parallèle sur un grand nb de serveurs : « split, compute, join ».
๏ Existe dans plusieurs langages (C++, C#, Java, Python)
๏ MVCC (Contrôle de Concurrence Multi-Version) : gère les accès simultanés avec mises-à-jour. Plusieurs versions enregistrées, une seule plus récente, balayage périodique pour supprimer les données obsolètes
๏ Vector-Clock : mises à jours concurrentes datant les données par des vecteurs d’horloge
Typologie
4 types de BD NoSQL
๏ Type clé-valeur : chaque objet est identifié par une clé unique constituant la seule manière de le requêter
๏ Type colonne : permet un grand nb de valeurs sur une même ligne, requêtes par clé, adapté au stockage de listes
๏ Type document : pour des 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
๏ Type graphe : pour gérer des relations multiples entre les objets, adaptés aux données issues de réseaux sociaux
Clé-valeur
๏ Couples clé–valeur, la valeur pouvant être une simple chaîne de caractères ou un objet
๏ Tables de hashage avec des entités généralement rapatriées à partir d’un identifiant et de tables partitionnées. Un hash choisit en fonction des clés et sélectionne l’instance en charge du stockage
๏ Le consistant hashing assure la répartition la plus égale possible des clés entre les partitions
๏ Modèles d’interrogations, la communication se résume à quelques opérations simples (crud : create, read, update, delete)
๏ Exemples : Voldemort (LinkedIn), SimpleDB (panier Amazon)
Colonne
๏ Grand nombre de colonnes (jusqu’à plusieurs millions) pour chaque ligne
๏ Organisées en familles de colonnes (super-colonnes : conteneurs de colonnes)
๏ Créer des colonnes dynamiquement uniquement pour les lignes concernées : nombre de colonnes varie selon les lignes
๏ Colonnes triées sur le disque pour obtenir un intervalle de colonnes (ou de super-colonnes) avec un nombre réduit d’accès aléatoires sur le disque
๏ Reconstruction de l’ensemble de la table de données sur le disque au fur et à mesure des modifications ! mise en œuvre efficace
๏ Système de requêtes minimaliste
๏ Repose sur le concept BigTable de Google
๏ Exemples : Hadoop (Facebook, Google, Microsoft, Wikitrends de
Document
๏ Collection de documents pouvant être très hétérogènes
๏ Exprimer un document structuré sous une forme hiérarchique : document composé de champs et valeurs associées
๏ Pour représenter des données structurées ou semi-structurées,
๏ Format de sérialisation et d’échange de données :
๏ JSON (JavaScript Object Notation)
๏ XML (Extensible Markup Language)
๏ Pas nécessaire de définir au préalable les champs utilisés
๏ Requêtes sur le contenu des documents, pas possible en clés-valeurs
๏ Une seule clé pour récupérer l’ensemble des informations de manière hiérarchique (plusieurs jointures en SQL ☹).
๏ Exemples pour sites Web : MongoDB (SourceForge.net, pages jaunes, NY Times) ou CouchDB.
Graphe
๏ Représentation de données basée sur la théorie des graphes (nœuds, relations et propriétés),
๏ Représenter le « monde réel » (cartographie, réseaux sociaux)
๏ Moteurs de recommandation, Business Intelligence, Web Sémantique
๏ Triplets RDF (Ressource Description Framework)
Sujet-Prédicat-Valeur : s = « le ciel », p = « a pour couleur »), v = « bleu »
๏ Possibilité de fusion de graphes
๏ Triplets RDF interrogés via le protocole/langage de requête SPARQL utilisant des ontologies pour inférer (W3C RDF Data Access)
๏ Exemple : Neo4J
Exemple : MongoDB (1/2)
๏ Libre
๏ Orienté documents au format BSON (binary JSON)
๏ Réplication et auto-sharding
๏ MapReduce
๏ Flexible, écrit en C++
๏ Langage MongoDB
๏ Mise-à-jour : db.collection.insert(), db.collection.update(), db.collection.save(), db.collection.findAndModify(),
db.collection.remove()
๏ Interrogation : db.collection.find(), db.collection.findOne()
Exemple : MongoDB (2/2)
๏ Requêtes spécifiques en JavaScript
๏ Pré-traitements (requêtes, agrégats, etc.) pour scinder les données par paquets et enchaîner des traitements dessus
๏ Traiter les données en passant par R (ou python)
๏ Un exemple d’agrégation (PFE Valentine Le Monnier de Gouville 2021) : nb de morceaux par playlist ainsi que score de popularité moyen :
$aggregate ( ’[
{ "$group" :
{ "_id" : { "playlist" : "$playlist.id" } , "nb_track" : { "$sum" : 1 } ,
"moy_popularity" : { "$avg" : "$track.popularity" } }
}