ISET Djerba

CHAP 4 : NoSQL

Enseignant : Abdelhakim TRAOULI

 Il était une fois : SQL
Modèle de données relationnel
 Il était une fois : SQL
SQL
 Un langage de requête plus ou moins normé.
 Tout information est décrite par des listes de n-uplets
 Opérations puissantes :
 Sélection (where)
 Projection (select)
 Produit cartésien (join)
 Union
 Intersection
 Différence
 Transactions ACID
Atomique (Atomic)
• Pas de modification partielle : Une transaction est une unité logique de travail qui doit être
achevée soit avec la totalité de ses modifications de données ou aucune d'entre elles n'est
effectuée.

Cohérente (Consistant)
• A la fin de la transaction, les données doivent être dans un état cohérent.
• Assuré par les contraintes d’intégrités.

Isolées
• Les modifications d’une transaction doivent être indépendantes des autres transactions : Les
modifications ne sont pas visibles par les autres tant que la transaction n’a pas été validée.

Durable
• Une fois validés, les données sont permanentes jusqu’à leur prochaine
modification.
 Il était une fois : SQL
Marché mature
 Utilisé depuis des dizaines d’années
 De nombreux fournisseurs et de nombreux outils :
– Oracle
– SQL Server
– Mysql
– Postgresql
– MariaDB (clone de Mysql)
– MS Access
 Bases de données relationnelles

• Entités – relation
Modèle • Simple
• Universel

• SQL
Requête
• Puissant

Transaction • ACID

• Utilisé massivement
Maturité • Nombreux moteurs sur le marché
• Nombreux outils
Mise en œuvre d’un SGBD-R (1/4)
Mise en œuvre d’un SGBD-R (2/4)
Mise en œuvre d’un SGBD-R (3/4)
Mise en œuvre d’un SGBD-R (4/4)
 Montée en charge difficile
• Les règles d’intégrité compliquent la montée horizontale
• Montée en charge verticale:
 Coût non linéaire
 Atteint une limite
 Point unique de défaillance
 Limites des SGBD classiques
• SGBD Relationnels offrent :
– Un système de jointure entre les tables permettant de construire des requêtes
complexes impliquant plusieurs entités.
– Un système d’intégrité référentielle permettant de s’assurer que les liens entre les
entités sont valides.
• Contexte fortement distribué : Ces mécanismes ont un coût considérable :
– Avec la plupart des SGBD relationnels, les données d’une BD liées entre elles sont
placées sur le même nœud du serveur.
– Si le nombre de liens important, il est de plus en plus difficile de placer les données sur
des nœuds différents.
• SGBD Relationnels sont généralement transactionnels ⇒ Gestion de transactions
respectant les contraintes ACID (Atomicity, Consistency, Isolation, Durability).
 Limites des SGBD classiques
 Essor des très grandes plate-formes et applications Web (Google, Facebook, Twitter, LinkedIn,
Amazon,...).
 Volume considérable de données à gérer par ces applications nécessitant une distribution des
données et leur traitement sur de nombreux serveurs.
 Ces données sont souvent associées à des objets complexes et hétérogènes.
⇒ Limites des SGBD traditionnels (relationnels et transactionnels) basés sur SQL.
⇒ D’où, nouvelles approches de stockage et de gestion des données :
 Permettant une meilleure scalabilité dans des contextes fortement distribués.
 Permettant une gestion d’objets complexes et hétérogènes sans avoir à déclarer au
préalable l’ensemble des champs représentant un objet.
 Regroupées derrière le terme NoSQL (Not Only SQL), proposé par Carl Strozzi, ne se
substituant pas aux SGBD Relationnels mais les complètant en comblant leurs faiblesses.
 Limites des SGBD classiques
• Nécessaire de distribuer les traitements de données entre différents serveurs.
• Difficile de maintenir les contraintes ACID à l’échelle du système distribué entier 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.
 BDs non-relationnelles et largement distribuées.
 Permet une analyse et une organisation rapides des données de très grands volumes et de
types de données hétérogènes.
 Appelées également :
― Cloud Databases.
― Non-Relational Databases.
― Big Data Databases...
 Pourquoi NoSQL ? (1/3)
Big User :
 Pourquoi NoSQL ? (2/3)
Big Data (Gros volumes de données + variété) :
 Pourquoi NoSQL ? (3/3)
Montée en charge (1/2) :
 Pourquoi NoSQL ? (3/3)
Montée en charge (2/2) :
 SGBD NoSQL (1/3)
 Définition:
– SGBD non fondé sur l’architecture des SGBDR, open source, distribué, horizontally scalable
(montée en charge par ajout de serveurs)
 Origine:
