yang db
1.0.0
https://www.yangdb.org/
wiki
Informations sur la version
Notes de version
Lior Perry
Romain Margolis
Moti Cohen
Elad Wies
Shimon Benoshti
Un article présentant notre nouvelle initiative Open source pour la création d'une base de données graphique distribuée évolutive via Opensearch https://www.linkedin.com/pulse/making-db-lior-perry/
Une autre utilisation d'Opensearch comme base de données graphique https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
Le monde des bases de données graphiques a eu un impact considérable au cours des dernières années, notamment en ce qui concerne les réseaux sociaux et leur impact sur notre activité quotidienne.
Le SGBDR autrefois puissant (et solitaire) est désormais obligé de céder la place à un partenaire émergent et de plus en plus important dans le centre de données : la base de données graphique.
Twitter l'utilise, Facebook l'utilise, même les sites de rencontres en ligne l'utilisent ; ils utilisent des graphiques de relations. Après tout, le social est social et, en fin de compte, tout est une question de relations.
Deux éléments principaux distinguent la technologie des graphes : le stockage et le traitement.
Le stockage graphique fait généralement référence à la structure de la base de données qui contient les données graphiques.
Un tel stockage de graphiques est optimisé pour les graphiques sous de nombreux aspects, garantissant que les données sont stockées efficacement, gardant les nœuds et les relations proches les uns des autres dans la couche physique réelle.
Le stockage graphique est classé comme non natif lorsque le stockage provient d'une source externe, telle qu'une base de données relationnelle, en colonnes ou tout autre type de base de données (dans la plupart des cas, un magasin NoSQL est préférable)
Les bases de données graphiques non natives comprennent généralement des magasins de valeurs relationnelles, de documents et de clés existants, adaptés aux scénarios de requête du modèle de données graphiques.
Le traitement graphique comprend l'accès au graphique, la traversée des sommets et des arêtes et la collecte des résultats.
Un parcours est la façon dont vous interrogez un graphique, en naviguant des nœuds de départ aux nœuds associés, en suivant les relations selon certaines règles.
trouver des réponses à des questions telles que « quelle musique mes amis aiment-ils et que je ne possède pas encore ? »
L'un des modèles les plus populaires pour représenter un graphique est le modèle de propriété.
Ce modèle contient des entités connectées (les nœuds) qui peuvent contenir n'importe quel nombre d'attributs (paires clé-valeur).
Les nœuds ont un identifiant unique et une liste d'attributs représentent leurs fonctionnalités et leur contenu.
Les nœuds peuvent être marqués d'étiquettes représentant leurs différents rôles dans votre domaine. En plus des propriétés de relation, les étiquettes peuvent également servir des métadonnées sur les éléments du graphique.
Les nœuds sont souvent utilisés pour représenter des entités mais, selon les domaines, les relations peuvent également être utilisées à cette fin.
La relation est représentée par les nœuds source et cible qu'ils connectent et en cas de connexions multiples entre les mêmes sommets – étiquette de propriété supplémentaire à distinguer (type de relation)
Les relations organisent les nœuds en structures arbitraires, permettant à un graphique de ressembler à une liste, un arbre, une carte ou une entité composée, chacune pouvant être combinée en structures encore plus complexes.
Tout comme les clés étrangères entre les tables dans le modèle de base de données relationnel, la relation dans le modèle graphique décrit les relations entre les sommets.
Une différence majeure dans ce modèle (par rapport au schéma relationnel strict) est que cette structure sans schéma permet d'ajouter/supprimer des relations entre les sommets sans aucune contrainte.
Un modèle de graphique supplémentaire est le modèle Resource Description Framework (RDF).
Notre cas d'usage se situe dans le domaine des réseaux sociaux. Un très grand graphe social qui doit être fréquemment mis à jour et disponible à la fois pour :
recherche simple (principalement textuelle)
requêtes basées sur des graphiques.
Toutes les lectures et écritures sont effectuées simultanément avec un temps de réponse raisonnable et un débit toujours croissant.
La première exigence a été remplie grâce à Opensearch, un moteur de recherche et de stockage de documents NoSql bien connu et établi, capable de contenir un très grand volume de données.
Pour la deuxième exigence , nous avons décidé que notre meilleure solution serait d'utiliser Opensearch comme couche de stockage graph-DB non native .
Comme mentionné précédemment, une couche de stockage graph-DB peut être implémentée à l'aide d'un stockage non natif tel que le stockage NoSql.
Dans une discussion future, j'expliquerai en détail pourquoi l'alternative communautaire la plus populaire pour graph-DB – Neo4J, ne pouvait pas répondre à nos besoins.
Le premier problème de notre tâche est de concevoir le modèle de données représentant le graphe, comme un ensemble de sommets et d’arêtes.
Avec Opensearch, nous pouvons utiliser ses puissantes capacités de recherche pour récupérer efficacement les documents de nœuds et de relations en fonction des filtres de requête.
Dans Opensearch, chaque index peut être décrit comme une table pour un schéma spécifique, l'index lui-même est partitionné en éléments partagés qui permettent l'évolutivité et la redondance (avec des répliques) à travers le cluster.
Un document est acheminé vers une partition particulière dans un index à l'aide de la formule suivante :
shard_num = hash(_routing) % num_primary_shards
Chaque index possède un schéma (appelé type dans Opensearch) qui définit la structure des documents (appelé mappage dans Opensearch). Chaque index ne peut contenir qu'un seul type de cartographie (depuis Opensearch 6)
L'index des sommets contiendra les documents des sommets avec les propriétés, l'index des arêtes contiendra les documents des arêtes avec leurs propriétés.
La façon dont nous décrivons comment parcourir le graphique (source de données)
Il existe peu de langages de requête orientés graphes :
Cypher est un langage de requête pour la base de données de graphes Neo4j (voir l'initiative openCypher)
Gremlin est un langage de traversée de graphiques Apache Software Foundation pour les systèmes graphiques OLTP et OLAP.
SPARQL est un langage de requête pour les graphes RDF.
Certains langages sont davantage basés sur des modèles et déclaratifs, d’autres sont plus impératifs – ils décrivent tous la manière logique de parcourir les données.
Considérons Cypher - un langage déclaratif inspiré de SQL pour décrire visuellement des modèles dans des graphiques à l'aide d'une syntaxe ascii-art.
Il nous permet d'indiquer ce que nous voulons sélectionner, insérer, mettre à jour ou supprimer de nos données graphiques sans nous obliger à décrire exactement comment le faire.
Une fois qu'une requête logique est donnée, nous devons la traduire vers la couche physique du stockage de données qui est Opensearch.
Opensearch a une requête DSL qui se concentre sur la recherche et les agrégations – pas sur le parcours, nous avons besoin d'une phase de traduction supplémentaire qui prendra en compte la structure schématique du graphe (et les indices sous-jacents).
La traduction de requêtes logiques en requêtes physiques est un processus qui implique quelques étapes :
valider la requête par rapport au schéma
traduire les étiquettes en entités de schéma réelles (indices)
création de la requête physique Opensearch
C'est le processus d'une révision de haut niveau, en pratique : il y aura plus d'étapes qui optimiseront la requête logique ; dans certains cas, il est possible de créer plusieurs plans physiques (plans d'exécution) et de les classer selon une stratégie d'efficacité (coût) telle que le nombre d'éléments nécessaires à récupérer...
Nous avons commencé par discuter de l'objectif de la base de données de graphiques dans les cas d'utilisation commerciale actuels et avons examiné différents modèles de représentation d'un graphique. Comprendre les éléments logiques fondamentaux qui devraient constituer une base de données graphique potentielle et discuter d'un candidat NoSql existant pour répondre aux exigences de la couche de stockage.
Une fois que nous avons sélectionné Opensearch comme couche de stockage, nous avons pris le modèle graphique LDBC Social Network Benchmark et l'avons simplifié pour être optimisé dans ce stockage spécifique. Nous avons discuté du schéma de stockage réel avec les propriétés redondantes et examiné le langage de chiffrement pour interroger le stockage dans un langage de modèle graphique de type SQL.
Nous avons continué à voir la transformation réelle de la requête chiffrée en une requête d’exécution physique qui sera exécutée par Opensearch.
Dans la dernière section, nous avons pris une simple requête graphique et approfondi les détails des stratégies d'exécution et du mécanisme de regroupement.
Tutoriel d'installation :
Tutoriel de création de schéma :
Tutoriel de chargement de données :
Interroger le didacticiel Graph :
Tutoriel de matérialisation et de comptage de projection :
