Neo4J dans la mouvance NOSQL

Qui sommes-nous ?

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

Plan

  1. NOSQL ?

  2. Neo4J

La mouvance NOSQL

NOSQL ? ça sonne un peu comme ça...

...ou comme ça

NOSQL = Not Only SQL

<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 :

Illustration

L'hégémonie relationnelle vs Les autres BDD

Les autres modèles tels que :

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 :

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 :

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 :

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 ;)

</Flashback>

La famille NOSQL

 

Bien sûr il n'y a ici que les principaux acteurs du genre.

SGBD vs Key/Value

Document

Column

Last but not least...

Les bases de données Graphes :

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 ?

Présentation de Neo4J

Pourquoi Neo4J ?

Roadmap

BDD orientée graphe ?

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:

Recherche sur graphe (II/III)

Depth-first search

Propriétés intéressantes:

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

Concepts I · 3 fondamentaux à retenir

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 :

SpringData/*

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 · fonctionnalités

Les fonctionnalités communes entre les tous les projets SpringData/* sont regroupées dans Spring Data Commons.

Aperçu

SpringData/Neo4J

Extraits choisis (1/3)

SpringData/Neo4J

Extraits choisis (2/3)

SpringData/Neo4J

Extraits choisis (3/3)

DevInLove!

Concept :

Vous permettre de trouver l'âme soeur programmatiquement en se basant :

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”)

Conclusion

Questions ?

/

#