Base de données graphe et Neo4j

Présentation Neo4j
BORIS GUARISMA
CONSULTANT DATA SCIENCE ET BIG DATA
17/01/2017 BORIS GUARISMA - PRÉSENTATION NEO4J POUR LE CNAM 1

Présentation
•CNAM 2013-2014:
• NFE204: Bases de données avancées (1)
• NFE211 / 212: Ingénierie des systèmes décisionnels (1 et 2)
• EAR206: Analyse données et décisions dans l’entreprise
•LinkedIn:
• fr.linkedin.com/in/borisguarisma
• SlideShare:
• fr.slideshare.net/BorisGuarisma

Présentation

Sommaire
• L’entreprise connectée
• Pour quoi une base de données graphe ?
• Stockage et traitement graphe
• Labeled Property Graph
• Base de données graphe: cas d’usage … vers une vraie adoption
•Neo4j: autres informations « produit »
• Import des données
• Architecture
• Réplication: cohérence, Causal Clustering/Consistency
• Sharding
• Autres features

L’entreprise connectée
Source YouTube :
Introducing Neo4j 3.1: The Graph Foundation for the Enterprise

Source YouTube :
need a real-time view of
every single store,
related to user’s
geography and position
need entire purchase
story

Source YouTube :
not good at managing relationships
within dataset
between datasets

Source YouTube :

Pour quoi une base de données graphe?
FAITS
• Les systèmes de gestion de base de données relationnelles (SGBDR) ne sont plus adaptés au Big
Data
• Les données sont fortement connectées (notion de « relation »)
• La redéfinition du schéma (ajouter de nouveaux types de données ou une nouvelle relation), …
cela prend beaucoup de temps pour les SGBDR …
• SGBDR : les requêtes SQL avec des multiples jointures de plus en plus complexes avec des
latences en lecture de plus en plus importante

DES SOLUTIONS
• Les bases de données NoSQL (Not Only SQL):
• clé – valeur
• orientées colonne
• orientées documents
• graphe

RELATIONNEL
• Qui sont les amis d’Alice ? la recherche via
l’index global possède généralement une
complexité en temps de O(log n).
• Qui est ami avec Alice ? lorsque l’on effectue
une recherche dans le sens opposé de celui à
partir duquel l’index à été construit, on doit
effectuer plusieurs recherches via l’index pour
chaque personne (ami potentiel d’Alice), pour
un coût total de O(m log n).

GRAPHE
• Illustration de l'adjacence entre éléments sans index (index-free adjacency).
• Pour trouver les amis de Alice, nous suivons tout simplement ses relations FRIEND sortants,
chacune avec un coût O(1).
• Pour trouver qui est ami avec Alice, nous suivons tout simplement toutes les relations FRIEND
entrants d'Alice, chacune avec un coût de O(1), pour un coût total de O(m).

EFFET « WHITEBOARD »
le dessin sur le tableau est le
modèle physique, c’est la façon
comment les données sont
stockées sur disque

CEPENDANT LES SGBDR ONT QUELQUE CHOSE DE BIEN !
Elles sont ACID … et Neo4j aussi
• Atomicité : Tout ou rien. Soit l’opération se fait en entier, soit elle ne se fait pas du tout. La
notion d’atomicité sous-entend la possibilité de défaire un opération avortée.
• Cohérence : L’opération doit assurer que la base de données sera dans un état valide après
l’opération.
• Liée à la configuration en cluster des nœuds (maître-esclaves, core-replicas, etc.) de la base de données
NoSQL (voir slides « Casual Clustering » à la fin de la présentation)
• Isolation : L’opération doit se faire en toute autonomie sans dépendance à une autre opération.
• Durabilité : En cas de problème important (coupure d’électricité), les modifications apportées
sont bien enregistrées

Stockage et traitement graphe
LES SYSTEMES NoSQL
• En général, il n'y a pas de structure de données pour
modéliser et stocker les relations.
• La plupart des bases NoSQL n’ont pas un
« bon concept » de requête pour les relations
• modélise et stocke les relations

bases de données graphe qui
sérialisent le graphe (sous forme de
table) pour un SGBDR, pour une base
de donnés orientée objet ou pour un
autre type de stockage.

• Stockage Graphe
• Objectif: performance et scalabilité.
• Stockage des données représentées sous forme d'un graphe, avec des nœuds et des relations.
• Utilisant des structures de stockage dédiées aux nœuds et relations.
• Traitement Graphe
• Objectif: performance des traversals.
• Parcours des relations grâce à des pointeurs physiques.
• Système de stockage capable de fournir une adjacence entre éléments voisins : chaque voisin d'une
entité est accessible grâce à un pointeur physique.
• Lecture et parcours des données sans recours à un index, en utilisant les arcs pour passer d'un
nœud à l'autre.
• Les bases de données graphe profitent de l’avantage donné par l'adjacence entre éléments sans
index (index-free adjacency).

