Présentation CNAM 19 janvier 2016

1. Bases de données graphe
19 janvier 2016 1

2. Présentation
Boris Guarisma
• Consultant Data Science (et Big Data)
• 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:
• https://fr.linkedin.com/in/borisguarisma
19 janvier 2016 2

3. 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
19 janvier 2016 3

4. Agenda
• Introduction
• Problématique
• Base de données graphe
• Cas d’usage
• Stockage et traitement graphe
• Labeled property graph model
• Relationnel vs graphe
19 janvier 2016 4
• Neo4j
• Architecture
• Cypher
• Core API et Traversal API
• Manuel utilisateur (web)
• Résilience
• Partitionnement
• Démo

5. Introduction
• Les données augmentent en volume … et elles sont de plus en plus connectées.
19 janvier 2016 5

6. Problématique
Par rapport aux bases de données relationnelles (SGBDR):
• Outils traditionnels pour la gestion des données et de leur relations.
• Malgré leur nom, les SGBDR ne fonctionnent pas très bien avec le traitement ou gestion
des relations.
• Un SGBDR doit utiliser des multiples jointures très coûteuses en termes de performance.
• Inadaptées pour les systèmes transactionnels OLTP nécessitant des réponses en temps
réel
• L'écriture des requêtes très complexes
• Redéfinition du schéma si l’on souhaite ajouter de nouveaux types de données ou une
nouvelle relation, … cela prend beaucoup de temps.
19 janvier 2016 6

7. Problématique
Par rapport aux autres bases NoSQL (orienté document ou clé-valeur):
• 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.
• Beaucoup ne supportent pas l’intégrité transactionnelle (ACID)
19 janvier 2016 7

8. Bases de données graphe
• Un système de base de données graphe est un
SGBD avec des méthodes CRUD (Create, Read,
Update, Delete) qui expose un modèle de
données sous forme de graphe.
• Une base de données graphe est optimisée
pour la performance transactionnelle, conçue
pour offrir de l’intégrité transactionnelle et de
la disponibilité opérationnelle.
• Neo4j
• diffère de certaines technologies NoSQL en étant
pleinement compatible ACID (atomicité, cohérence,
isolation, durabilité).
• offre les mêmes garanties qu’un système
traditionnel de base de données relationnelle.
19 janvier 2016 8

9. Cas d’usage
• Réseaux sociaux
• Détection de fraude
• Analyse des réseaux IT
• Systèmes de recommandations
• …
19 janvier 2016 9

10. Stockage et traitement graphe
19 janvier 2016 10

11. Stockage et traitement graphe
• 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.
• Un stockage natif n’est pas supporté par des 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.
19 janvier 2016 11

12. Stockage et traitement graphe
• 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).
19 janvier 2016 12

13. Labeled Property Graph Model
19 janvier 2016 13
• Les « property graphs » sont un type de
graphe particulier dans lequel à la fois les
nœuds et les relations peuvent avoir des
propriétés, ce qui offre donc un modèle de
données entièrement dynamique [7].
• Composés par
• des nœuds
• des relations
• des propriétés
• des libellés

14. Labeled Property Graph Model
• Les nœuds et relations contiennent des
propriétés sous la forme de paires clé-valeur
arbitraires.
• Une relation a toujours une direction, un seul
nom, et un nœud de départ et un nœud de fin.
• Les propriétés des relations fournissent
• des métadonnées supplémentaires pour les
algorithmes de graphes,
• une sémantique supplémentaire aux relations (y
compris une qualité et un poids),
• contraintes pour les requêtes à l'exécution.
19 janvier 2016 14

15. Relationnel vs. Graphe
• Grâce aux structures internes des tables, les SGBDR sont plus adaptés à des requêtes de
type trouver toutes les entités de type X et à des opérations d’agrégation sur toutes les
lignes d'une table.
• Les bases de données de graphe ne souffrent pas des mêmes problèmes de latence que
les bases de données relationnelles traditionnelles, où plus il y a de données dans les
tables (et dans les index), plus longues seront les opérations de jointure.
19 janvier 2016 15

16. Relationnel vs. Graphe
Latence
• 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.
• 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.
19 janvier 2016 16

17. Relationnel vs. 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).
19 janvier 2016 17

18. Relationnel vs. Graphe
• 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).
19 janvier 2016 18

19. Neo4j
• Neo Technology, leader mondial des bases de données Graph
• Editeur de la base de données graphe Neo4j depuis 2000
• QG à Palo Alto (CA) aux USA, ingénierie à Malmö en Suède
• Présence en France, Allemagne, Angleterre, Suède, USA, Grèce et Malaisie
• 100,000+ utilisateurs (il y a un an …)
• Top 500 clients: Adobe, Cisco, Deutsche Telecom, Telenor, SFR, Lockheed Martin, etc.
• Support global 24/7
• Partenaires locaux ou globaux tells que Accenture
• Partenaires technologiques tells que VMWare, Informatica et Microsoft
19 janvier 2016 19

20. Neo4j
19 janvier 2016 20

21. Neo4j
19 janvier 2016 21

22. Neo4j
• 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.
19 janvier 2016 22

23. Neo4j - Cypher
19 janvier 2016 23

24. Neo4j – Core API & Traversals
19 janvier 2016 24

25. Neo4j
• Manuel utilisateur (web)
19 janvier 2016 25
• File buffer cache
• Object cache:
• References caches
• High-Performance Cache
• File Sizes
• Read speed
• Write sped
• Data size

26. Neo4j
• Résilience: haute disponibilité
• Le plus souvent, nous regroupons les instances de base de données pour une haute disponibilité.
• Neo4j utilise une structure de cluster maître-esclave pour garantir qu'une réplique complète du
graphe est stocké sur chaque machine.
• Les écritures sont répliquées à partir du maître vers les esclaves à des intervalles fréquents.
• À tout moment, le maître et quelques esclaves auront une copie complètement à jour du graphe,
tandis que d'autres esclaves se rattraperont (généralement, ils seront en retard de quelques
millisecondes).
19 janvier 2016 26
“Understanding
Neo4j Scalability”
(Jan 2013)

27. Neo4j
• 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.
19 janvier 2016 27
“On Sharding
Graph Databases”
(Feb 2011)
“Understanding
Neo4j Scalability”
(Jan 2013)

28. BACKUP SLIDES
19 janvier 2016 28

29. BACKUP SLIDES
19 janvier 2016 29
• 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

30. BACKUP SLIDES
19 janvier 2016 30
• 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)

31. BACKUP SLIDES
• Labeled Property Graph Model
• Tous les nœuds ont un libellé Asset en plus
d’un libellé plus spécifique e.g., Database,
VM, App, Server, Rack, LoadBalancer.
19 janvier 2016 31