– « Les SGBDR en font trop, alors que les produits NoSQL font exactement ce dont vous avez
besoin » selon J. Travis (lors du meetup NoSQL de San Francisco du 2009)
– Gestion des BD géantes des sites web de très grande audience
– Exemple des SGBD d’annuaires : grande majorité des accès aux BD consistent en lectures sans
modification (ainsi, seule la persistance doit être vérifiée)
 « Consensus » actuel:
– Les SGBD NoSQL ne replacent pas les SGBDR mais les complètent en palliant leurs faiblesses
 UnQL (Unstructured Query Language):
– 2011 : début d’une spécification d’un langage de manipulation standardisé (pour formaliser le
requêtage des collections des BD NoSQL)
 SGBD NoSQL (2/3)
 Simplification en renonçant aux fonctionnalités classiques des SGBDR :
– Redondance (via réplication)
– Pas forcément de schéma normalisé, initialement voire à terme
– Pas de tables mais des collections
– Rarement du SQL (L4G déclaratif, complet au sens de Turing depuis SQL-99) mais API
simple ou langage spécialisé
– Pas forcément de jointure mais multiplication des requêtes, cache/réplication/données
non normalisées, données imbriquées
– Transactions pas forcément ACID mais plutôt BASE
– P s’impose pour un système distribué : AP (accepte de recevoir des données
éventuellement incohérentes) voire CP (attendre que les données soient cohérentes)
 SGBD NoSQL (3/3)
• Gestion des mégadonnées (big data) du web, des objets connectés, etc.
• Structure des données hétérogène et évolutive
• Données complexes et pas toujours renseignées
• Environnement distribué : données répliquées et accédées d’un peu partout (dans le monde),
traitement répartis
• Techniques de partionnement des BD : sharding, hachage cohérent (consistent hashing)
• Contrôle de concurrence multi-version (Multi-Version Concurrency Control (MVCC))
– Modification d’une donnée non par écrasement des anciennes données par les
nouvelles mais en indiquant que les anciennes données sont obsolètes et en ajoutant
une nouvelle version (seule la plus récente étant correcte) … ce qui nécessite une purge
régulière des données obsolètes
• Performances linéaires avec la montée en charge (les requêtes obtiennent toujours aussi
rapidement une réponse)
 BASE
• L'acronyme de BASE a été définie par Eric Brewer, qui est également connu pour formuler le
théorème CAP. Le théorème CAP affirme que tout système à état partagé en réseau ne peut avoir
que deux des trois propriétés désirables.
• Néanmoins, en gérant explicitement les partitions, les concepteurs peuvent optimiser la
cohérence et la disponibilité, atteignant ainsi un compromis des trois.
• Propriétés BASE:
– Basically Available: le système doit toujours être accessible (ou indisponible sur de courtes périodes)
– Soft state: l’état de la BD n’est pas garanti à un instant donné (les mises à jour ne sont pas
immédiates : cf. cohérence à terme)
– Eventual consistency: la cohérence des données à un instant donné n’est pas primordiale (mais
assurée à terme : verrouillage optimiste en reportant à plus tard la vérification de l’intégrité)
• Les systèmes étendus modernes et à grande échelle, y compris le cloud, utilisent l’approche BASE
combinée par l’approche ACID.
 ACID vs BASE
ACID BASE
• Atomique • Basiquement diponible
• Cohérent • Souple état
• Isolé • Eventuelle consistence
• Durable

• Cohérence forte • Cohérence faible

• Transactions • Procédure de réconciliation
• Schéma • Pas de schéma
• Évolutions difficiles • Évolutions faciles
• Rapide
• Favorise la disponibilité
 Théorème CAP (1/3)
Consistency • Après la modification d’une donnée, tous les
(Cohérence) clients lisent la nouvelle valeur

Avalibility • Le système répond toujours aux requêtes

(Disponibilité) dans un temps borné (timeout)

Partition • Le système continue à fonctionner si le réseau qui

Tolerance relie les nœuds est scindé en deux.
(Tolérance aux • La chute d’un nœud est une forme particulière de
pannes) partition.

Théorème CAP :
« You can have at most two of these properties for any sharded-data system. »
Eric A. Brewer — 19 juillet 2000
 Théorème CAP (2/3)
 En théorie, il est impossible de satisfaire à toutes les 3 exigences.
 CAP oblige un système distribué de suivre 2 des 3 exigences.
 Par conséquent, tous les bases de données actuelles NoSQL suivent les différentes
combinaisons de C, A, P du théorème CAP.
 Voici une brève description des trois combinaisons CA, CP, AP :
