Slides de la présentation lors de la réunion de Juin de l'AFUP Aix / Marseille

1. SGBDR vs NOSQL
Différences et « Uses Cases »
(ou dans quels cas utiliser l’un plutôt que l’autre au-delà de l’effet de mode ;p)
Focus sur ArangoBD -> LA solution NOSQL multi-modèles ^^
- Présentation par Eric DYKSTEIN le 27 Juin 2017 @ Digitick, Marseille -
Marseille

2. Qu’est-ce que le NOSQL ?
• Acronyme créé en 2009 : « Not Only SQL » -> il n’y a pas que le SQL dans la vie ;) !
• Moteurs de stockage de bases de données plus que « Systèmes de Gestion » :
→Données stockées de manière non structurée (chaque « record » peut contenir des champs ≠ )
→Aucun contrôle sur l’intégrité des données (aucune règle d’écriture applicable -> les propriétés
« cohérence » et/ou « isolation » du concept ACID ne sont généralement pas respectées)
→Aucun système d’intégrité référentielle des données entre « entités » différentes.
→Systèmes de requêtage des données plus ou moins élaborés
• 4 familles / types de moteurs de stockage distincts :
→Clés / valeurs (ex : Redis, DynamoDB, Voldemort)
→Colonnes (ex : Cassandra, BigTables, Hbase)
→Documents (ex : MongoDB, CouchDB, CouchBase)
→Graphe (ex : Neo4j)
Marseille

3. Pourquoi le NOSQL ?
• Pour répondre à des problématiques spécifiques de performance :
→En cas de très grosse volumétrie de données
→En cas de très grosses montées en charges (sites à fort trafic)
 Les moteurs NOSQL sont plus rapides en lecture et en écriture qu’un SGBDR classique car ils n’effectuent
aucun contrôle sur les données, la plupart peuvent charger leurs données en mémoire vive et/ou être
répartis sur plusieurs serveurs en parallèle (sharding).
• Pour répondre à des problématiques fonctionnelles spécifiques :
→Designer une base de donnée pour développer un système de gestion du cache (modèle Clés / Valeurs)
→Designer une base de données à la structure « super flexible » pour la réalisation d’un POC ou d’un MVP
(modèles Documents et Colonnes)
→Designer une base de données à nœuds multiples (type réseau social via le modèle Graphe)
→Designer une base de données pour se lancer dans l’aventure « Big Data » <(-_-)>
• Pour répondre à des problématiques de stockage : les collections de données n’étant pas
structurées (pas de champs prédéfinis contrairement aux tables d’un SGBDR), aucun « espace
vide » n’est réservé sur le disque dur.
Marseille

4. Les bases de données de type Clé / Valeur
• Elles permettent un stockage de paires « clé / valeur » : la clé identifie
l’enregistrement, la valeur étant la (ou les données) elle(s)-même(s)
qui est/sont gérée(s) de manière « opaque » -> le type de donnée(s)
est indéterminé et stocké généralement de manière binaire.
• Elles offrent une large flexibilité concernant le type de donnée(s) à
stocker : il peut s’agir d’une simple chaine de caractère, ou de tout
autre type de données tel un objet JSON ou des données binaires
(image, vidéo, exécutable, etc…).
• Elles stockent les données en mémoire vive lorsqu’elles sont actives
afin d’obtenir des temps de réponses très rapides.
Marseille

5. Les bases de données de type Colonnes
• Type de BDD le plus proche des SGBDR en terme de structuration de données :
Nous avons à faire à des lignes et des colonnes contenues dans des Tables -> Sauf
que les colonnes sont créées pour chaque ligne et qu’elles ne sont pas décrites
structurellement dans la définition de la Table.
• Une colonne n’existe donc pas tant qu’une donnée n’a pas été enregistrée en
base et la manière dont celles-ci sont stockées s’apparente à une paire « clé /
valeur » où la clé est le nom de la colonne et la valeur est la donnée que l’on veut
exploiter.
• Ainsi, les données ne seront pas stockées par ligne mais par colonne -> Objectif
pouvoir faire des traitements sur des colonnes spécifiques et non sur des lignes
complètes pour un balayage des données par colonne plus rapide.
Marseille

