Université Aube Nouvelle

Base de données NoSQL

Not Only SQL

[Link] NIBENAON Tel : 61275837 / 67662595 @mail : nibenaons@[Link]

Introduction aux systèmes NoSQL (Not Only SQL)
1. De nouveaux besoin en gestion de données
• Nouveaux besoins en gestion de données
• Limites des SGBD Relationnels-transactionnels
• Le théorème de Brewer ou de CAP
• Le grand paysage des bases de données
2. Introduction aux systèmes NoSQL
• Les grands principes des systèmes NoSQL
• Typologie des systèmes NoSQL
• Quelques systèmes NoSQL
• Introduction au NoSQL
• Fondements des systèmes NoSQL : MVCC, Vector-clock »
• Typologie des BD NoSQL
3. Modèle NoSQL « Clé-Valeur »
4. Modèle NoSQL « Colonne »
5. Modèle NoSQL « Document »
6. Modèle NoSQL « Graphe »
1
 Notion Data center
• Utilisent des LANs (Local Area Networks) avec 3 niveaux de communication :

! Les serveurs sont regroupés en « Racks » : liaison réseau rapide, environ 1Go/sec

! un « Data center » consiste en un grand nombre de « racks », interconnectés par des routeurs (switches) : liaison à

100 Mo/sec

! entre différents « Data centers » : communication internet à 2-3 Mo/sec

• Les serveurs communiquent par envoi de messages, ils ne partagent pas de disque ni de ressource de traitement =

architecture « shared nothing »

2
 Notion Data center
•Ex : Data center de Google (début 2010) :
!Un « Data center » Google contient entre 100 et 200 « Racks », chacun contenant 40 serveurs
!environ 5000 serveurs par « Data-center » pour un total de 1 millions de serveurs (estimation dʼaprès la
consommation électrique).

•Ex : Data center de Facebook (2010) :

!2500 cpu (serveurs)
!1 PetaByte dʼespace disque (= milleTerabytes = 1 million de Gigabytes)
!Plus de 250 Gigabytes données compressées (plus de 2 Terabytes non compressés) Rack2

Rack1

Rack3

3
 Notion de système distribué
• système logiciel permettant de coordonner plusieurs ordinateurs
• ordinateurs reliés par un réseau local (LAN)
• communiquant généralement par envoi de messages
• utilisant une architecture distribuée :
! fonctionnant sur du matériel peu spécialisé
! matériel facilement remplaçable en cas de panne

Application particulière : la distribution de données sur plusieurs

serveurs organisés en « data centers » :
! gestion de volumes de données très importants
! assurer une continuité de service en cas d'indisponibilité de service sur un serveur

4
 Gestion de données système distribué
On dispose d'un très grand ensemble de données sur lesquelles on doit leur appliquer des traitements. 2 stratégies :
• Par distribution des traitements :
! on distribue ces traitements sur un nombre de machines important afin dʼabsorber des charges très importantes
! on envoie les données aux endroits appropriés, et on enchaîne les exécutions distantes (scénario type Workflow
implémentable avec des web services)

• Par distribution des données (scaling des données) :