– CA – Situés dans un cluster unique, tous les nœuds sont toujours en contact.
Lorsqu'une partition se produit, le système bloque.
– CP - Certaines données peuvent ne pas être accessibles, mais le reste est toujours
conforme/précis.
– AP - Le système est toujours disponible sous le partitionnement, mais quelques-unes
des données renvoyées peuvent être inexacts/imprécises.
Théorème CAP (3/3)
 NoSQL Catégories - Présentation

• Il existe quatre types courants des bases de données NoSQL. Chacune de ces
catégories a ses spécifiques attributs et limites. Il n'y a pas une solution qui est
mieux que tous les autres, mais il y a certaines bases de données qui sont mieux
pour résoudre à certains problèmes.
• Afin de clarifier les bases de données NoSQL, nous discuterons les catégories les
plus courantes :
– Clef-valeur
– Bases orientées colonnes
– Bases orientées documents
– Graphe
 NoSQL Catégories - Clef-valeur
(1/6)
 Définition:
– BD = 1 tableau associatif unidimensionnel
– Le stockage clé-valeur est le type le plus élémentaire de base de données NoSQL.
– Chaque objet de la base représenté par un couple (clé,valeur) est identifié par une clé unique qui est
le seul moyen d’accès à l’objet
– Les clés sont triées en ordre lexicographique
 Opérations:
– Les 4 opérations CRUD :
• create(clé,valeur) : crée un couple (clé,valeur)
• read(clé) : lit une valeur à partir de sa clé
• update(clé,valeur) : modifie une valeur à partir de sa clé
• delete(clé) : supprime un couple à partir de sa clé
– Souvent interface HTTP REST disponible depuis n'importe quel langage
NoSQL Catégories - Clef-valeur (2/6)
 Cas d’utilisation:
– Dépôt de masses de données avec des besoins de requêtage simple
pour des analyses en temps-réel: sessions web et fichiers de log,
profils utilisateurs, données de capteurs, contenu du panier de
shopping, etc.
 Logiciels:
– Amazon Dynamo (Riak est l’implémentation open source).
– Redis (projet sponsorisé par VMWare).
– Oracle NoSQL Database
NoSQL Catégories - Clef-valeur (3/6)

Critiques
 Simple / Répartition facile  Interrogation seulement sur la clé
 Très performant / Requêtes  Complexité des valeurs à gérer
optimales à temps constants / dans les programmes
Performances prédictibles  Toutes les jointures doivent être
 Disponibilité faites dans le code
 Bonne mise à l’échelle /  Pas de contraintes
Evolutivité des valeurs  Pas de triggers
NoSQL Catégories - Clef-valeur (4/6)
Schéma des données
NoSQL Catégories - Clef-valeur (5/6)
Exemple 1 :
NoSQL Catégories - Clef-valeur (6/6)
Exemple 2 :
 NoSQL Catégories - Orientées
colonnes (1/8)

 Données stockées en colonnes.

 C’est une évolution de la BD clé/valeur.
 La colonne est l’entité de base représentant un champ de donnée, chaque colonne est définie par
un couple (clé,valeur) avec une estampille (pour gérer les versions et les conflits)
 Une super-colonne est une colonne contenant d’autres colonnes
 Une famille de colonnes regroupe plusieurs colonnes ou supercolonnes où les colonnes sont
regroupées par ligne et chaque ligne est identifiée par un identifiant unique et par un nom unique
 Les stockages orientés colonnes peuvent améliorer les performances des requêtes car ils peuvent
accéder à des données spécifiques d’une colonne.
 Modèle proche d’une table dans un SGBDR mais ici le nombre de colonnes :
― est dynamique.
― peut varier d’un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des
valeurs NULL.
 NoSQL Catégories - Orientées
colonnes (2/8)
 Cas d’utilisation:
– Analyse de données, traitement analytique en ligne (OnLine Analytical Processing
(OLAP)), exploration de données (data mining), entrepôt de données (data
warehouse), gestion de données semi-structurées, journalisation d’événements
et de compteurs, analyses de clientèle et recommandation, stockage de listes
(messages, posts, commentaires, ...), traitements massifs
– Ex. : Netflix (logging et analyse de sa clientèle), eBay Inc. (optimisation de la
recherche)
 Logiciels:
– BigTable, HBase, Cassandra, SimpleDB
 NoSQL Catégories - Orientées
colonnes (3/8)
Critiques
 Bonne mise à l’échelle horizontale.  Ne supporte pas les données
 Efficace avec l’indexation sur les structurées complexes ou
colonnes et pour des requêtes temps- interconnectées.
réel connues à l’avance.  Maintenance nécessaire pour la
 Supporte des données tabulaires à
