Les bases de données
NoSQL
Dr. Houda EL BOUHISSI M1 GL
Historique
Les BD NoSQL remettent en cause l'hégémonie des SGBDR telle qu'elle s'est constitué dans
les années 1980. Les BD NoSQL sont essentiellement un retour à des modèles de données
antérieurs à cette hégémonie, telles que les représentations hiérarchique ou réseau qui
existaient dans les années 60.
Définition du NoSQL
Le NoSQL regroupe de nombreuses bases de données, récentes pour la plupart, qui se
caractérisent par une logique de représentation de données non relationnelle et qui
n'offrent donc pas une interface de requêtes en SQL.
NoSQL signifie Not Only SQL et non pas No SQL, il s'agit de compléments aux SGBDR
pour des besoins spécifiques et non de solutions de remplacement.
Les bases NoSQL se fondent sur une approche dite schema-less, c'est à dire sans schéma
logique défini a priori.
L'équivalent du CREATE TABLE en SQL n'est soit pas nécessaire, soit même pas possible ; on
peut directement faire l'équivalent de INSERT INTO.
BD NOSQL (Not Only SQL)
Ce n’est pas (comme son nom le laisse supposer) No SQL (pas de SQL)
• Bases de données non-relationnelles et largement distribuées
• Permet une analyse et une organisation rapides et ad-hoc des données de
très grands volumes et de types de données disparates
• Appelées également :
Cloud Databases
Non-Relational Databases
Big Data Databases
• Développées en réponse à l’augmentation exponentielle des données
générées, enregistrées et analysées par les utilisateurs modernes et leurs
applications.
BD NOSQL : Atouts et caractéristiques
Évolutivité
Disponibilité
Tolérance aux fautes
Modèle de données sans schéma
Architecture distribuée
Utilisation de langages et interfaces qui ne sont pas
uniquement du SQL
De point de vue métier, utiliser un environnement BigData et
NOSQL fournit un avantage compétitif certain
Acteurs du NoSQL
● Amazon : DynamoDB, SimpleDB
● Microsoft : Azure Table Storage
● Google : BigTable, Datastore, GFS
● Apache : CouchDB, Cassandra, Hadoop /HBase
● Beaucoup de start-ups...
Taxonomie des BD NoSQL
1/ BD NoSQL Clé-Valeurs
BD NoSQL Clé-Valeurs - Avantages
BD NoSQL Clé-Valeurs - Exemples
BD NoSQL Clé-Valeurs - Exemple
2/ BD NoSQL Orientées Colonnes
Évolution de la BD clef/valeur
Ressemble aux SGBDR, mais avec un nombre de colonnes dynamique,
différent d’un enregistrement à un autre (pas de colonnes portant les
valeurs NULL)
Offrent de très hautes performances et une architecture hautement
évolutive
Exemples: Hbase (Hadoop), Cassandra (Facebook, Twitter),
BigTable(Google)
2/ BD NoSQL Orientées Colonnes
3/ BD NoSQL Orientées documents
Étendent le paradigme clef/valeur, avec des « documents » plus
complexes à la place des données simples, et une clef unique pour chacun
d’eux
Documents 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 les bases
relationnelles, cela impliquerait plusieurs jointures
3/ BD NoSQL Orientées document : Exemple
3/ BD NoSQL Orientées Documents : Exemple
4/ BD NoSQL Orientées Graphes
Basées sur les théories des graphes
S’appuie sur les notions de nœuds, 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
Exemples : Neo4J et InfiniteGraph, OrientDB
4/ BD NoSQL Orientées Graphes
Types de BD NoSQL : Comparaison
Illustration des modèles NoSQL
Représentation de ventes en document
Représentation de ventes en relationnel
Illustration des modèles NoSQL
Représentation de ventes en relationnel Représentation de ventes en colonne
Illustration des modèles NoSQL
Représentation de ventes en relationnel Représentation de ventes en graphe
BDR Vs NoSQL
Toutes les BDR (Bases de données Relationnelles) supportent les transactions ACID :
A : Atomicité : Soit toutes les instructions sont exécutées, soit aucune
C : Consistance : toute transaction amène la BD d’un état valide à un autre renforcée
par les contraintes d’intégrité et les clefs étrangères
I : Isolation : Même si plusieurs transactions peuvent être exécutées par un ou plusieurs
utilisateurs simultanément, une transaction ne devrait pas voir les effets des autres
transactions concurrentes
D : Durabilité : Une fois la transaction enregistrée dans la base (commit ), ces
changements sont persistants.
Mais :
Données de plus en plus volumineuses + Besoin de systèmes évolutifs
Besoin de BD distribuées sur le réseau, pour une évolutivité horizontale
BDR Vs NoSQL
JSON = JavaScript Object Notation ?
