SlideShare une entreprise Scribd logo
1  sur  23
Télécharger pour lire hors ligne
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
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
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
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
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
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
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…
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
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
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
• 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
• 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
• 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
• 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
Marseille
• 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
• 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
Marseille
Le AQL – Parcours de Graphe – Use Case
• 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
• 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
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
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…
Des questions :) ?
Contact info :
Mail : eric@recrut-info.com / e@riw.fr
Twitter : @edykstein
Merci pour votre attention ^o^ !
Marseille

Contenu connexe

Tendances

Bases de donnees fondamentaux
Bases de donnees fondamentauxBases de donnees fondamentaux
Bases de donnees fondamentauxRokhaya CISSE
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQLAntoine Augusti
 
Presentation Hadoop Québec
Presentation Hadoop QuébecPresentation Hadoop Québec
Presentation Hadoop QuébecMathieu Dumoulin
 
Chp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleChp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleLilia Sfaxi
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingLilia Sfaxi
 
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Hatim CHAHDI
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataLilia Sfaxi
 
Chp2 - Les Entrepôts de Données
Chp2 - Les Entrepôts de DonnéesChp2 - Les Entrepôts de Données
Chp2 - Les Entrepôts de DonnéesLilia Sfaxi
 
Découvrez Power BI - [webinaire avec demo]
Découvrez Power BI - [webinaire avec demo]Découvrez Power BI - [webinaire avec demo]
Découvrez Power BI - [webinaire avec demo]Technologia Formation
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQLSamy Dindane
 
La démo DAX, le langage de Power BI [webinaire]
La démo DAX, le langage de Power BI [webinaire]La démo DAX, le langage de Power BI [webinaire]
La démo DAX, le langage de Power BI [webinaire]Technologia Formation
 
BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherLilia Sfaxi
 
Cours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkCours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkAmal Abid
 
L’analyse de l’apprentissage (learning analytics): une revue de littérature
L’analyse de l’apprentissage (learning analytics): une revue de littératureL’analyse de l’apprentissage (learning analytics): une revue de littérature
L’analyse de l’apprentissage (learning analytics): une revue de littératureAudrey Bistodeau, CPA, CA, MBA
 
BigData_TP5 : Neo4J
BigData_TP5 : Neo4JBigData_TP5 : Neo4J
BigData_TP5 : Neo4JLilia Sfaxi
 
Business Intelligence
Business IntelligenceBusiness Intelligence
Business Intelligences.poles
 
cours base de données
cours base de donnéescours base de données
cours base de donnéesYassine Badri
 

Tendances (20)

Tp talend BI
Tp talend BITp talend BI
Tp talend BI
 
introduction à MongoDB
introduction à MongoDBintroduction à MongoDB
introduction à MongoDB
 
Bases de donnees fondamentaux
Bases de donnees fondamentauxBases de donnees fondamentaux
Bases de donnees fondamentaux
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQL
 
Presentation Hadoop Québec
Presentation Hadoop QuébecPresentation Hadoop Québec
Presentation Hadoop Québec
 
Chp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleChp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation Multidimensionnelle
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data Processing
 
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big Data
 
Chp2 - Les Entrepôts de Données
Chp2 - Les Entrepôts de DonnéesChp2 - Les Entrepôts de Données
Chp2 - Les Entrepôts de Données
 
Découvrez Power BI - [webinaire avec demo]
Découvrez Power BI - [webinaire avec demo]Découvrez Power BI - [webinaire avec demo]
Découvrez Power BI - [webinaire avec demo]
 
Hadoop
HadoopHadoop
Hadoop
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
 
La démo DAX, le langage de Power BI [webinaire]
La démo DAX, le langage de Power BI [webinaire]La démo DAX, le langage de Power BI [webinaire]
La démo DAX, le langage de Power BI [webinaire]
 
BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all together
 
Cours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkCours Big Data Chap4 - Spark
Cours Big Data Chap4 - Spark
 
L’analyse de l’apprentissage (learning analytics): une revue de littérature
L’analyse de l’apprentissage (learning analytics): une revue de littératureL’analyse de l’apprentissage (learning analytics): une revue de littérature
L’analyse de l’apprentissage (learning analytics): une revue de littérature
 
BigData_TP5 : Neo4J
BigData_TP5 : Neo4JBigData_TP5 : Neo4J
BigData_TP5 : Neo4J
 
Business Intelligence
Business IntelligenceBusiness Intelligence
Business Intelligence
 
cours base de données
cours base de donnéescours base de données
cours base de données
 

Similaire à SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB

Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTCHAKER ALLAOUI
 
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICNoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICLa FeWeb
 