6. Les bases de données de type Documents
• Type de BDD NOSQL le plus populaire, notamment grâce à MongoDB
• Stockage des données dans des collections de documents -> Par rapport aux bases de
données relationnelles, les collections sont aux tables ce que les documents sont aux
enregistrements.
• Les données sont généralement formatées en JSON -> pratique à manipuler avec du
JavaScript, d’où le couplage célèbre « NodeJS / MongoDB »
• Possibilité de stocker tous types de données « primitives » dans une collection (boolean,
number, string), mais aussi des tableaux de données ou des objets JSON contenant eux-
mêmes des données de tous types -> possibilité de créer des arborescences de données
complexes dans un document.
• Exemple de document : {"_id" : 1 ; "marque" : "Toyota", "modele" : "Prius+", "immat" :
"DH-040-VT", "proprietaire" : {"nom" : "DYKSTEIN", "prenom" : "Eric", "adresse" : { "voie"
: "72, rue paradis" , "cp" : "13006", "ville" : "Marseille" } } }
Marseille

7. Les bases de données de type Graphe
• Type de BDD NOSQL le moins répandu, car il couvre un besoin fonctionnel très particulier
-> les relations multi-nœuds (type réseau social)
• Les enregistrements d’une base Graphe sont soit de des « noeuds » ou « nodes », soit
des « arcs » ou « edges » qui correspondent aux liens entre les « noeuds » .
• Les nœuds correspondent à une entité de données, pouvant contenir des données ou
des tableaux de données exclusivement de types primitifs (boolean, number, string),
ayant la spécificité d’être reliable à un ou plusieurs autres nœuds par des arcs.
• Un arc contient les données permettant de relier deux noeuds : un « identifiant de
noeud » de départ, un « identifiant de noeud » d’arrivée et, éventuellement, des
données complémentaires caractérisant le lien entre les deux nœuds.
• Le système de requêtage n’est pas des plus simples (pour ce que j’ai pu voir de Neo4j :p)
Marseille
En théorie…

8. Les bases de données de type Graphe
Marseille
En pratique… -> Design d’un modèle de réseau social
Relationnel
Personnes
Perso_id
Perso_nom
Perso_prenom
Relations
Perso_id_from
Perso_id_to
Relation_type
1 n
1
n
Problématiques d’interrogation de la base de
données pour retrouver le lien entre deux
personnes :
- Nombre de jointures compliqué à déterminer
pour trouver le parent/enfant le plus « éloigné » ou
le « chemin le plus court »
- Impossibilité de chercher dans deux directions
sans se casser la tête (ou faire exploser le SGBDR)
GrapheVS
Personnes
(noeud)
Perso_id
Perso_nom
Perso_prenom
Relations
(arc)
_from
_to
type
Dans une base de type graphe, les personnes sont
enregistrés comme « nœuds » et les relations comme
« arcs ». Le moteur de graphe permet d’effectuer une
recherche mono ou bidirectionnelle sans la
« lourdeur » du SQL face à cette problématique
fonctionnelle. Il est possible de déterminer une
« profondeur » de recherche.
1 n
1
n

9. Inconvénients du NOSQL
• Pas de structure de données « in database » et Zéro contrôle à l’insertion des données,
donc :
→Il faut concevoir une « structure logique » de vos collections de données et coder des contrôles
vous-même avant chaque insertion / modification pour assurer l’intégrité du type de données à
stocker (ce que vous êtes déjà censés faire, ou qu’un framework fait pour vous ;D)
→Les modifications manuelles sont à éviter pour limiter les risques de bugs dans votre application
• Pas de système de clé étrangère pour lier les collections entre elles, cependant :
→Possibilité de créer des arborescences de données à l’intérieur d’un enregistrement dans une base
de type Documents -> inconvénient sous-jacent : coder de manière récursive la lecture des
données…
→Possibilité de raccorder des « enregistrements » entre eux avec une base de type Graphe
→Sinon, relations à l’ancienne (MyISAM style pour les connaisseurs ;p) -> indiquer dans un champs
d’un document ou dans une colonne, l’identifiant du document ou de l’enregistrement d’une
autre collection / table lié à celui-ci.
Marseille
Partie 1

10. Inconvénients du NOSQL
• Mais même si on contourne le problème de l’absence de clés étrangères…
→Aucune gestion des contraintes d’intégrité référentielle, donc il va aussi falloir les coder soi-
même dans son applicatif si besoin.
→Aucune modification ou suppression en cascade dans le cas d’une gestion des relation via
une base graphe ou bien d’une gestion des relations à « l’ancienne » entre deux collections /
tables…
• Donc, sur le papier : Beaucoup plus souple, plus rapide, mais aussi plus de
précautions à prendre lors de la manipulation des données pour
conserver une certaine forme d’intégrité. Sans parler de la nécessité de
coder tout ce qui a attrait aux relations entre les données lorsque c’est
nécessaire.
Marseille
Partie 2

