Neo4J dans la mouvance NOSQL
Qui sommes-nous ?
-
Olivier Girardot
-
Florent Biville
Et Lateral Thoughts ?
Société d'informatique composée de développeurs passionnés qui apportent leur expertise à tous ceux qui le souhaitent :)
En quelques mots
- Innovante : la société est composée uniquement de développeurs
- Transparente : chacun a le même poids de décision et accès aux mêmes informations
- Fun : projets communs, time-off ...
NOSQL ? ça sonne un peu comme ça...
...ou comme ça
NOSQL = Not Only SQL
- Le terme date de 1998 et est popularisé en 2009
- Il regroupe des bases de données très différentes
- Éloigné du modèle relationnel des SGBDR (Oracle, PostgreSQL etc.)
- Souvent associé à des modèles scalables, mais pas que.
<Flashback about="le modèle relationnel">
Les concepts basics
Le modèle relationnel a éte défini par Edgar Codd il y a 40 ans.
Une base de données relationnelle est faite de :
- tables
- ... elles-mêmes faites de colonnes
- ... définies avec certaines propriétés (identité, unicité, nullabilité ...)
- ... et dont certaines référencent des colonnes d'autres tables
Illustration
L'hégémonie relationnelle vs Les autres BDD
Les autres modèles tels que :
- les bases de données hiérarchiques (Adabas, SoftwareAG)
- les bases de données objet
- les bases de données XML
ne se sont peu ou pas imposés.
L'hégémonie relationnelle vs la Programmation Orientée Objet
Côté applicatif, c'est le paradigme objet qui s'est imposé (on en revient). Soit :
- d'un côté, un monde objet
- de l'autre, un monde de relations
Cela a donc donné naissance aux... Object-Relational Mappers (côté Java: JPA a.k.a. JSR 317) : un pont entre deux paradigmes complètement différents...
... avec beaucoup plus de contraintes qu'on veut nous faire croire.
Le modèle relationnel actuellement menacé ?
Certains cas d'utilisation avancés (exemple : "indexer le web") ont poussé le modèle relationnel à bout.
Notamment à cause des contraintes suivantes :
- ACID
- SQL
- SHARDING
- cf. CAP de Brewer
BUZZWORD WARNING !
ACID ?
- Atomicity
- Chaque transaction est vue comme une opération unique. Toutes ou aucune des modifications sont persistées (commit/rollback), aucun état intermédiaire n'est permis.
- Consistency
- Chaque état atteint par le système de persistance est stable et valide.
- Isolation
- Chaque transaction a son propre état, indépendant des autres transactions en cours d'exécution.
- Durability
- Tout résultat committé doit persister en permanence même après crash.
Sharding ?
Partitionnement horizontal des données, i.e. par lignes plutôt que par colonne, sur un critère donné.
Théorème de CAP ?
L'hégémonie relationnelle (on reprend)
... et il a ses limites :
- ACID et SQL coûtent cher
- Le seul vrai moyen efficace de rendre scalable une BDD relationnelle, c'est le sharding !
- Le SHARDING c'est dur ! et ça dépend beaucoup du métier...
- Le théorème CAP de Brewer est inévitable
Conclusion ?
On a beaucoup progressé pour faire monter en charge et répliquer nos applications, beaucoup moins avec les systèmes persistant les données qu'elles manipulent !
Indice : on peut faire mieux ;)
La famille NOSQL
- Key-Value Store :
- Redis
- BerkeleyDB
- (et dans un sens Cassandra/RIAK)
- Document Oriented :
- Column oriented :
- les versatiles :
- Tokyo Cabinet
- et Kyoto Cabinet
Bien sûr il n'y a ici que les principaux acteurs du genre.
SGBD vs Key/Value
Column
Last but not least...
Les bases de données Graphes :
- AllegroGraph
- Bigdata
- CloudGraph
- Cytoscape
- DEX
- Filament
- GraphBase
- Graphd
- Horton
- HyperGraphDB
- InfiniteGraph
- InfoGrid
- Neo4j
- OrientDB
- OQGRAPH
- sones GraphDB
- VertexDB
- Virtuoso Universal Server
- R2DF
- GiraffeDB
Spécialisation
Dans la même mouvance que le Polyglot Programming (1 langage pour 1 cas d'utilisation), chaque type de datastore NOSQL correspond à des contraintes métier différentes.
Et si on s'orientait vers ça ?
Pourquoi Neo4J ?
Base de données écrite en Java
Supportée commercialement par Neo Technology
Rapprochement récent de SpringSource
Roadmap
Version stable: 1.7.2
1.8 dans les cartons
BDD orientée graphe ?
Données fortement inter-connectées
Les Graphes représentent bien un modèle Objet
Est plus facilement scalable qu'un SGBDR, pas de jointures coûteuses
Modèle rempli d'algorithmes efficaces
et bien connus en Recherche Opérationnelle
Flexible et souvent Schema-Less
Graphe, vous avez dit graphe ?
Le graphe le plus simple du monde
Un graphe un peu plus intéressant
Autres modes de représentations
Sous forme de matrice d'adjacence :
Autres modes de représentations
Sous forme de liste d'adjacence : tableau de liste de sommets
Recherche sur graphe (I/III)
Breadth-first search
Propriétés intéressantes:
- Complexité: O(n) où n=somme du nombre de vertices et d'egdes
- Tous les plus courts chemins depuis le vertex racine sont découverts
Recherche sur graphe (II/III)
Depth-first search
Propriétés intéressantes:
- Classification des edges:
- tree edges
- back edges
- forward edges
- cross edges
- Tri topologique possible
Recherche sur graphe (III/III)
Tri topologique avec une depth-first search (très fortement inspiré de la figure 22.7 de "Introduction to Algorithms", chapitre 22.4)
Avant
Après
Note: cela ne fonctionne qu'avec des graphes acycliques orientés.
Algorithmes non couverts
- Minimum Spanning trees
- Shortest Path (Bellman-Ford, Dijkstra, Floyd-Warshall...)
- Maximum Flow (Ford-Fulkerson, Edmonds-Karp)
- et bien d'autres... suivez donc le cours de M. Mainguenaud ;)
Concepts I · 3 fondamentaux à retenir
-
Noeud (vertex, node)
La forme la plus simple d'un graphe.
Node iAmANode = graphDatastore.createNode();
-
Relation (relationship, edge)
Permet d'organiser les noeuds.
iAmANode.createRelationshipTo(anotherNode, ExampleRelationships.ROMANTIC);
-
Propriété (property, key/value pairs)
Enrichit les noeuds et les relations.
iAmANode.setProperty("having", "a property!");
Présentation de Neo4J - le retour
Exemple I · création d'un graphe
Exemple II · traversée de graphe
Exemple III · index
Implémentation embarquée par défaut: Lucène.
Les index supportent également le pseudo-requêtage sur les valeurs indexées (ex: index.query("key","*e*")
).
Requêtage
Gremlin
Langage de traversée de graphe intégré en Groovy basé sur l'effort de standardisation d'accès aux graphes appelé "Blueprints".
Gremlin supporte Neo4J, OrientDB, DEX...
Cypher
Cypher est un langage de requêtage principalement développé par Neo Technologies.
Il supporte uniquement Neo4J et est en perpétuelle évolution.
Il se veut une alternative à Gremlin, compréhensible par les dévs et les ops dont la syntaxe s'inspire du SQL.
Présentation de SpringData
L'écosystème Spring
Spring est à la base un framework d'injection de dépendance (appelé maintenant Spring Core) simplifiant les développements et la testabilité des projets Java/JEE.
L'écosystème s'est agrandi bien au-delà de l'injection de dépendance pour compter :
- Spring Security
- Spring Batch
- Spring MVC
- ...
- et aussi SpringData qui nous intéresse aujourd'hui
Projet ombrelle visant à faciliter l'intégration de la couche d'accès aux données aux applications se reposant sur Spring Core.
Quelques projets existants
- SpringData/JPA
- SpringData/MongoDb
- SpringData/Redis
- SpringData/Neo4J
Les fonctionnalités communes entre les tous les projets SpringData/* sont regroupées dans Spring Data Commons.
Aperçu
Concept :
Vous permettre de trouver l'âme soeur programmatiquement en se basant :
- Sur vos mascottes préférées : Tux, Django Poney, elePHPant
- Vos outils favoris : IntelliJIDEA, Eclipse, Git, CVS...
- etc...
Cohabitation avec l'existant
Entités partielles
Permet de partager la persistence d'une entité entre Neo4J et un autre store.
Exemple (tiré de “Good Relationships, The Spring Data Neo4j Guide Book”)
Questions ?
- Florent Biville : @fbiville
- Olivier Girardot : @ogirardot
←
→
/
#