Cet article comprend les points de contenu suivants :
· Principales classifications techniques des bases de données
· Qu'est-ce qu'un graphique ?
· Modèle graphique
· Base de données graphique versus base de données relationnelle
· Base de données graphique versus comparaison avec d'autres NOSQL
· Toutes les bases de données graphiques ne sont pas identiques !
Selon les prévisions de Gartner, « d’ici 2025, la proportion d’innovations en matière de données et d’analyses utilisant la technologie des graphes passera de 10 % en 2021 à 80 %, ce qui favorisera grandement une prise de décision rapide par les entreprises. »
L'image ci-dessus est une classification simple par l'auteur des principales pistes techniques de la base de données. Vous pouvez également la combiner avec mon article précédent [Ying Figure | Un article pour comprendre quelles sont les étapes du développement de la base de données ? - Zhihu (zhihu.com) ] Regardons ensemble. Il n'est pas difficile de constater que, au cours des plus de 50 années d'histoire du développement de la technologie des bases de données, de sa vitalité vigoureuse et des défis posés par les nouvelles bases de données aux bases de données traditionnelles, les facteurs déterminants sont principalement le besoin urgent d'une base de données nouvelle et efficace. Dans l'industrie et le monde universitaire, une architecture flexible et de grande dimension émerge pour répondre à la croissance rapide du volume de données (Volume), à la diversité des types de données (Volume), à l'augmentation rapide de la vitesse de génération des données (Volume) et à l'attention des gens sur le valeur des données (Volume) ——On peut donc comprendre pourquoi GQL est devenu le seul standard international après SQL depuis 1983. Cela illustre aussi fortement l'influence et l'importance de la technologie des bases de données graphiques sur l'avenir.
Tableau 1 : Analyse de 5 catégories de produits de bases de données grand public
| Classification |
performance |
Évolutivité |
la flexibilité |
Complexité |
| Base de données de stockage de valeurs clés |
haut |
haut |
haut |
aucun |
| base de données documentaire |
haut |
variable |
haut |
Faible |
| Base de données du magasin de colonnes |
haut |
variable |
en général |
Faible |
| base de données de graphiques |
variable |
haut |
haut |
haut |
| Base de données relationnelle |
variable |
variable |
Faible |
en général |
Graph Database est une base de données NoSQL implémentée sur la base de la théorie des graphes. Elle peut stocker des informations sur les attributs des entités et des informations sur les relations entre les entités. Elle présente une modélisation simple, de fortes performances, des fonctions de recherche riches et une forte évolutivité.
Un graphe est composé de sommets et d'arêtes reliant chaque paire de sommets :
Point (nœud) : Il est appelé sommet (Vertex) ou point (nœud), et peut également être appelé entité (Entity).
Bord : Une arête reliant deux points (nœud). On l'appelle aussi souvent une relation (relation, relation) dans la catégorie des graphe de connaissances.
Par exemple, lorsque vous étudiez la relation entre Léonard de Vinci et le Louvre, vous pouvez établir une corrélation entre un diagramme très simple entre les personnes et les objets : la « théorie des six degrés de séparation » est issue de ce diagramme.
Un autre exemple est le métro, un outil de déplacement que nous utilisons presque tous les jours dans notre vie quotidienne. Si une station est considérée comme un « point » et que deux stations adjacentes sont reliées par des « bords », cela peut également être connecté dans un « graphique » typique.
Nous pouvons nous étendre à l'infini avec notre propre pensée, et en connectant des nœuds avec des nœuds, nous pouvons directement construire des attributs et des relations dans le monde réel grâce à des données graphiques à portée de main [Pour en savoir plus, voir la bibliothèque | Qu'est-ce qu'un graphique ? 】.
Il existe trois types de modes graphiques, à savoir le graphique d'attributs, l'hypergraphe et le triplet, car les données graphiques doivent être stockées dans une base de données graphique spécifique avant de pouvoir être finalement implémentées dans un fichier de données spécifique, et ce processus implique naturellement quelle méthode de mise en œuvre est utilisée pour enregistrer les données graphiques. Prenons Ultipa Graph comme exemple. Comme Nejo4, il s'agit d'un graphe de propriétés (Property Graphs) - le modèle de graphe de propriétés est plus facile à comprendre et peut décrire la plupart des scénarios d'utilisation de graphiques.
Pourquoi les avantages des bases de données graphiques deviennent-ils de plus en plus importants ? Par exemple, dans les bases de données relationnelles traditionnelles, une fois que des requêtes de corrélation multi-tables sont impliquées, la quantité de calcul augmente proportionnellement au produit cartésien de la quantité de données dans la table. Plus la quantité de données est grande, plus il y a de corrélations de table, plus plus complexe et plus l’efficacité est faible. Parce qu'il recherche les enregistrements de clé primaire correspondants dans la table principale via des clés étrangères pour effectuer des opérations de recherche et de calcul de correspondance. Si une relation plusieurs-à-plusieurs est utilisée, une table intermédiaire doit être ajoutée pour enregistrer la correspondance de clé étrangère entre les deux participants. tables.
La base de données graphique est très flexible. Non seulement elle peut montrer succinctement la relation entre les données du tissu à travers des points et des bords, mais la logique de calcul utilisée est le mode de calcul (requête) d'association de voisin le plus proche, qui a une faible complexité de calcul et une efficacité exponentiellement améliorée. Voir photo ci-dessous.
Par exemple, si vous utilisez une base de données relationnelle et une base de données graphique pour effectuer une pénétration profonde, des couches 2 à 5, la différence de performances augmente en fait de façon exponentielle. Par exemple, lors de la pénétration de la couche 1, il peut n'y avoir aucune différence essentielle entre les deux. À partir de la couche 2, il y aura des changements exponentiels (plus de 10 fois). Il ne peut plus renvoyer aucun résultat, c'est-à-dire qu'il a dépassé la capacité de calcul de la machine et s'est arrêté. (Les lecteurs intéressés peuvent lire en détail : La différence entre les bases de données graphiques et les bases de données relationnelles⁴ ).
À en juger par la part de marché actuelle des principaux types de bases de données, les bases de données relationnelles restent dominantes, mais cela s'inscrit dans le contexte d'un passé où il y avait un manque d'alternatives. Avec de plus en plus de scénarios où elles ne peuvent pas tenir, les bases de données graphiques sont son les avantages génétiques naturels deviendront une arme pour dépasser dans les virages.
Tableau 2 : Comparaison des bases de données graphiques traditionnelles
| Nejo4j |
JanusGraph |
Graphique Ultipa |
|
| Réputation |
Le plus élevé |
haut |
en général |
| Écosystème open source |
La version communautaire est open source, mais comporte plus de restrictions ; la version commerciale est fermée : |
Open source ; compatible avec l'écosystème Apache Tinkerpop, services cloud principalement fournis par AWS et IBM |
Les services cloud à source fermée sont principalement fournis par Ultipa Cloud |
| langage de requête graphique |
Zéro |
Diablotin |
UQL |
| Prise en charge de l'échelle des données |
La version communautaire est évaluée à un milliard de niveaux ; la version entreprise est évaluée à plus de 100 milliards de niveaux. |
Niveau dix milliards ou plus |
Niveau supérieur à 100 milliards |
| Performances d'écriture de données à grande échelle |
L'importation en ligne est lente |
Ralentissez |
Importation en ligne rapide |
| Performances des requêtes de données à grande échelle |
Rapide et plus stable |
plus rapide |
Rapide et super stable |
| Perfection fonctionnelle |
Complet |
Complet |
Complet |
| Outil d'importation de données |
Prise en charge de l'importation en ligne CSV ; prise en charge des formats riches |
Aucun support fourni |
Ultipa Transporter prend en charge l'exécution sur toutes les plates-formes, prend en charge une variété de formats et fournit des capacités d'importation de données pour des fichiers tels que les capacités d'exportation TSV, CSV, Mysql, BigQuery et CSV. |
| Interface visuelle |
Prise en charge, fonctions riches, prise en charge de la modélisation visuelle des données, de l'importation, de l'analyse, etc. |
Non pris en charge, l'utilisateur doit intégrer une interface tierce |
Prise en charge, riche en fonctions, prise en charge de la conversion 2D et 3D ; prise en charge de la modélisation, de l'importation, de l'analyse de données visuelles, etc. |
| Algorithmes graphiques intégrés couramment utilisés |
Fournit un package d'algorithmes d'installation, fournissant une multitude d'algorithmes graphiques de base |
pas de support |
Il fournit des packages d'algorithmes d'installation et dispose d'une riche bibliothèque d'algorithmes, qui peut être fournie aux utilisateurs sous la forme de packages d'algorithmes indépendants. |
| Fonctions de base (ajouter, supprimer, vérifier et modifier les graphiques d'attributs, planifier la maintenance, les métadonnées, les transactions, la mise en cache, l'optimisation des requêtes, la mise à jour incrémentielle des graphiques, etc.) |
soutien |
soutien |
soutien |
| Transactions ACIDE |
soutien |
Partiellement pris en charge, en fonction du stockage back-end. |
soutien |
| contraintes de schéma |
Prise en charge de la version commerciale, prend également en charge Schema-Free |
Pris en charge, et prend également en charge Schema-Free |
Pris en charge, et prend également en charge Schema-Free |
| Type de stockage graphique |
Prise en charge du stockage local, prise en charge du stockage distribué, prise en charge du stockage géré dans le cloud |
Pilotez le stockage local, prenez en charge le stockage distribué |
|
| partition graphique |
soutien |
soutien |
soutien |
| HA haute disponibilité |
Prise en charge de la version professionnelle |
Aucun support fourni |
soutien |
Comme nous le savons d'après ce qui précède, la raison pour laquelle les bases de données NoSQL sont devenues populaires est qu'elles peuvent résoudre les défis de la plupart des types de données, des collections de données à grande échelle, etc., mais quelles sont les différences entre elles (parlez simplement de clé-valeur paires et documents) Qu’en est-il de la comparaison ?
Le stockage de documents est une structure hiérarchique et les données peuvent être facilement stockées sous forme d'arborescence. Cependant, de ce fait, il ne peut exprimer qu'une relation subordonnée de haut en bas, et la forme de l'arbre n'est que l'une d'entre elles dans les bases de données graphiques. les performances sont plus riches. De plus, la structure de stockage arborescente intégrera des données redondantes à plusieurs reprises, ce qui augmentera la difficulté de mise à jour des données et ne parviendra pas à garantir la cohérence des données.
La base de données clé-valeur est plus adaptée aux applications avec une petite quantité de relations de données, car elle est organisée, indexée et stockée sous forme de paires clé-valeur. Lorsque la quantité de données est petite, elle peut réduire efficacement le nombre de lectures. et écrit sur le disque et a des performances élevées.Mais au contraire, une fois que la quantité de données est importante, le graphique évident peut mieux exprimer la relation complexe entre les données.
Enfin, il est important de noter que toutes les bases de données graphiques ne se valent pas ! Certaines bases de données graphiques n'ont que des capacités de stockage mais manquent de capacités de calcul, tandis que d'autres peuvent effectuer des calculs, mais sont très inefficaces en matière de migration de données. Il existe également des bases de données de graphes implémentées à l'aide d'architectures NoSQL ou MapReduce, mais elles n'ont pas optimisé complètement et en profondeur les caractéristiques du calcul graphique. L'effet final est que plus la distribution est horizontale, plus l'efficacité est faible. Certains fabricants déplacent aveuglément toutes les données dans la mémoire, ce qui entraîne une augmentation soudaine de l'utilisation de la mémoire, ce qui crée également le problème négatif d'un MOO fréquent et entraîne des temps d'arrêt. Le chemin d'implémentation correct est "distribution + intégration du stockage et du calcul + optimisation du stockage multi-niveaux + optimisation de la profondeur des requêtes graphiques". Les bases de données graphiques comportent de nombreux points de connaissances et défis, sur la façon de concevoir et de mettre en œuvre un graphique distribué vraiment hautes performances. Base de données, les lecteurs intéressés peuvent se référer à Comment implémenter un système de base de données graphique à haute concurrence ? ³. [Texte/Nezha Emma]