Bases de Données non relationnelles, NoSQL (Introduction) 1er cours

HMIN313 : 1er Cours
Les bases de données NoSQL
BD orientées graphes
Hatim CHAHDI
UMR Espace-DEV
Université de Montpellier
14 Septembre 2016
Hatim CHAHDI (Espace Dev - UM) Intro NoSQL, BD Graphes 14 Septembre 2016 1 / 42

Objectifs du cours
Comprendre la problématique de stockage de données
Prendre conscience des alternatives No-SQL existantes par rapport
aux systèmes traditionnels
Étude approfondie des bases de données orientées graphe
Présentation de Neo4J comme exemple d’une BD orientée graphe

Base de donn´ees relationnelles ! Pourquoi pas ?
”I suppose it is tempting, if the only tool you have is a hammer, to treat
everything as if it were a nail.”
Abraham Maslow : The Psychology of Science 1966

Base de donn´ees relationnelles ! Pourquoi pas ?
”I suppose it is tempting, if the only tool you have is a hammer, to treat
everything as if it were a nail.”
Abraham Maslow : The Psychology of Science 1966
Pourquoi utiliser d’autres types de bases de donn´ees ?
Si le seul outil que j’ai en ma possession est un SGBD relationnel. Alors
tout m’apparaˆıtra comme une table

Motivations
Mission principale d’un SGBD
Un SGBD cherche à fournir un système de stockage et un accès pratique,
fiable, efficace et sûr à des quantités importantes de données
persistantes.
Évolution du Web :
Plusieurs sources de données disponibles
Acquisition facilitée des données : Navigation, préférences des
utilisateurs...
...
Complexité des données : Gros volumes de données interconnectées
Des besoins de flexibilité avec des schémas qui évoluent, des priorités
sur l’accès, des données manquantes

Motivations
Les performances des SGBD restaient très insatisfaisantes...
Scalabilité
Consistance des données
Complexité des schémas
. . .
Constat :
Les SGBD relationnels ne sont pas toujours la meilleure solution de gestion
et/ou traitement des données

Le monde No-SQL : Des alternatives !
Des besoins différents. Des structures de
stockage différentes
Résultat
Apparition des Systèmes dits No-SQL.
Les différents types des SGBD No-SQL:
Clé/Valeur
Colonne
Document
Graphe
. . .
No-SQL = Not Only SQL

Base de données orientée Clé/Valeur
Principes: Représentation des données sous forme de clé/valeur .
Les valeurs peuvent être de simple chaˆınes de caractères ou des objets
sérialisés complexes.
Utilisation: dépôt de données avec besoins de requêtage simples
(préférences d’utilisateur, données de panier, les logs . . . )
Figure : modèle clé/valeur

Base de données orientée Clé/Valeur
Principes: Représentation des données sous forme de clé/valeur .
Les valeurs peuvent être de simple chaˆınes de caractères ou des objets
sérialisés complexes.
Utilisation: dépôt de données avec besoins de requêtage simples
(préférences d’utilisateur, données de panier, les logs . . . )
Figure : modèle clé/valeur
Exploitation basée sur 4
opérations (CRUD): Accès par
la clé
Create: Création d’un objet.
Read: Lecture d’un objet.
Update: Mise à jour d’un
objet.
Delete: Suppression un objet.

Base de données orientée colonnes
Principes: Proche du relationnel. Mais le stockage des donnés se fait
par colonne et non par ligne.
Ajout de colonnes facile et dynamique
Possibilité de compression des données
Utilisation: Optimisation de la recherche, traitement et analyse de
données structurées (BI) . . .
Figure : modèle colonne

Base de données orientée colonnes
Principes: Proche du relationnel. Mais le stockage des donnés se fait
par colonne et non par ligne.
Ajout de colonnes facile et dynamique
Possibilité de compression des données
Utilisation: Optimisation de la recherche, traitement et analyse de
données structurées (BI) . . .
Figure : modèle colonne
Implémentation à étudier dans
la suite de l’UE