cours06-nosql.pdf
cours06-nosql.pdfcours06-nosql.pdf
cours06-nosql.pdfhbadir
 
Base de données NoSQL
Base de données NoSQLBase de données NoSQL
Base de données NoSQLOussama ARBI
 
Base de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvreBase de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvreMICHRAFY MUSTAFA
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010JUG Lausanne
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - IntroductionBlandine Larbret
 
resume-theorique-m106-partie3-0903-1-622f07613b825.pdf
resume-theorique-m106-partie3-0903-1-622f07613b825.pdfresume-theorique-m106-partie3-0903-1-622f07613b825.pdf
resume-theorique-m106-partie3-0903-1-622f07613b825.pdfFootballLovers9
 
A Brief History of Database Management (SQL, NoSQL, NewSQL)
A Brief History of Database Management (SQL, NoSQL, NewSQL)A Brief History of Database Management (SQL, NoSQL, NewSQL)
A Brief History of Database Management (SQL, NoSQL, NewSQL)Abdelkader OUARED
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdfZkSadrati
 
La persistance des données : ORM et hibernate
La persistance des données : ORM et hibernateLa persistance des données : ORM et hibernate
La persistance des données : ORM et hibernateYouness Boukouchi
 
Database/ Bases de données
Database/ Bases de donnéesDatabase/ Bases de données
Database/ Bases de donnéeszied kallel
 
Serveur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développementServeur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développementLudovic REUS
 
La caisse à outils de la visualisation d'informations
La caisse à outils de la visualisation d'informationsLa caisse à outils de la visualisation d'informations
La caisse à outils de la visualisation d'informationsChristopheTricot
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamTelecomValley
 

Similaire à SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB (20)

NoSQL MeetUp
NoSQL MeetUpNoSQL MeetUp
NoSQL MeetUp
 
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
 
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICNoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
 
cours06-nosql.pdf
cours06-nosql.pdfcours06-nosql.pdf
cours06-nosql.pdf
 
MariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQLMariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQL
 
Base de données NoSQL
Base de données NoSQLBase de données NoSQL
Base de données NoSQL
 
Les BD NoSQL
Les BD NoSQLLes BD NoSQL
Les BD NoSQL
 
Base de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvreBase de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvre
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
 
resume-theorique-m106-partie3-0903-1-622f07613b825.pdf
resume-theorique-m106-partie3-0903-1-622f07613b825.pdfresume-theorique-m106-partie3-0903-1-622f07613b825.pdf
resume-theorique-m106-partie3-0903-1-622f07613b825.pdf
 
A Brief History of Database Management (SQL, NoSQL, NewSQL)
A Brief History of Database Management (SQL, NoSQL, NewSQL)A Brief History of Database Management (SQL, NoSQL, NewSQL)
A Brief History of Database Management (SQL, NoSQL, NewSQL)
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdf
 
La persistance des données : ORM et hibernate
La persistance des données : ORM et hibernateLa persistance des données : ORM et hibernate
La persistance des données : ORM et hibernate
 
Database/ Bases de données
Database/ Bases de donnéesDatabase/ Bases de données
Database/ Bases de données
 
Serveur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développementServeur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développement
 
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka StreamsTraitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
 
La caisse à outils de la visualisation d'informations
La caisse à outils de la visualisation d'informationsLa caisse à outils de la visualisation d'informations
La caisse à outils de la visualisation d'informations
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler Softeam
 

Dernier

Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IAMilo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IAUGAIA
 
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...OCTO Technology
 
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...Faga1939
 
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdfEtude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdfsnapierala
 
Intelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imaginationIntelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imaginationTony Aubé
 
GUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - MontréalGUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - MontréalNicolas Georgeault
 
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudLe Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudOCTO Technology
 

Dernier (7)

Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IAMilo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
Milo-AI Milo AI Congress est conçu pour transformer votre compréhension de l'IA
 
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
 
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
LA SUPERINTELLIGENCE ARTIFICIELLE, SES BÉNÉFICES ET NUIRES ET QUE FAIRE POUR ...
 
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdfEtude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
Etude_Bpifrance_-_Les_Greentech_francaises_-_3eme_edition_annuelle_2024.pdf
 
Intelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imaginationIntelligence Artificielle: Vers l'ère de l'imagination
Intelligence Artificielle: Vers l'ère de l'imagination
 
GUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - MontréalGUM365 - Rencontre mensuelle Avril 2024 - Montréal
GUM365 - Rencontre mensuelle Avril 2024 - Montréal
 
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudLe Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
 

SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB

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