11. • Moteur de Bases de données NOSQL Open Source (Licence Apache V2) développé en
C++ depuis 2011 par une société allemande de consulting informatique (Deutsch Qualität
!) nommée triAGENS qui, en 2014, s’est « forkée » en une nouvelle société portant le
nom du projet pour donner pleinement vie à celui-ci. Version actuelle stable : 3.1
• Projet compilé pour plusieurs OS Linux (Debian, RedHat, Suse...) pour MacOS et
Windows (!) mais aussi pour plusieurs environnements cloud (AWS, Windows Azure, DC
/ OS) et il existe aussi une version dockerisée téléchargeable depuis le site officiel.
• 2 versions distinctes pour 3 niveaux de support :
• Community Edition sans support (ou presque : google group) mais gratuite
• Community Edition avec support basique (payant)
• Enterprise Edition (fonctionnalités supplémentaires) avec support (payant).
Marseille
Introduction Part 1

12. • Système de bases de données NOSQL capable de gérer 3 modèles différents :
→Documents (JSON …)
→Graphe (… JSON…)
→Clé / Valeur ( … et encore JSON)
☞Structurellement, les 3 modèles sont stockés / gérés comme des collections de documents de par leur
stockage au format JSON. Chaque « document » est identifié par un champs « _key », identifiant unique
du document au sein de la collection, et par un champs « _id », identifiant unique au sein de la base de
données, l’ « _id » étant constitué du « nom de la collection » / « _key » (ex : « personnes/12 » )
• Permet donc de gérer plusieurs problématiques à la fois avec un langage de manipulation des
données unique qui offre des features proches du SQL : le AQL (ArangoDB Query Language)
• La coexistence d’un modèle Documents et d’un modèle Graphe, au sein d’une même base de
données, manipulables avec un seul et même langage, permet de se retrouver avec un
système NOSQL qui permet de mettre en œuvre et d’exploiter facilement des BDD
présentant des caractéristiques « relationnelles » complexes sans passer par un SGBDR (les
contraintes d’intégrité référentielle en moins…).
Marseille
Introduction Part 2

13. • Existe des bibliothèques téléchargeables sur Github pour accéder à ArangoDB
depuis de nombreux langages de programmation ou outils : PHP, NodeJs, Java,
Python, Go, Ruby, Scala, .NET, Clojure, ElasticSearch, Vert.X,…
• Embarque Foxx, un serveur d’application + framework Javascript, basé sur le
moteur Google V8 pour développer ses propres API liées à ses bases ArangoDB.
• Plusieurs moyen d’accéder au moteur de bases de données :
• via l’API native de ArangoDB (HTTP)
• via la web user interface embarquée
• via Foxx
• via ArangoSh (mode console)
Marseille
Caractéristiques et Fonctionnalités Part 1

14. • Indexation automatique des identifiants de documents et des nœuds dans les « arcs »,
indexation manuelle possible de certains « champs » ou ensemble de champs en
imposant une contrainte d’unicité par exemple.
• Mise à disposition d’un système de « Transactions » permettant de palier aux
problématiques de « cohérence » et « d’isolation » des propriétés ACID
• Possibilité de créer des bases de données en mode « Réplication » ou « Sharding »
(déploiement d’une base de données sur plusieurs serveurs dans un cluster DC/OS basé
sur Apache Mesos)
• Possibilité de créer des collections d’indexs géographiques exploitables via des
fonctionnalités spécifiques adaptées à leur traitement (distance entre deux lieux ,
présence d’un lieu dans un périmètre,…)
Marseille
Caractéristiques et Fonctionnalités Part 2

15. Marseille

16. • En mode lecture, fonctionne avec une ou plusieurs boucles « FOR » qui balaye(nt)
l’ensemble des documents de la ou des collections dont on veut consulter les
données. Le résultat d’une requête de lecture en AQL est toujours un « Array ».
Exemple de Lecture simple de données dans une collection :
FOR p in Personnes FILTER p.age > 25 RETURN { nom : p.nom, prenom : p.prenom}
Equivalent SQL :
SELECT p.nom, p.prenom FROM Personnes p WHERE p.age > 25
Exemple avec imbrication pour effectuer une jointure « classique » entre deux collections :
FOR p in personnes FOR v in Vehicules FILTER v.perso.id == p._id RETURN { nom : p.nom, prenom :
p.prenom, immat : v.immat}
Equivalent SQL :
SELECT p.nom, p.prenom, v.immat FROM Personnes p JOIN Vehicules v on p.id = v.perso_id
Marseille
Le AQL – Lecture simple