Base de données orientée document
Principes: C’est une variante des SGBD clé/valeur, où la valeur est
un document de type XML ou JSON.
Les documents ont une structure arborescente, ils sont composés de
champs et des valeurs associées
Ce type de SGBD permet d’effectuer des requêtes sur le contenu des
documents.
Utilisation: Enregistrements d’événements, gestion de contenu . . .
Figure : modèle document

Base de données orientée document
Principes: C’est une variante des SGBD clé/valeur, où la valeur est
un document de type XML ou JSON.
Les documents ont une structure arborescente, ils sont composés de
champs et des valeurs associées
Ce type de SGBD permet d’effectuer des requêtes sur le contenu des
documents.
Utilisation: Enregistrements d’événements, gestion de contenu . . .
Figure : modèle document
Implémentations connues
CouchDB fondation apache
MangoDB

Base de données orientée graphe
Principes
Les données sont représentées sous-forme de graphe : Des noeuds pour
les entités, des arcs pour les relations entre les entités
Ce type de SGBD est adapté à la manipulation de données fortement
connectées
Utilisation: Systèmes de recommandations, Réseaux sociaux,
Systèmes de transport . . .
Figure : modèle graphe

Base de données orientée graphe
Principes
Les données sont représentées sous-forme de graphe : Des noeuds pour
les entités, des arcs pour les relations entre les entités
Ce type de SGBD est adapté à la manipulation de données fortement
connectées
Utilisation: Systèmes de recommandations, Réseaux sociaux,
Systèmes de transport . . .
Figure : modèle graphe
Implémentations connues
Neo4J
AllegroGraph
. . .

Passage oblig´e au NoSQL ?

Récapitulatif : Passage obligé au NoSQL ?
Alternatives adaptées à des cas particuliers
Évolution fréquente des schémas
Flexibilité dans la gestion des données manquantes (ou non
conformes)
Flux important : Passage à l’échelle
. . .

Des systèmes complémentaires
Utilisation conjointe pour une meilleure gestion des données
Figure : Persistance dite polyglotte

Des systèmes complémentaires
Utilisation conjointe pour une meilleure gestion des données
Figure : Persistance dite polyglotte
One Size doesn’t fit all

Caractéristiques des systèmes NoSQL : CAP
Consistency, Availability, Partition tolerance
Consistency ou cohérence des données : toute modification de
donnée est suivie d’effet pour tous les noeuds du système
Availability ou disponibilité des données : toute requête émise et
traitée par un noeud du système, re¸coit une réponse (même en
situation d’échec à produire une réponse)
Partition tolerance ou recouvrement des noeuds assurer une
continuité du fonctionnement en cas d’ajout/suppression de noeud
(ou partition) du système distribué
Constat de Brewer : aucun des systèmes distribués n’est à même de
satisfaire en même temps les principes C, A et P

Théorème CAP : un choix à faire !
Un système distribué va satisfaire deux des trois points CAP
Considérations SGBDR / Systèmes NoSQL
SGBDR : Cohérence et haute disponibilité (pas ou peu de P : de
différents noeuds système)
Systèmes NoSQL : Choix du P (système naturellement distribué) et
sélection soit du C, soit du A
abandon du A ⇐ Accepte d’attendre que les données soient cohérentes
abandon du C ⇐ Accepte de recevoir des données parfois incohérentes

Positionnement des syst`emes / CAP
Figure : Synth`ese CAP

Les Bases de Données orientées Graphes
Figure : Graphe du trafic aérien mondial

Base de Données orientée Graphes
Histoire des graphes
Théorie des graphes
Les graphes en base de données
Neo4J: un SGBD orienté graphe open source*

Des probl`emes remontant `a 840 . . .

Le problème du cavalier
Posé par le joueur et théoricien
d’échecs al-Adli ar-Rumi :
Comment un cavalier peut-il
visiter toute les cases sans passer
deux fois par la même ?

Le problème du cavalier
Posé par le joueur et théoricien
d’échecs al-Adli ar-Rumi :
Comment un cavalier peut-il
visiter toute les cases sans passer
deux fois par la même ?
Figure : La solution de Ar-Rumi
Une solution parmi les milliards de
solution possibles

