Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

1 144 vues

Publié le

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

Publié dans : Technologie
  • Login to see the comments

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

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Marseille
  16. 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. 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. 18. Marseille Le AQL – Parcours de Graphe – Use Case
  19. 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. 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. 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. 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. 23. Des questions :) ? Contact info : Mail : eric@recrut-info.com / e@riw.fr Twitter : @edykstein Merci pour votre attention ^o^ ! Marseille

×