NOSQL
Professeur : Habib Mlayah
C’est quoi le NOSQL ?
• Les bases de données SQL étaient la référence pour gérer les données
d’un SI dans les années 70.
• Face aux 3V du Big Data : Volume, Vitesse et Variété, le relationnel
peut difficilement se retrouver face à cette vague de donnée.
• Le NOSQL s’est naturellement imposé dans ce contexte en proposant
une nouvelle façon de gérer les données sans se reposer sur le
concept relationnel.
NOSQL
• NOSQL : Not Only SQL / Pas seulement du SQL
• Ce langage/approche propose de relâcher certaines contraintes
lourdes du relationnel pour favoriser la distribution (structure des
données, langage d’interrogation ou la cohérence)
• Le NoSQL est à la fois une autre manière d'interroger les données,
mais aussi de les stocker.
Les différentes familles du NOSQL
• Les besoins de stockage et de manipulation des données sont
différents et dépendent de l’application que nous souhaitons intégrer.
• Pour cela nous avons différentes familles de bases NOSQL
• Clé/Valeur
• Colonnes
• Documents
• Graphes
Chacune de ces familles est liée à un besoin très particulier
Les clés-valeurs 1/4
• Cette famille est très efficace et simple
où tout repose sur le couple Key/Value.
• Ce système se comporte comme une
table de hachage distribuée sur le
réseau.
• La valeur peut contenir n’importe quel
type de donnée.
Les clés-valeurs 2/4
• Le fait de pouvoir avoir n’importe quel type
de donnée => contrairement aux bases de
données relationnelles et au SQL
(Structured Query Language), nous n’aurons
ni schéma ni structure pour le stockage et
nous n’aurons ni la possibilité d’exploiter ni
de contrôler la structure des données =>
pas de langage.
• Cela ne constitue pas un problème si nous
savons ce qu’on recherche (via la clé) afin
de manipuler directement la valeur.
Table de hâchage
• Une table de hachage est, en
informatique, une structure de
données qui permet une
association clé–valeur, c'est-à-
dire une implémentation du type
abstrait tableau associatif.
• Un annuaire représenté comme
une table de hachage. La
fonction de hachage transforme
les clés (en bleu) en valeurs de
hachage (en rouge) indexant les
éléments de la table (alvéoles)
composés de paires clé–valeur
Source du schéma : Wikepedia
(en vert).
Les clés-valeurs 3/4
• Les opérations CRUD que nous pouvons utiliser pour cette famille :
• CREATE (Clé, valeur) => afin d’ajouter un nouveau couple clé/valeur
• READ (Clé) => afin de lire/d’afficher une valeur(une donnée)
• UPDATE (Clé, Valeur) => afin de mettre à jour une valeur
• Delete (Clé) => afin de supprimer une valeur
Les clés-valeurs 4/4
• Exemples d’utilisation :
• Fichiers de logs
• Chat
• Détection de fraude en live
• Gestion de cache
• Transaction
Source document : [Link]
Colonnes 1/5
• D’une façon générale, nous avons
l’habitude d’avoir les données en
ligne (les tuples en SQL), Dans
chaque ligne nous avons les
données des attributs d’une entité.
• Le stockage par colonne change la
donne => nous nous focaliserons
beaucoup plus sur chaque attribut.
Source du schéma : blent,ai
Colonnes 2/5
• Nous pouvons voir cela
comme une extension des
tables relationnelles.
• Néanmoins, les colonnes ne
sont pas fixes pour chaque
ligne.
• Nous pourrons focaliser les
requêtes sur une (ou même
plusieurs) colonne(s) sans
avoir à ajouter des
informations qui ne vont pas
servir.
Source document : [Link]
Colonnes 3/5
• Avantages :
• Effectuer des traitements complexes sur des colonnes (Moyenne, comptage ….)
• Effectuer de gros calculs analytiques
• Avoir plus d’espace de stockage (nous renseignons uniquement au sein de la colonne les données
qui nous intéressent)
• Nous n’aurons plus besoin de faire des jointures entre les tables (les jointures comme en SQL).
• Permet d’historiser beaucoup plus facilement
• Nous utilisons cette famille lorsque les données sont très volumineux et de nombreux évènements
pourraient arriver (comportement des utilisateurs ect…)
Colonnes 4/5
• Principal inconvénient :
Cette solution n’est pas du tout appropriée pour la lecture de données
spécifiques (par exemple avoir toutes les données d’un trader en
partant de son ID en SQL ou comme pour les clés/valeurs en NOSQL).
Colonnes 5/5
• Exemples d’utilisation :
• Election/Notation en ligne
• Recherche de produits dans une
catégorie (option dans titres
dérivés)
Source document : [Link]
• Reporting à grande échelle
Bases orientées documents 1/4
• Cette famille repose sur le principe de
Clés/valeurs mais avec une extension
sur les champs qui composent le
document.
• Cette famille ressemble à ce que nous
avons dans une base de données
classique pour des requêtes
complexes.
• Le but de ce type de stockage est de
manipuler des documents contenant
des informations avec une structure
complexe (listes, imbrications, types)
Source document : [Link]
Bases orientées documents 2/4
• Intérêt pour utiliser cette famille :
• Avoir une approche structurée de chaque valeur formant ainsi un document
• Ces solutions proposent des langages d’interrogation riches permettant de
faire des manipulations complexes sur chaque attribut du document et même
sous document comme dans une base de donnée traditionnelle tout en
passant à l’échelle dans un contexte distribué, dans un environnement
relationnel, cela nécessiterait plusieurs jointures
• On les utilise lorsqu’il n’y a pas de relations entre les documents et les
collections
Bases orientées documents 3/4
• Inconvénient principal :
• Elles ne sont ni adaptées pour les données interconnectées ni pour
les données non-structurées
Bases orientées documents 4/4
• Exemples d’utilisation :
• Les données clients (Stockage de
toutes mes transactions et
données client au sein d’un
même document (même clé)
• Web analytics
• Gestion catalogue produit
Source document : [Link]
Graphes 1/4
• Les précédentes familles NoSQL
n'adressent pas le problème de
corrélations entre les éléments.
Prenons l'exemple d'un réseau
social : dans certains cas, il
devient très complexe de calculer
la distance entre deux personnes
non directement connectées. Et
c'est ce type d'approche que
résolvent les bases orientées
Graphe.
Source document : [Link]
Graphes 2/4
• Avantages :
• De nombreuses jointures entre différentes entités(tables) sont
indispensables dans une base de données relationnelle, cela complexifie
les requêtes à mettre en place et augumente le temps de calcul comparé à
une base NoSQL famille des graphes,
• Adaptées aux objets complexes organisés en réseaux, aux données
présentant des dépendances fortes
• Permettent d’appliquer les algorithmes de théorie des graphes et la mise
en place de visualisation de graphes nativement
• Beaucoup plus rapides que les autres systèmes de stockage pour manipuler
les données fortement connectées
Graphes 3/4
• Inconvénient principal :
Non adaptées pour tous les autres contextes que celui des “données
fortement connectées”
Graphes 4/4
Exemples d’utilisation :
• Modélisation des données provenant des
réseaux sociaux (Twitter, Facebook…)
• Moteur de recommandation (vous êtes
sûrement intéressés par tel ou tel objet car
beaucoup de vos amis et des amis de vos
amis le sont aussi)
• Détection de la fraude organisée (détection
de réseaux de fraude)
• Catalogue de produits
• Données géo spatiales (réseaux ferrés etc..)
• Web sémantique
Source document : [Link]
• Biologie