Les sept ponts de K¨onigsberg

Figure : Mod´elisation simple

Figure : Modélisation simple
Solution démontrée par Euler
Pas de promenade possible
Naissance de la théorie des
graphes : 1736
Figure : Modélisation sous forme de
graphe

Des problématiques plus récentes...
Gestion de code
Réseaux sociaux
Transport et logistique
Collaborations
Chimie et biologie
spatial

Gestion de code
Réseaux sociaux
Collaborations
Chimie et biologie
spatial
Pourquoi et quand utiliser les graphes ?
Modélisation efficace des données connectées
Donner de l’importance aux relations entre différentes entités
. . .

Gestion de code
Réseaux sociaux
Collaborations
Chimie et biologie
spatial
Pourquoi et quand utiliser les graphes ?
Modélisation efficace des données connectées
Donner de l’importance aux relations entre différentes entités
. . .
Quand les SGBD relationnels et les autres SGBD No-SQL négligent
les relations, toute la puissance des SGBD graphes est dans leur
prise en compte et représentation explicite des relations

La théorie des graphes : Notions de base
Définitions
Un graphe permet de représenter simplement la structure, les
connexions et les cheminements possibles d’un ensemble
complexe comprenant un grand nombre de situations, en
exprimant les relations, les dépendances entre ses éléments
G = ( V , E , L ) où L : E -> V x V
avec :
V: Ensemble des sommets.
E: Ensemble des arêtes.
L: fonction associant à chaque arête une paire de sommets.
Les différents types de graphes: orienté, non orienté,
multigraphe, réflexif . . .

La théorie des graphes : Notions de base
Opérations
Adjacent(G,x,y): Tester s’il existe une arête de x à y.
Voisinage(G,x): Retourner, s’ils existent, les sommets liés par
une arête avec le sommet x.
Ajout(G,x,y,l): Ajouter à un graphe G une arête ,étiquetée l,
entre les sommets x et y.
Atteindre(G,x,y): Tester s’il existe un chemin entre les
sommets x et y.
Chemin(G,x,y): Retourne le plus court chemin entre les
sommets x et y.

Les BD graphes
Modèle de representation des données s’appuyant sur les algorithmes
développés en théorie des graphes pour offrir des implémentations
simples et efficaces.
Modélisation, stockage et manipulation de données complexes
liées par des relations.
Le Graphe est l’entité qui va enregistrer les données dans des Noeuds
qui possèdent des propriétés. Ces Noeuds peuvent être reliés entre
eux avec des arcs (relations).
Figure : Graphe avec 3 noeuds et 2 relations

Les implémentations des graphes
Liste d’adjacence
Pour chaque noeud, on représente la liste des voisins.
Efficace pour obtenir les voisins d’un noeud.
N’est pas optimale pour tester l’existence de chemin entre deux noeuds.
Liste d’incidence
Les arcs et les noeuds sont stockés comme des objets dans la base.
chaque noeud enregistre les arcs incidents.
chaque arc enregistre les noeuds incidents.

Les implémentations des graphes
Matrice d’adjacence
représentation du graphe en deux dimensions.
Les lignes représentent les noeuds sources.
Les colonnes représentent les noeuds de destination.
Les valeurs représentent les arcs.
Matrice d’incidence
représentation du graphe en deux dimensions.
Les lignes représentent les noeuds.
Les colonnes représentent les colonnes.
La valeur précise si le noeud est la source ou la destination des arcs.

Les SGBD orientés graphe disponibles
Deux courants d’implémentations : Pour des besoins différents
Stockage optimisé : des SGBD offrant des performances accrues pour
le stockage de graphe.
Analyse optimisée : des SGBD performant pour l’analyse et le calcul
de graphes.

Neo4J
Qu’est ce que c’est Neo4J ?
Un SGBD orienté graphe écrit en Java.
Transactionnel : ACID (Atomicité, Consistance, Isolation, Durabilité).
Scalabilité : Jusqu’à un degré
Disponible en version embarquée et serveur.
Dispose d’une API REST.
Peut-il servir comme un endpoint SPARQL ?

