Utiliser Postgres comme base de données graphe : ab(user) de PgRouting — usage ou abus ?

• pgRouting est une extension de Postgres, principalement utilisée dans les systèmes d'information géographique (GIS) pour trouver le plus court chemin entre deux points
• Cependant, pgRouting peut aussi être utilisé pour traiter divers types de données structurées en graphe au-delà des données géospatiales
• Il peut servir d'alternative légère à des bases de données graphe spécialisées comme Apache AGE ou Neo4j

Présentation de pgRouting

• pgRouting est une extension de PostGIS qui fournit des fonctionnalités de routage géospatial
• Il permet de calculer des plus courts chemins, d'effectuer des analyses de réseau et de résoudre des problèmes de routage complexes
• Il est surtout utilisé dans le GIS, par exemple pour trouver le plus court chemin entre deux emplacements

Lien avec les graphes

• L'un des points forts de pgRouting est qu'il peut fonctionner avec n'importe quelles données structurées sous forme de graphe
• Un graphe est constitué d'un réseau de points interconnectés, où :
  • les nœuds représentent des entités
  • les arêtes représentent les relations ou chemins entre les nœuds
• Sur une carte ou dans un GIS, les nœuds et les arêtes correspondent respectivement aux intersections et aux routes, mais ce modèle peut aussi s'appliquer à des systèmes abstraits comme les réseaux sociaux

Cas d'usage de pgRouting en dehors du GIS

• Planification des tâches

  • Dans un projet, il existe des dépendances entre les tâches, ce qui forme un graphe orienté acyclique (DAG)
    • les nœuds représentent les tâches
    • les arêtes représentent les dépendances
  • L'un des principaux enjeux en gestion de projet consiste à trouver le « chemin critique » qui détermine la durée totale du projet
  • On peut utiliser pgRouting pour modéliser les dépendances entre tâches et trouver le chemin critique à l'aide d'algorithmes de graphe

• Routage de reverse proxy basé sur l'allocation de ressources

  • Dans les systèmes distribués, il est important d'allouer efficacement les ressources entre les nœuds du réseau
  • Chaque nœud représente un emplacement physique ou un processus de calcul, et les arêtes représentent les chemins de circulation des données entre les nœuds
  • Par exemple, dans une infrastructure cloud, pgRouting peut être utilisé pour acheminer les données ou les tâches de calcul entre des serveurs distribués via le chemin le plus efficace

• Moteurs de recommandation comme YouTube

  • Dans les moteurs de recommandation ou les algorithmes de recherche utilisant des graphes de connaissances, pgRouting peut servir à construire les relations entre entités et événements
  • Par exemple, dans l'algorithme de recommandation de YouTube :
    • les nœuds représentent des entités comme les utilisateurs, les vidéos ou les catégories
    • les arêtes représentent des relations comme les interactions entre utilisateurs et vidéos, ou le partage de catégories entre vidéos
  • Cette structure en graphe permet de fournir des recommandations personnalisées aux utilisateurs

Informations complémentaires sur pgRouting

• pgRouting est une extension puissante de Postgres qui peut être utilisée pour résoudre divers problèmes fondés sur des graphes
• Pour en savoir plus, consultez la documentation officielle de pgRouting

[curiosityprocessor]

Quelqu’un a-t-il déjà mis en production apache age ou pgRouting ?
L’entreprise est en train d’introduire une base de données graphe, et nous utilisons déjà Postgres comme SGBDR existant.
Les plugins/extensions permettent d’utiliser Postgres « comme si c’était une base graphe », mais on nous dit qu’en pratique les performances ne sont pas au rendez-vous, donc nous envisagions plutôt Neo4j ; pourtant, à voir les avis sur Hacker News, il semble aussi y avoir beaucoup d’insatisfaction envers Neo4j.

[GN⁺]

Commentaires Hacker News