Traitement graphe: CYPHER
LATENCE DES REPONSES DES REQUETES
• Avec une base de données graphe, la plupart des requêtes suivent un schéma dans lequel un
index est utilisé simplement pour trouver le(s) nœud(s) de départ.
• Le reste du parcours utilise ensuite une combinaison de chasse au pointeur + pattern
matching pour rechercher les données. Requête CYPHER:
MATCH (:BAILLEUR)-[r1:EST_BAILLEUR_DE]->(b)-[r2:A_CONJOINT]->(:CONJOINT)
• La performance ne dépend pas de la taille totale de l'ensemble de données, mais uniquement
sur les données interrogées (sous-graphes).
• Cela conduit à des temps de performance qui sont à peu près constant (liés à la taille de
l'ensemble de résultat), même si la taille de l'ensemble de données augmente.
“openCypher project aims to bring graph querying to the masses, with support from Oracle,
Databricks, Tableau and other leading companies”

Traitement graphe: Transversal
CORE API: JAVA

Labeled Property Graph
• Libellés – types de nœuds
:PERSONNE :PERSONNE

• Libellés – types de nœuds
:PERSONNE:BENEFICIAIRE :PERSONNE:CONJOINT

• Libellés – types de relations
A_CONJOINT

• Propriétés – nœuds et relations
A_CONJOINT
nuinp:
matricule:
nom :
prenom:
nir:
dtnaires:
numteldo:
nutel2do:
email:
adresse:
iban:
mtloy:
mttotdro:
toprsa:
nuinp:
nom:
nir:
sitfam: ‘MAR’

• Propriétés – nœuds et relations
CVA_CONJOINT
nuinp:
matricule:
nom :
prenom:
nir:
dtnaires:
numteldo:
nutel2do:
email:
adresse:
iban:
mtloy:
mttotdro:
toprsa:
nuinp:
nom :
nir:
matricule:sitfam: ‘MAR’
matricule:
respdos: ‘MME’
sitdos: ‘A’
numteldo:
nutel2do:
emaildos:
toprsa:
:DOSSIER

• En conclusion
:SUJET :SUJET
CVVERBE
adjectif:
adjectif:
adjectif:
adjectif:
adverbe:
adjectif:
adjectif:

Base de données graphe: cas d’usage
• Réseaux sociaux
• Détection de fraude (PANAMA PAPERS !)
• Analyse des réseaux IT
• Systèmes de recommandations
• …

Pas que des cas d’usage
• Vers une adoption généralisée des bases de données graphe
• La valeur (avantage compétitif) est dans la relation entre les données, e.g. Google (search)

Neo4j: autres informations produit
• Comparaison versions « Enterprise » et « Community (gratuit) »

Neo4j: autres informations produit

Neo4j: Import des données

Neo4j: Architecture
• Architecture
• Le Core API est une API Java qui expose les
primitives de graphe des nœuds, des relations,
des propriétés et des libellés à l'utilisateur.
• Neo4j possède un langage de requête
puissant, Cypher, qui permet d’interroger le
graphe pour obtenir toutes sortes
d’informations sur les nœuds, leurs liens et le
contenu de ces derniers.
• Le Traversal ou parcours de graphe est un
processus qui visite les nœuds dans le graphe
en suivant les relations entre les nœuds d'une
manière particulière.
in-memory

La cohérence
• Capacité d’un système à refléter fidèlement les actions d’un utilisateur.
• Cohérence forte – nécessite une réplication synchrone, et potentiellement des verrouillages complexes
(two phases commit)
• Cohérence faible – on accepte le risque de lectures ne reflétant pas les mises à jour
• Cohérence à terme (Eventual consistency) – le système garantit que les incohérences ne sont que
transitoires.
• En général, les systèmes NoSQL abandonnent la cohérence forte pour favoriser la réplication
asynchrone, et donc le débit en écriture/lecture.
• La notion de cohérence est liée à la configuration en cluster des nœuds (maître-esclaves, core-
replicas, etc.) de la base de données NoSQL

Transactions et logs

Neo4j: Causal Clustering
1. Core servers: mis à jour du graphe, opérations en continue
2. Read replicas (scalabilité): requêtes, analyses, reporting
RAFT
BOLT
source YouTube :Introducing Neo4j 3.1: The Graph Foundation for the Enterprise
avant
maintenant

Neo4j: Causal Consistency
source YouTube : Introducing Neo4j 3.1: The Graph Foundation for the Enterprise

Neo4j: Causal Consistency
Consensus log: stores both
committed and
uncommitted transactions

Neo4j: Causal Consistency - bookmarks
The client can ask for a bookmark which it then presents as a parameter to the next transaction. Using
that bookmark the cluster can ensure that only servers which have processed the client’s bookmarked
transaction will be able to run its next transaction. This provides a causal chain which ensures correct
behaviour from the client’s point of view

Neo4j: Sharding
• Scalabilité: sharding
• S'il faut dépasser la capacité d'un cluster, nous pouvons partitionner le graphe sur plusieurs
instances de la base via la construction d'une logique de sharding dans l'application.
• Le sharding implique l'utilisation d'un identifiant synthétique pour la jointure des données sur
plusieurs instances de la base au niveau applicatif.
• Comment cela s'effectuera dépend beaucoup de la forme du graphe. Certains graphes se prêtent
très bien à ce cas avec des « frontières pratiques ». Bien sûr, pas tous les graphes ont des
« frontières » si évidentes.
• L'objectif futur de la plupart des bases de données graphe est d'être capable de partitionner un
graphe sur plusieurs machines sans intervention au niveau de l'application, de sorte que l'accès en
lecture et en écriture sur le graphe puisse être scalable horizontalement.
• Dans le cas général, cela est connu pour être un problème NP-dur, et donc impossible à résoudre.
“On Sharding
Graph Databases”
(Feb 2011)
Part of the reason Neo4j does not shard the graph is that since a graph is a highly connected data structure, traversing through a
distributed/sharded graph would involve lots of network latency as the traversal "hops" from machine to machine.
http://stackoverflow.com/questions/35982619/neo4j-difference-between-high-availability-and-distributed-mechanism

Neo4j: Performance & Scale

Neo4j: Productivity & Convenience

Neo4j: Ops & Security

Neo4j: + Apache Spark

Références
• [1] Robinson I., Webber J, Eifrem E., “Graph Databases”, O’Reilly, 2nd edition, ISBN
9781491930892
• [2] Vukotic A., Watt N., “Neo4j in Action”, Manning Publications, ISBN 9781617290763
• [3] Wikipedia, “Base de données orientée graphe”,
https://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_orient%C3%A9e_graphe
• [4] Willemsen C., “Découverte de Neo4j, la base de données graphe”,
http://neoxygen.io/articles/decouverte-de-neo4j.html , version 1.1, 14-01-2015
• [5] Maury F., “Pourquoi s’intéresser aux graph-databases ?”,
http://www.arolla.fr/blog/2013/10/pourquoi-sinteresser-aux-graph-databases/
• [6] Fauvet C., “Nouvelles opportunités pour les données fortement connectées: La base de
graphe Neo4j”, 10 décembre 2013
• [7] Robert M., Dutheil L., Domenjoud M., « Introduction aux graphes avec Neo4j et Gephi »
http://blog.octo.com/introduction-aux-graphes-avec-neo4j-et-gephi/
• [8] Lyon William, Introduction to Graph Databases and Neo4j - January 14, 2016,
https://www.youtube.com/watch?v=83P81ebgCxA

Backup
• la réplication
• la réplication n'est pas une distribution !!
• c'est une copie des données qui sert avant tout à assurer la redondance, donc la protection contre
la perte de données
• tolérance aux pannes, distribution des lectures, des écritures
• théorème CAP: compromis entre cohérence, disponibilité, tolérance au partitionnement
• cohérence synchrone, un maître (SGBDR)
• cohérence asynchrone, un maître
• cohérence faible
• cohérence à terme (EM: eventual consistency) e.g. MongoDB
• cohérence asynchrone, plusieurs maîtres
• cohérence faible e.g. CouchDB
• cohérence à terme (EM: eventual consistency) e.g. Cassandra
• disponibilité: élection d’un maître si ce dernier tombe en panne
• tolérance au partitionnement: élection d’un maître si cluster est coupé en deux parties

Backup
• le sharding ou partionnement
• découper une (grande) collection en fragments en fonction d’une clé
• placer chaque fragment sur un serveur
• maintenir un répertoire indiquent que telle clé se trouve dans tel fragment sur tel serveur
• le partionnement apporte la répartition de charge (load balancing)
• il doit être dynamique (ajout/retrait de serveurs) pour s’adapter « élastiquement »
• s’applique à des collections de paires (clé, valeur), où valeur est n’importe quelle information
structurée
• distribution avec maître
• partitionnement par intervalle e.g. MongoDB, Hbase, Cassandra, Redis
• l’index est tout petit par rapport à la collection
• le « routeur » reçoit les requêtes et détermine le(s) serveur(s) à solliciter
• distribution sans maître
• partitionnement par hachage e.g. memcached, Dynamo
• faire hachage cohérent (consistent hashing)

Base de données graphe et Neo4j

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Base de données graphe et Neo4j

Similaire à Base de données graphe et Neo4j (20)

Base de données graphe et Neo4j