17. • En mode écriture, la syntaxe est très proche du SQL et conserve le système
de boucles « FOR » pour réaliser des opérations sur plusieurs documents.
Exemples d’insert, update et delete simple :
INSERT { nom : "Dykstein" , prenom : "Eric"} IN Personnes
UPDATE DOCUMENT("personnes/12") WITH { age : 35 } IN Personnes
REMOVE { _key: "12" } IN Personnes
Exemple d’update avec une boucle :
FOR p in Personnes UPDATE p WITH { age : p.age + 1 } IN Personnes
• Il existe aussi les instructions REPLACE et UPSERT (UPDATE or INSERT).
Marseille
Le AQL – Mises à jour

18. Marseille
Le AQL – Parcours de Graphe – Use Case

19. • Une requête AQL dont le but est de parcourir un graphe est appelée « Traversal ». Ce type
de requête doit mentionner à minima : un sommet (nœud) (l’id d’un document) et une
collection d’arcs / edges. A savoir qu’il est parfaitement possible de traverser plusieurs
collections d’arcs différentes. NB : Chaque arc contient une donnée « _from » et « _to ».
• Il est possible de mentionner une direction spécifique à parcourir à travers les nœuds du
graphe, et une profondeur de recherche -> le nombre minimum ou maximum de sommets à
parcourir pour atteindre la ou les informations souhaitées.
• Il est possible de récupérer le(s) chemin(s) parcouru(s) pour atteindre la /les informations
souhaitées en plus de celle(s)-ci.
• Une requête de type Traversal peut s’appuyer soit sur un ensemble collections d’arcs/edges
donnés, soit sur une entité ArangoDB de type Graphe qu’il faut « décrire » en amont (et qui
permet notamment d’avoir une représentation graphique via l’interface web).
• Deux types de requêtes Traversal possibles : le parcours de graphe classique, et la
recherche du « chemin le plus court ».
Marseille
Le AQL – Parcours de Graphe - Introduction

20. • A l’instar d’une requête de lecture simple, un Traversal s’appuie sur une
boucle « FOR » qui peut prendre jusqu’à 3 variables : le sommet/noeud visité
(obligatoire), l’arc/edge traversé (optionnel) et le chemin parcouru jusqu’ici / path
(optionnel) -> ces variables seront alimentées par les données obtenues lors du
parcours du graphe.
Exemple de parcours de graphe simple (retourne les relations de 1er niveau d’une personne) :
FOR v, e IN OUTBOUND "personnes/27331798" relations RETURN { nom : v.nom, prenom : v.prenom,
relation : e.type}
Exemple de parcours de graphe avec profondeur et unicité des sommets dans la liste des résultats
(retourne toutes les relations de niveau 1 à 4, sans résultat doublonné) :
FOR v, e, p IN 1..4 ANY "personnes/27331798" relations OPTIONS { uniqueVertices : "global", bfs :
true} RETURN { nom : v.nom, prenom : v.prenom, relation : e.type}
Marseille
Le AQL – Parcours de Graphe – En pratique - Part 1

21. Exemple de parcours de graphe avec critère sur le type de relation sur tout le parcours
(retourne les relations de niveau 1 à 3 d’une personne qui sont liées par un lien amical) :
FOR v, e, p IN 1..3 ANY "personnes/27331798" relations FILTER p.edges[*].type ALL == "ami" RETURN
{ nom : v.nom, prenom : v.prenom, relation : e.type}
• Le second type de requête Traversal, permettant d’atteindre le chemin le plus court
(ou « Shortest Path »), s’appuie sur une syntaxe légèrement différente. Cette requête
renvoie tous les nœuds y compris celui de départ. Un seul inconvénient : impossible
de mettre un critère de recherche mais il est possible d’arriver au même résultat avec
un Traversal classique en appliquant un filtre, la requête sera juste plus longue…
FOR v, e IN ANY SHORTEST_PATH "personnes/27331798" TO "personnes/27331824" relations
RETURN { nom : v.nom, prenom : v.prenom, relation : e.type}
Marseille
Le AQL – Parcours de Graphe – En pratique - Part 2

22. Le site officiel : http://www.arangodb.com
 Super bien documenté (non mais vraiment ! ^^)
Mais pas de version française (faut pas rêver ;p)
Et si vous voulez un T-shirt (gratuit) ArangoDB ou Foxx, vous venez me
voir -> j’en ai une vingtaine dont 3 taille fille :o !
Marseille
Pour aller plus loin…

23. Des questions :) ?
Contact info :
Mail : eric@recrut-info.com / e@riw.fr
Twitter : @edykstein
Merci pour votre attention ^o^ !
Marseille