! on distribue les données sur un nombre important de serveurs afin de stocker de très grands volumes de données
! on « pousse » les programmes vers ces serveurs (plus efficace de transférer un petit programme sur le réseau plutôt
qu'un grand volume de données – Ex : algorithme MapReduce).

5
Rappel sur les bases de données rélationnelles
Une base de données relationnelle est un type de base de données où les données sont liées à
d’autres informations au sein des bases de données. Les bases de données relationnelles sont
composées d’un ensemble de tables qui peuvent être accessibles et reconstruites de différentes
manières, sans qu’il soit nécessaire de réarranger ces tables de quelque façon que ce soit. Le langage de
requête structuré (SQL) est l’interface standard pour une base de données relationnelle. Les instructions
SQL sont utilisées à la fois pour interroger de façon interactive les données contenues dans la base de
données relationnelle et pour collecter les données dans le cadre de rapports.

6
Rappel sur les bases de données relationnelles
Ci-dessous les 4 systèmes de gestion de bases de données relationnelles (SGBDR) les plus utilisé :
• OracleDatabase
• MySQL
• Microsoft SQL Server
• PostgreSQL

7
Nouveau besoin en matière de gestion de données
Constat avec les bases de données relationnelles (BDR):
Constat 1 : le modèle relationnel présente certaines limites
• On ne peut pas imbriquer les informations : On multiplie le nombre de tables pour représenter conceptuellement le
même objet
• La structure du schéma est très rigide : une base a un nombre fixé de tables, une table a un nombre fixe d’attributs, …
Le modèle doit être défini tôt dans le processus de développement, il est souvent difficile et couteux de le faire évoluer.
• Difficile de maintenir les contraintes ACID à lʼéchelle du système distribué entier
Constat 2 : croissance exponentielle des données générées par le web
• Ces masses de données apportent des opportunités d’analyses plus larges et plus fines ainsi que de nouveaux usages
de l’information
• Les données sont devenues le principal actif de certaines entreprises !
• Le phénomène « Big data » : Les systèmes de gestion des BD relationnelles n’ont pas été conçus pour gérer de tels
volumes de données.

8
Nouveau besoin en matière de gestion de données
Réponse au constat n°1 : les modèles non-structurés ou semi-structurés, plus adaptés à de nombreux cas de
collecte et de manipulation des données…
• Les bases NoSQL manipulent les données à l’aide de modèles non ou semistructurées: par exemple XML, mais ça n’est
pas le seul format de modèles semistructurés qui existe…

Réponse au constat n°2 : gérer de grands volumes de données nécessite de mettre en place des
systèmes distribués ….
• Les capacités de stockage sont démultipliées par la possibilité de répartir les données sur plusieurs nœuds.
• Les systèmes relationnels ne sont pas adaptés aux environnements distribués.
• Les solutions NoSQL implémentent naturellement des mécanismes qui permettent une distribution des données.
Les bases NoSQL ne remplacent pas les BD relationnelles mais en sont une alternative, un complément
apportant des solutions plus intéressantes dans certains contextes.

9
 Le grand paysage de base de données
Face aux faiblesses des SGBDR en termes de performance, d'évolutivité et de flexibilité des besoins de traitement à

grande échelle des données, alternatives suivantes avec des architectures distribuées :

• NoSQL BD : BD avec schéma dynamique ou sans schéma, BD magasins de clés-valeur, BD de documents et de

données graphiques, …

• NewSQL DB : amélioration des performances grâce à de nouveaux moteurs de stockage, des technologies

transparentes de fragmentation, de nouveaux logiciels et matériels : des BD radicalement nouvelles

• Data grid/cache products : amélioration des performances des applications et de la BD par stockage des données

en mémoire : données persistante en cache, réplication et des données distribuées, et calcul exploitant le grid

10
 SPRAIN relationnel base de données
• SPRAIN : acronyme qui désigne les 6 facteurs clés de l'adoption de
technologies de gestion de données alternatives aux traditionnelles BDR
• ces BD alternatives doivent permettre de traiter de très grands volumes de
données, supporter des applications hautement distribuées ou très complexes
• Ces 6 facteurs clés sont :
! Scalability (évolutivité) – hardware economics (économie de
matériel)
! Performance – BDR limitations
! Relaxed consistency – CAP theorem (cohérence relachée)
! Agility – polyglot persistence (agilité, persistance polyglotte)
! Intricacy (intrication) – big data, total data
! Necessity (nécessité) – open source

11
 Introduction au système NoSQL
• Definition

• Clarification des concepts

• Introduction au NoSQL

• Fondements des syst. NoSQL : MVCC

• Fondements des syst. NoSQL : Vector-clock

• Typologie des BD NoSQL

12
 Définition
Une proposition de définition de NoSQL: « Tout système de gestion de données sacrifiant des fonctionnalités du relationnel

pour faciliter la scalabilité par distribution »

• Les bases NoSQL adoptent une représentation de données non relationnelle.

• Les bases NoSQL apportent une plus grande performance dans le contexte des applications Web avec des volumétries de

données très importantes.

• Les bases NoSQL utilisent une très forte distribution de ces données et des traitements associés sur de nombreux serveurs.

13
 Clarification des concepts
 JSON : JavaScript Object Notation

Format de données textuelles dérivé de la notation des objets du langage JavaScript.

• Dérivé de la représentation littérale d’un objet en Javascript.

• JSON est plus simple que XML, et il est très facile à associer à un langage de programmation.

• JSON est massivement utilisé dans les applications web (AJAX), les web-services

(REST), et … les bases de données NoSQL.

• JSON se base sur deux structures :

► Une collection de couples nom/valeur, appelée objet

► Une liste de valeurs ordonnées, appelée tableau.

14
 Clarification des concepts
Exemples : objet

"personne": {" nom": "Fincher",

"prenom": "David", couples nom/valeur

"naissance": 1962

tableau

"acteurs": ["Eisenberg", "Mara", "Garfield", "Timberlake"]

15
 Clarification des concepts
 L’objet est un ensemble de couples nom/valeur non ordonné :

 Un tableau est une collection de valeurs ordonnées :

 Une valeur peut être une chaîne de caractères, un nombre, true ou false ou null, un objet, un tableau :

16
 Introduction au NoSQL
Les BD NoSQL :
• Adoptent une représentation de données non relationnelle (données non ou semi structurées)
• Ne remplacent pas les BD relationnelles mais sont une alternative, un complément apportant des solutions plus
intéressantes dans certains contextes
• Apportent une plus grande performance dans le contexte des applications Web avec des volumétries de données
exponentielle
• Utilisent une très forte distribution de ces données et des traitements associés sur de nombreux serveurs
• Font un compromis sur le caractère « ACID » des SGBDR pour plus de scalabilité horizontale et dʼévolutivité.

Lʼadoption croissante des bases NoSQL par des grands acteurs du Web (Google, faceBook, …) => multiplication
des offres de systèmes NoSQL

17
 Caractéristique de BD NoSQL
• pas de schéma pour les données ou schéma dynamique

• données de structures complexes ou imbriquées

• données distribuées : partitionnement horizontal des données sur plusieurs nœuds (serveurs) généralement par

utilisation dʼalgorithmes « MapReduce »

• réplication des données sur plusieurs noeuds

• privilégient la Disponibilité à la Cohérence (théorème de CAP) :

AP (Disponible + Résistant au partitionnement) plutôt que CP (Cohérent + Résistant au partitionnement)

=> nʼont en général pas de gestion de transactions

• mode d'utilisation : peu d'écritures, beaucoup de lecture

18
 Fondement des systèmes NoSQL : MVC
Contrôle de Concurrence Multi-Version (MVCC) :
• Méthode de contrôle de concurrence couramment utilisée par les SGBD
pour gérer des accès simultanés à la base de données avec mises à jour
• Dans une BD NoSQL, la gestion des mises à jour est faite :
! non pas en supprimant une fraction contenant les données avant modification et en la remplaçant par une fraction
contenant les données modifiées
! mais en marquant les anciennes données comme obsolètes et en ajoutant une nouvelle version contenant les
nouvelles données
! il existe ainsi plusieurs versions enregistrées, une seule est la plus récente
• nécessite généralement un balayage périodique pour supprimer les objets de données obsolètes.

19
Fondement des systèmes NoSQL : vector-clock
Horloges vectorielles (Vector-clocks) :
• Les ensembles de données répartis sur nœuds peuvent être lus et modifiés sur chaque nœud et aucune cohérence
stricte est assurée par des protocoles de transactions distribuées
Problème : comment faire des modifications concurrentes
• Une solution : les horloges vectorielles :
! un vecteur d'horloge est défini comme un n-uplet V [0], V [1], ..., V[n] des valeurs d'horloge à partir de chaque
noeud.
! à tout instant le noeud i maintient un vecteur d'horloge représentant son état et celui des autres nœuds répliques :
(Vi [0] = valeur de l'horloge du premier noeud, Vi [1] = valeur de l'horloge du deuxième noeud, ... Vi [i] = sa propre
valeur dʼhorloge, ... Vi [n] = valeur de l'horloge du dernier nœud)
! les valeurs d'horloge peuvent être de réelles « timestamps » dérivées d'une horloge locale de nœud, du numéro de
version/révision …

20
 Typologie des BD NoSQL
Stocker les informations de la façon la mieux adaptée à leur représentation => différents types de BD NoSQL :
• type « Clé-valeur / Key-value » : basique, chaque objet est identifié par une clé unique constituant la seule
manière de le requêter
Voldemort, Redis, Riak, …
• type « Colonne / Column » : permet de disposer d'un très grand nb devaleurs sur une même ligne, de stocker des
relations « one-to-many », dʼeffectuer des requêtes par clé (adaptés au stockage de listes : messages,posts,
commentaires, ...)
HBase, Cassandra, Hypertable, …
• type « Document » : pour la gestion de 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)
! MongoDBn CouchDB, Couchbase, …
• type « Graphe » : pour gérer des relations multiples entre les objets (adaptés au données issues de réseaux
sociaux, …)
Neo4j, OrientDB, …
21
Typologie des BD NoSQL

22
 BD NoSQL : Clé-valeur
• BD NOSQL modèle « Clé-Valeur »

• Forces & faiblesses des BD NoSQL « Clé-Valeurs »

23
 BD NoSQL : Clé-valeur
► Il s’agit de la catégorie de base de données la plus basique. Dans ce modèle chaque objet est identifié par une clé

unique qui constitue la seule manière de le requêter.

► La structure de l’objet est libre et le plus souvent laissé au choix du développeur de l’application (XML, JSON, ...), la

base ne gérant généralement que des chaînes d’octets.

► Le système de stockage ne connait pas la structure de l'information qu'il manipule.

24
 BD modèle NoSQL : Clé-valeur
• Elles fonctionnent comme un grand tableau associatif et retourne une valeur dont elle ne connaît pas la structure

• leur modèle peut être assimilé à une table de hachage distribuée

• les données sont simplement représentées par un couple clé/valeur

• la valeur peut être une simple chaîne de caractères, ou un objet sérialisé…

• cette absence de structure ou de typage ont un impact important sur le requêtage : toute lʼintelligence portée

auparavant par les requêtes SQL devra être portée par lʼapplicatif qui interroge la BD.

• Implémentations les plus connues :

! Amazon Dynamo (Riak en est l'implémentation Open Source)

! Redis (projet sponsorisé par VMWare)

! Voldemort (développé par Linkedln en interne puis passage en open source).

25
 BD modèle NoSQL : Clé-valeur
• Chaque objet est identifié par une clé unique seule façon de le requêter
• la structure de lʼobjet est libre, souvent laissé à la charge du développeur de lʼapplication (XML, JSON, ...), la base ne
gérant généralement que des chaînes dʼoctets

26
 BD modèle NoSQL : Clé-valeur
• Leur exploitation est basée sur 4 opérations (CRUD):

! C reate : créer un nouvel objet avec sa clé -- create(key, value)

! R ead : lit un objet à partir de sa clé -- read(key)

! U pdate : met à jour la valeur dʼun objet à partir de sa clé -- update(key, value)

! D elete: supprime un objet à partir de sa clé -- delete(key)

• Elles disposent généralement dʼune simple interface de requêtage HTTP REST accessible depuis nʼimporte quel

langage de développement

• Ont des performances très élevées en lecture et en écriture et une scalabilité horizontale considérable

• Le besoin en scalabilité verticale est faible du fait de la simplicité des opérations effectuées

27
 Utilisation de BD NoSQL : Clé-valeur
Utilisations principales des BD NoSQL type « Clés-Valeurs » :
! dépôt de données avec besoins de requêtage très simples
! système de stockage de cache ou dʼinformation de sessions distribuées (quand lʼintégrité relationnelle des
données est non significative)
! les profils, préférences dʼutilisateur
! les données de panier dʼachat
! les données de capteur
! les logs de données
!…

28
Forces et faiblesse de BD NoSQL : Clé-valeur
Forces :
• modèle de données simple
• Des performances exceptionnellement élevées en lecture et en écriture.
• bonne mise à lʼéchelle horizontale pour les lectures et écritures :
! évolutivité (scalable)
! disponibilité
! pas de maintenances requises lors d'ajout/suppression de colonnes
Faiblesses :
• modèle de données TROP simple :
! pauvre pour les données complexes
! interrogation seulement sur clé
! déporte une grande partie de la complexité de l'application sur la couche application elle-même

29
 BD NoSQL : Colonne
• BD NOSQL modèle « Colonne »
• Forces & faiblesses des BD NoSQL « Colonne »

30
 BD NoSQL modèle : Colonne
• Les données sont stockées par colonne, non par ligne
• On peut facilement ajouter des colonnes aux tables, par contre l'insertion d'une ligne est plus coûteuse
• Quand les données d'une colonne se ressemblent, on peut facilement compresser la 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.
• Implémentations les plus connues :
! HBase (Open Source de BigTable de Google utilisé pour l'indexation des pages web, Google Earth, Google
analytics, ...)
! Cassandra (fondation Apache qui respecte lʼarchitecture distribuée de Dynamo dʼAmazon, projet né de chez
Facebook)
! SimpleDB de Amazon.

31
 BD NoSQL modèle : Colonne
Les principaux concepts associés sont les suivants :
• Colonne :
! entité de base représentant un champ de donnée
! chaque colonne est définie par un couple clé / valeur
! une colonne contenant dʼautres colonnes est nommée supercolonne.
• Famille de colonnes :
! permettent de regrouper plusieurs colonnes (ou supercolonnes)
! les colonnes sont regroupées par ligne
! chaque ligne est identifiée par un identifiant unique (assimilées aux tables dans le modèle relationnel) et sont
identifiées par un nom unique
• Supercolonnes :
! situées dans les familles de colonnes sont souvent utilisées comme les lignes dʼune table de jointure dans le
modèle relationnel.

32
BD NoSQL modèle : Colonne

33
 BD NoSQL modèle : Colonne
• Elles sont les plus complexes à appréhender des BD NoSQL, même si au final on a un schéma assez proche des
bases documentaires
• elles sont très utilisées pour les traitements dʼanalyse de données et dans les traitements massifs (notamment via
des opérations de type MapReduce).
• elles offrent plus de flexibilité que les BD relationnelles:
! Il est possible dʼajouter une colonne ou dʼune famille de colonnes à nʼimporte quelle ligne à tout instant.

34
 BD NoSQL modèle : Colonne
Optimisation du stockage par rapport à une solution relationnelle

A chaque de ligne, correspond une liste de clé valeur

35
Forces et faiblesses des BD NoSQL : Colonne
Forces :
• Optimisation : pas de place perdue lorsque des champs n’existent pas dans certaines lignes
• L’accès aux données à partir de la clé sera beaucoup plus rapide, les données liées à une clé étant
regroupées en terme de stockage
• Conçues pour accueillir un grand nombre de colonnes (jusqu’à plusieurs millions) pour chaque ligne.
Stockage optimisé de relations « one to many »
• Performances et scalabilité
Faiblesses :
• A éviter pour des données interconnectés : système de requêtes minimaliste
• à éviter pour les lectures de données complexes
• exige de la maintenance - lors de l'ajout / suppression de colonnes et leur regroupements
• les requêtes doivent être pré-écrit, pas de requêtes ad-hoc définis "à la volée"

36
Utilisations principales des BD NoSQL : Colonne
Les BD NoSQL type « Colonne » sont principalement utilisées pour :
• Netflix l'utilise notamment pour le logging et l'analyse de sa clientèle
• Ebay l'utilise pour l'optimisation de la recherche
• Adobe l'utilise pour le traitement des données structurées et de Business Intelligence (BI)
• Des sociétés de TV lʼutilisent pour cerner leur audience et gérer le vote des spectateurs (nb élevé d'écritures
rapides et analyse de base en temps réel (Cassandra)
• peuvent être de bons magasins d'analyse des données semi-structurées
• utilisé pour la journalisation des événements et pour des compteurs
• Liste des actions effectuées par un utilisateur

37
 BD NoSQL : Document
• BD NOSQL modèle « Document »
• Forces & faiblesses des BD NoSQL « Document »

38
 BD NoSQL modèle : Document
• Constituées de collections de documents. Un document est composé de champs et des valeurs associées, ces dernières
pouvant être requêtées.
• elles sont basées sur le modèle « clé-valeur » mais la valeur est un document en format semi-structuré hiérarchique de type
JSON ou XML (possible aussi de stocker n'importe quel objet)
• les documents n'ont pas de schéma, mais une structure arborescente : ils contiennent une liste de champs, un champ a une
valeur qui peut être une liste de champs, ...
• Implémentations les plus connues :
! CouchDB (fondation Apache)
! RavenDB (pour plateformes « .NET/Windows » - LINQ)
! MongoDB, Terrastore, …

39
 BD NoSQL modèle : Document
• Un document est composé de champs et des valeurs associées
• ces valeurs :
! peuvent être requêtées
! sont soit dʼun type simple (entier, chaine de caractère, date, ...)
! soit ellesmêmes composées de plusieurs couples clé/valeur.
• bien que les documents soient structurés, ces BD sont dites “schemaless” : il nʼest pas nécessaire de définir au préalable les
champs utilisés dans un document
• les documents peuvent être très hétérogènes au sein de la BD
• permettent d'effectuer des requêtes sur le contenu des documents/objets : pas possible avec les BD clés/valeurs simples
• Elles sont principalement utilisées dans le développement de CMS (Content Management System - outils de gestion de
contenus).

40
BD NoSQL modèle : Document

41
Forces et les faiblesses des BD NoSQL : Document
Forces :
• modèle de données simple mais puissant (expression de structures imbriquées)
• Capacité à effectuer des requêtes sur le contenu des objets
• pas de maintenance de la BD requise pour ajouter/supprimer des «colonnes»
• Permet de représenter les relations one-to-one et one-to-many. Ainsi un document pourra être
sauvegardé et chargé sans aucun traitement de jointure.
• Scalabilité
Faiblesses :
• inadaptée pour les données interconnectées
• peut alors être lent pour les grandes requêtes (avec MapReduce)

42
Utilisation principales des BD NoSQL : Document
Les BD NoSQL type « Document » principalement utilisée pour :
• Enregistrement dʼévénements
• Systèmes de gestion de contenu
• Web analytique ou analytique temps-réel
• Catalogue de produits
• Systèmes d'exploitation
• …

43
 BD NoSQL : Graphe
• BD NOSQL modèle « Graphe »
• Forces & faiblesses des BD NoSQL « Graphe »

44
 BD NoSQL modèle : Graphe
• Elles permettent la modélisation, le stockage et la manipulation de données complexes liées par des
relations non-triviales ou variables
• modèle de représentation des données basé sur la théorie des graphes
• sʼappuie sur les notions de noeuds, de relations et de propriétés qui leur sont rattachées.
• Implémentations les plus connues :
! Neo4J
! OrientDB (fondation Apache)
!…

45
 BD NoSQL modèle : Graphe
• Elles utilisent :
! un moteur de stockage pour les objets (similaire à une base documentaire, chaque entité de cette base étant
nommée nœud)
! un mécanisme de description dʼarcs (relations entre les objets), arcs orientés et avec propriétés (nom, date, ...)
• elles sont bien plus efficaces que les BDR pour traiter les problématiques liées aux réseaux (cartographie, relations entre
personnes, ...)
• sont adaptées à la manipulation d'objets com

46
BD NoSQL modèle : Graphe

47
 Forces et faiblesses des BD NoSQL : Graphe
Forces :
• modèle de données puissant
• rapide pour les données liées, bien plus rapide que SGBDR
• modèles dʼinterrogation bien établis et performants : Tinkerpop pile (fournit un ensemble commun d'interfaces
permettant aux différentes technologies informatiques graphiques de travailler ensemble, que le développeur utilise
en cas de besoin), SPARQL et Cypher
Faiblesses :
• Fragmentation (sharding) :
! Même si elles peuvent évoluer assez bien
! Pour certains domaines, on peut aussi fractionner.

48
Utilisations principales des BD NoSQL : Graphe
Les BD NoSQL type « Document » sont principalement utilisées pour :
• Moteurs de recommandation
• Business Intelligence (BI)
• Semantic Web
• Social computing
• Données géospatiales
• Généalogie
• Web of things
• Catalogue des produits
• Sciences de la Vie et calcul scientifique (bioinformatique, …)
• Données liées, données hiérarchiques
• Services de routage, d'expédition et de géolocalisation
• Services financiers : chaîne de financement, dépendances, gestion des risques, détection des fraudes, …
49
 BD NoSQL : Graphe et web sémantique
Magasins de triplets RDF (Triple Stores) :
• the foundation of many Semantic Web systems
• encodés in format/langage RDF
• chaque ligne a une structure «nœud-lien-noeud» (sujet-prédicatobjet)
• possibilité de joindre des graphes ensemble automatiquement en faisant correspondre les identifiants des nœuds
• possibilité de fusion automatique de 2 graphes
Ex: le graphe 1 a le noeud A relié à B et le graphe 2 le nœud B relié à C, l'union de ces graphes montre une
relation de A à C.
• les données RDF interrogées via le protocole/langage de requête
SPARQL permettant l'utilisation d'ontologies pour l'inférence (Groupe W3C RDF Data Access de travail)
• Ex : Virtuoso, Sesame, Jena

50
 BD NoSQL : Graphe et web sémantique
Magasins de triplets RDF (Triple Stores) :
• the foundation of many Semantic Web systems
• encodés in format/langage RDF
• chaque ligne a une structure «nœud-lien-noeud» (sujet-prédicatobjet)
• possibilité de joindre des graphes ensemble automatiquement en faisant correspondre les identifiants des nœuds
• possibilité de fusion automatique de 2 graphes
Ex: le graphe 1 a le noeud A relié à B et le graphe 2 le nœud B relié à C, l'union de ces graphes montre une
relation de A à C.
• les données RDF interrogées via le protocole/langage de requête
SPARQL permettant l'utilisation d'ontologies pour l'inférence (Groupe W3C RDF Data Access de travail)
• Ex : Virtuoso, Sesame, Jena

51
Implémentation d’une mini base clé-valeur en Python
• Dictionnaire Python = base clé-valeur Exemple d’utilisation (Étudiants)
• Classes = abstraction NoSQL
db = KeyValueDB()
import time

class KeyValueDB: [Link]("etudiant:1", {

def __init__(self):
[Link] = {} "nom": "Ali",
"prenom": "Karim",
def set(self, key, value, ttl=None):
expiration = [Link]() + ttl if ttl else None "email": "karim@[Link]"
[Link][key] = (value, expiration) })
def get(self, key):
if key not in [Link]: print([Link]("etudiant:1"))
return None

value, expiration = [Link][key]

if expiration and [Link]() > expiration:
del [Link][key] Gestion des sessions avec TTL
return None

return value [Link]("session:abc123", {"user_id": 1}, ttl=5)

def delete(self, key):
[Link](key, None) [Link](6)
def keys(self):
print([Link]("session:abc123")) # None
return list([Link]())

52
 TP PRATIQUE – NoSQL Clé-Valeur avec MongoDB + Python
Prérequis : Insertion (CREATE) : Insertion d’un étudiant
• MongoDB installé et lancé : etudiant = {
[Link] "matricule": "L3-101",
• Python 3.9+ "nom": "OUEDRAOGO",
• Environnement virtuel (recommandé) "prenom": "Ali",
• Connaissances de base en Python "age": 22,
"filiere": "Informatique",
Installation et connexion "moyenne": 14.5
}
Dans ton environnement Python : Installer PyMongo
collection.insert_one(etudiant)
pip install pymongo

Connexion à MongoDB
from pymongo import MongoClient

client = MongoClient("mongodb://localhost:27017/")
db = [Link]
collection = [Link]

print("Connexion réussie à MongoDB")

53
TP PRATIQUE – NoSQL Clé-Valeur avec MongoDB + Python
Insertion multiple Lecture (READ) : Afficher tous les étudiants
etudiants = [ for e in [Link]():
{ print(e)
"matricule": "L3-102",
"nom": "ZONGO", for e in [Link]({"filiere": "Informatique"}):
"prenom": "Sara", print(e)
"age": 21,
"filiere": "Mathématiques",
for e in [Link]({"moyenne": {"$gt": 13}}):
"moyenne": 16
print(e)
},
{
"matricule": "L3-103", Mise à jour (UPDATE) : Modifier la moyenne
"nom": "KABORE",
"prenom": "Paul",
collection.update_one(
"age": 23,
{"matricule": "L3-103"},
"filiere": "Informatique",
{"$set": {"moyenne": 13.5}}
"moyenne": 12
)
}
]

collection.insert_many(etudiants)

54
TP PRATIQUE – NoSQL Clé-Valeur avec MongoDB + Python
Suppression (DELETE) : Supprimer un étudiant
Cas pratique reel : gestion des notes
collection.delete_one({"matricule": "L3-101"}) (Ajouter un tableau de modules)

collection.update_one(
Requêtes avancées : Trier par moyenne décroissante {"matricule": "L3-102"},
{"$set": {
for e in [Link]().sort("moyenne", -1): "modules": [
print(e["nom"], e["moyenne"]) {"nom": "NoSQL", "note": 15},
{"nom": "IA", "note": 17}
]
}}
)

Visualiser les données dans MongoDB Compass

mongodb://localhost:27017

55