Neo4J : Couches logiques
Figure : Couches logiques de Neo4J

Neo4J : Architecture
Figure : Architecture technique de Neo4J

Neo4J : deux modes :Embarqué et Serveur
Mode embarqué:
Exécution de Neo4J dans le même processus de l’application.
Accès direct aux différentes API du SGBD : Core API, traversal
framework et cypher le langage de requêtage.
Contrôle total sur le cycle des transactions.
Remarques:
Faire attention au GC de la JVM.
L’application doit gérer les cycles de la base de données.

Neo4J : API Java avec deux modes : Embarqué et
Serveur
Mode serveur:
Au coeur de chaque serveur, une instance embarquée de Neo4J.
Communication avec le SGBD au travers de l’API REST : envoi de
requêtes formatées en JSON avec le protocole HTTP.
Bénificie des avantages de l’architecture Client/Serveur.
Remarques:
Faire attention aux communications sur le réseau.
Chaque requête est executée dans une transaction séparée.

Neo4J : Schema-less
Figure : Exemple (Documentation Neo4J)

Neo4J : Modèle de données
modèle : graphe marqué, orienté , attribué et multi-valué
Figure : Un autre exemple (Documentation Neo4J)

Jeux de données plus larges : OpenStreetMap ou
MusicBrainz
Gestion pouvant aller jusqu’à plusieurs milliards de nœuds
Figure : Un exemple plus complet : cartographie en Norvège avec OSM

Cypher : expressions pour poser des ﬁltres sur le graphe
Figure : Exemple de requˆete (Documentation Neo4J)

Exemple Cypher
Clauses dans une grammaire d´eclarative `a rapprocher de SQL : START,
MATCH, WHERE, RETURN
Listing 1: Read-Only Query Structure (doc. Neo4J)
START me = node : people (name = ’ Pierre ’ )
MATCH me −[:FRIEND]−> f r i e n d
WHERE f r i e n d . age > 28
RETURN f r i e n d . name
ORDER BY f r i e n d . age ASC
SKIP 5 LIMIT 10

Autre exemple Cypher
Listing 2: Compter sur le type des relations
MATCH () −[ r ]−>()
RETURN TYPE( r ) AS r e l t y p e , count (∗) AS r e l c a r d i n a l i t
MATCH ( : Person ) −[: l i k e s ]−>( r : Restaurant )
WITH r , count (∗) as t r
WHERE t r > 2
RETURN r . name as RESTAURANT, t r as TOTAL

Une force : les appels r´ecursifs
Listing 3: parcourir le graphe
(A)−>()−>()−>()−>(B)
(A)−[∗]−>(B)
MATCH ( John {name : ’ John ’ }) −[: f r i e n d ]−> ()
−[: f r i e n d ]−> ( f o f )}
RETURN John , f o f

Retrouver le sch´ema
Listing 4: Infos sur le sch´ema
match n
r e t u r n d i s t i n c t l a b e l s (n )
match n−[ r ] −()
r e t u r n d i s t i n c t type ( r )
match n−[ r ] −()
r e t u r n d i s t i n c t l a b e l s (n ) , type ( r )

Exemple Cypher
Autres op´erations CRUD
Listing 5: Tout supprimer dans la base (doc. Neo4J)
MATCH ( n)
OPTIONAL MATCH (n)−[ r ] −()
DELETE n , r

Conclusion
Bienvenue dans le cot´e obscure de la force : NoSQL!

Conclusion
Bienvenue dans le cot´e obscure de la force : NoSQL!
Salle TD : 5.08

Bases de Données non relationnelles, NoSQL (Introduction) 1er cours

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Bases de Données non relationnelles, NoSQL (Introduction) 1er cours

Similaire à Bases de Données non relationnelles, NoSQL (Introduction) 1er cours (20)

Bases de Données non relationnelles, NoSQL (Introduction) 1er cours