• Il y a cinq ans, j’avais été déçu par les bases de données et bibliothèques Graph, et j’avais essayé de placer plusieurs DBMS non orientés graphe derrière une interface Python similaire à NetworkX

  • Neo4J plantait sur tous les graphes, tandis que SQLite et Postgres étaient de meilleures options pour les tâches de traitement de réseaux
  • Avec l’amélioration de la compatibilité Postgres, je me demande si le projet mérite d’être relancé
  • Davantage de bases de données Graph comme MemGraph sont compatibles avec CYPHER et pourraient mieux fonctionner que Neo4J
  • L’objectif était de voir si pgrouting était un bon outil pour construire une couche mémoire pour l’IA/les agents
  • Les premiers résultats sont prometteurs, et je prévois de faire un suivi prochainement dans un autre article
  • Il existe des extensions intéressantes comme onesparse, basé sur SuiteSparse

• Supabase continue de proposer d’excellents contenus autour de PostGIS

  • Il y a des sujets liés au fait de servir directement des tuiles ou de (sur)utiliser des fonctionnalités dans un contexte géographique PG
  • Ce n’est ni révolutionnaire ni complexe, mais c’est amusant et intellectuellement stimulant
  • J’apprécie qu’ils publient souvent des contenus qui donnent envie de travailler avec des bases de données

• Je me suis toujours demandé pourquoi il n’existait pas de « SQLite pour les graphes »

  • Je me demande s’il existe un mode de stockage qui empêche une solution in-process avec stockage sur disque

• Je travaille sur un projet simple de base de données Graph sous Postgres

  • Les requêtes et la structure des tables sont bien plus simples pour le même travail

• J’aimerais avoir des avis sur l’idée de stocker des bitmaps roaring dans une colonne bytea Postgres pour représenter une matrice d’adjacence

  • Comme RDS prend en charge plrust et le SPI de PostgreSQL, il semble possible de construire cela avec croaring-rs
  • Cela pourrait représenter de nombreux graphes, chacun attribué à un tenant (cas d’usage entreprise / SaaS B2B)
  • En utilisant plrust, on pourrait stocker des bitmaps roaring dans le bytea du serveur DB et utiliser le SPI pour minimiser la surcharge réseau
  • PostgreSQL offre la sécurité transactionnelle, ainsi que la prise en charge d’autres données orientées colonnes comme du JSONB pour interroger la colonne d’ID de tenant et les métadonnées des relations
  • Il faut prendre en charge de nombreux graphes de tenants, et comme j’utilise déjà citus, cela semble aussi faisable à grande échelle
  • Il faudra probablement créer certaines classes d’opérateurs pour mieux indexer les relations
  • Je connais pg_roaringbitmap, mais il utilise int64 et je préfère partir de RDS
  • J’utilise déjà PostgreSQL en profondeur sans passer par Neo4J (travail sur des tables de plus de ~20 To, etc.)
  • Un grand merci à l’auteur du billet de blog
  • Il semble possible d’utiliser pgRouting comme base de données Graph, donc je l’ajoute à ma liste de tests

• Je me demande si quelqu’un a un avis sur « Apache AGE »

  • Apache AGE™ est PostgreSQL avec des fonctionnalités de base de données Graph

• Je me demande s’il existe une réelle différence entre une base de données « graphe » et une base de données « SQL classique » si l’on considère uniquement le modèle de données (et non le langage de requête, par exemple)

• Je me demande si quelqu’un a de l’expérience avec la génération d’isochrones à l’aide de PgRouting

  • Il y a un cas d’usage pour générer des cartes isochrones pour la marche, le vélo, etc.
  • Si possible, j’aimerais n’utiliser que Postgres et éviter d’autres infrastructures comme Valhalla, OpenTripPlanner et OpenRouteService

• Postgres propose toujours des extensions qui ouvrent de nouvelles possibilités de modélisation des données

  • Je me demande comment cela se compare aux fonctionnalités de graphe de CedarDB (compatible Postgres)