modification de structure en colonne.
schéma variable et des données semi-
 Ajout de ligne couteux.
structurées (facile d’ajouter/fusionner
des colonnes et d’ajouter une  Requêtes doivent être pré-écrites.
colonne/super-colonne à n’importe  Toutes les jointures doivent être faites
quelle ligne d’une colonne/super-
dans le code
colonne).
 Nombre de colonnes dynamique  Pas de contraintes
(variable d’un enregistrement à un  Pas de triggers
autre permettant d’éviter les
indéterminations)
NoSQL Catégories - Orientées
colonnes (4/8)
NoSQL Catégories - Orientées
colonnes (5/8)
NoSQL Catégories - Orientées
colonnes (6/8)
 NoSQL Catégories - Orientées
colonnes (7/8)

 Une colonne pourrait rassembler plusieurs données stockées dans des lignes
qui s'étendent sur plusieurs tables d'une base de données relationnelle.
NoSQL Catégories - Orientées
colonnes (8/8)
 NoSQL Catégories -
Orientées documents

 BD = collection de documents.
 Modèle clé-valeur où la valeur est un document (lisible par un humain) au format semi-
structuré hiérarchique (XML, YAML, JSON ou BSON, etc.)
 Document (structure arborescente) = collection de couples (clé,valeur)
― Un document est un ensemble de clé-valeur où la clé permet d'accéder à sa valeur.
 Valeur de type simple ou composée de plusieurs couples (clé,valeur)
 Les documents ne sont pas généralement forcés d'avoir un schéma. Ils sont donc flexibles
et faciles à modifier.
 Pouvoir de récupérer, via une seule clé, un ensemble d’informations structurées de
manière hiérarchique
― Dans les bases relationnelles, cela impliquerait plusieurs jointures.
 NoSQL Catégories - Orientées
documents
 Cas d’utilisation:
– Outils de gestion de contenu (Content Management
System (CMS)), catalogues de produits, web analytique,
analyse temps réel, enregistrement d’événements,
stockage de profils utilisateurs, systèmes d’exploitation,
gestion de données semi-structurées
 Logiciels:
– CouchDB, RavenDB, MongoDB, Terrastore
 NoSQL Catégories - Orientées
documents
Critiques
 Performances élevées interrogations par le contenu
 Bonne mise à l’échelle des documents.
 Modèle simple augmenté de la  Limité aux données
richesse des documents semi- hiérarchiques, inadapté pour
structurés. les données interconnectées,
 Expressivité des requêtes baisse des performances pour
 Schéma de BD évolutif, efficace de grandes requêtes.
pour les interrogations par clé  Toutes les jointures doivent
être faites dans le code
 Pas de contraintes
 Pas de triggers
 Peut être limité pour les
NoSQL Catégories - Orientées
documents
Schéma des données
NoSQL Catégories - Orientées
documents
 NoSQL Catégories - Orientées
documents

 Un document JSON pourrait, par exemple, prendre toutes les données stockées
dans une ligne qui s'étend sur 20 tables d'une base de données relationnelle et
de les regrouper dans un seul document/objet.
 NoSQL Catégories -
Graphe

 Une base de données de type graphe stocke les données dans un graphe.
 Elle est basée sur les théories des graphes.
 Elle est capable de représenter élégamment n'importe quel type de données d'une
manière hautement accessible.
 Chaque nœud représente une entité (comme un étudiant ou une entreprise) et
chaque arc représente un lien ou relation entre deux nœuds.
 Quand le nombre de nœuds augmente, le coût d'une étape local (ou hop) reste le
même.
 Adapté aux traitements des données des réseaux sociaux.
 NoSQL Catégories - Graphe

 Cas d’utilisation:
– Moteurs de recommandation, informatique décisionnelle, web sémantique,
internet des objets (internet of things (IoT)), sciences de la vie et calcul
scientifique (bioinformatique, …), données géospatiales, données liées,
données hiérarchiques (catalogue des produits, généalogie, …), réseaux
sociaux, réseaux de transport, services de routage et d’expédition, services
financiers (chaîne de financement, dépendances, gestion des risques,
détection des fraudes, …), données ouvertes (open data)
 Logiciels:
– Neo4J, OrientDB, Titan
NoSQL Catégories - Graphe
 NoSQL Catégories - Graphe
Critiques
 Modèle riche et évolutif  Répartition des données
 Bien adapté aux situations peut être problématique
où il faut modéliser pour de gros volumes de
beaucoup de relations. données, fragmentation
 Nombreux langages et API (sharding)
bien établis et performants
NoSQL Catégories - Graphe
Schéma des données
NoSQL Catégories - Graphe
 NoSQL Catégories - Graphe
Exemple 2 :