Les bases de données graphiques sont un type particulier de base de données stockant des structures de données complexes qu’il serait impossible de stocker dans une base de données relationnelle traditionnelle. Ils sont notamment utilisés pour les réseaux sociaux, car ils sont beaucoup plus performants pour certaines requêtes.
Qu’est-ce qu’une base de données graphique ?
Les bases de données graphiques sont le plus souvent utilisées pour des données fortement interconnectées et pour des situations où le contenu des données elles-mêmes importe moins que la structure globale.
Le cas d’utilisation le plus simple des données graphiques est celui des réseaux sociaux. Considérez un réseau de personnes ; chaque personne a une liste d’amis et a des relations avec d’autres personnes. Chaque personne fait aussi des posts, souvent des centaines. Chaque publication pourrait avoir des milliers de personnes qui interagissent avec elle. Ainsi, bien que le tweet ne fasse que 280 caractères, il y a tellement plus à stocker à ce sujet.
Ce n’est certainement pas le seul cas d’utilisation, juste le plus digeste : les bases de données de graphes sont utilisées pour toutes sortes de choses. Un autre exemple est la détection des fraudes ; dites que vous êtes une banque et que vous souhaitez signaler les comptes suspects. Il peut être un peu louche que deux comptes distincts aient la même adresse ou partagent des numéros de téléphone. Avec une base de données graphique, vous pouvez créer un graphique de la connexion entre les deux comptes et identifier des problèmes comme celui-ci beaucoup plus efficacement qu’une base de données relationnelle ne le pourrait jamais.
Dans une base de données de graphes, chaque objet est appelé un nœud. Un nœud peut avoir n’importe quel nombre de propriétés, très similaires au fonctionnement d’une base de données de documents. Une base de données de documents stockerait simplement chaque nœud en tant que document distinct dans une collection (tableau) de documents, sans tenir compte de la manière dont ils se connectent.
Dans une base de données de graphes, les connexions entre les nœuds sont appelées bords, et ils peuvent connecter deux nœuds n’importe où dans la table. Les arêtes définissent les relations entre les nœuds et peuvent avoir des types spécifiques. Par exemple, deux amis seraient connectés avec un bord « Amis », mais un utilisateur serait connecté à un message avec un bord « Publié » ou « Aimé ».
Qu’est-ce qui les rend plus rapides ?
Ce n’est pas que les bases de données relationnelles comme MySQL ne peut pas stocker des structures de type graphique – des liens comme ceux-ci sont toujours des concepts de base pour les tables SQL. Les liens forment des connexions entre les tables, permettant aux données d’être stockées et mises à jour dans des tables séparées tout en maintenant un lien ailleurs dans la base de données, très similaire au fonctionnement des pointeurs en C. Dans l’exemple de réseau social, vous ne voudriez pas stocker le nom de chaque ami d’un utilisateur donné car cet ami peut changer son nom, donc vous stockez à la place l’ID de l’ami, puis effectuez une recherche chaque fois que vous avez besoin des bonnes données. Peut-être que vous cachez les résultats pour prendre une certaine charge de la base de données, mais la plupart des systèmes fonctionneront de la même manière.
Stocker un ensemble de liens (comme une liste d’amis) est bien, mais le problème survient lorsque vous commencez à effectuer tout type d’analyse complexe. L’exemple classique est la recherche d’amis d’amis. Pour obtenir une liste de tous ceux qui ont un ami commun avec la personne donnée, vous devez parcourir la liste d’amis de la personne donnée, puis parcourir la liste d’amis de chaque ami, puis effectuer une recherche pour chaque enregistrement. Vous devez également vous assurer que vous ne retournez pas d’enregistrements en double, ce qui constitue une boucle supplémentaire.
Si vous connaissez Grande notation O, vous pouvez déjà voir le problème ici. C’est un problème de complexité exponentielle ; faire plusieurs boucles imbriquées comme celle-ci casse l’ordinateur très rapidement. Ce n’est pas non plus une façon intelligente d’aborder ce problème.
Jetez un œil à ce benchmark de neo4j exécutant la requête friends-of-friends, par rapport à une base de données relationnelle traditionnelle (comme MySQL) :
À la profondeur 2, il s’agit d’une simple requête pour les deux bases de données. À la profondeur 3, MySQL devient incapable d’effectuer cette requête dans un délai normal, prenant 30 secondes pour renvoyer une réponse. À son honneur, il parvient à renvoyer la requête de profondeur 4 après 25 minutes, bien que la profondeur 5 plante la base de données.
La base de données de graphes n’a aucun problème à renvoyer l’une de ces requêtes, tous les temps d’exécution étant inférieurs à 2 secondes, ce qui la rend des milliers de fois plus rapide.
Comment fait-il cela ? Des maths très compliquées, surtout. Les graphiques sont une structure mathématique au cœur, et il y a beaucoup de théorie derrière cela, dont nous ne sommes absolument pas qualifiés pour discuter en détail. Mais les graphes relationnels sont assez simples à comprendre visuellement, ce qui facilite le travail avec les bases de données de graphes dans la pratique.
Si vous voulez commencer à travailler avec un, vous devrez choisir et installer une base de données de graphes. Neo4j est gratuit et open source, et une option très populaire. AWS a sa base de données Neptune, que vous pouvez essayer gratuitement, mais que vous devez héberger sur AWS. Certaines bases de données multi-modèles prennent en charge les graphiques en option, comme Serveur Microsoft SQL, Base de données Oracle, et ArangoDB.
Vous pouvez lire l’article original (en Angais) sur le blogwww.cloudsavvyit.com