Postgres als Graph-DB verwenden: pgRouting missbrauchen – Nutzung oder Overuse?

• pgRouting ist eine Erweiterung für Postgres und wird hauptsächlich in geografischen Informationssystemen (GIS) verwendet, um den kürzesten Weg zwischen zwei Punkten zu finden
• Allerdings kann pgRouting nicht nur Geodaten, sondern auch viele andere Arten graphstrukturierter Daten verarbeiten
• Es kann als leichtgewichtige Alternative zu spezialisierten Graph-Datenbanken wie Apache AGE oder Neo4j dienen

Einführung in pgRouting

• pgRouting ist eine Erweiterung von PostGIS und bietet Geospatial-Routing-Funktionen
• Damit lassen sich kürzeste Wege berechnen, Netzwerkanalysen durchführen und komplexe Routing-Probleme lösen
• Es wird vor allem im GIS-Bereich eingesetzt, etwa um den kürzesten Weg zwischen zwei Orten zu finden

Verbindung zu Graphen

• Die Stärke von pgRouting liegt darin, dass es mit allen Daten arbeiten kann, die als Graph strukturiert sind
• Ein Graph besteht aus einem Netzwerk miteinander verbundener Punkte, wobei:
  • Knoten Entitäten darstellen
  • Kanten Beziehungen oder Wege zwischen Knoten darstellen
• In Karten oder GIS stehen Knoten und Kanten jeweils für Kreuzungen und Straßen, das Konzept lässt sich aber ebenso auf abstrakte Systeme wie soziale Netzwerke anwenden

Einsatzfälle für pgRouting außerhalb von GIS

• Aufgabenplanung

  • In Projekten bestehen Abhängigkeiten zwischen Aufgaben, die einen gerichteten azyklischen Graphen (DAG) bilden
    • Knoten stehen für Aufgaben
    • Kanten stehen für Abhängigkeiten
  • Eine der zentralen Herausforderungen im Projektmanagement ist das Finden des „kritischen Pfads“, der die Gesamtdauer des Projekts bestimmt
  • Mit pgRouting lassen sich Aufgabenabhängigkeiten modellieren und über Graph-Algorithmen kritische Pfade ermitteln

• Reverse-Proxy-Routing auf Basis von Ressourcenallokation

  • In verteilten Systemen ist eine effiziente Zuweisung von Ressourcen zwischen den Knoten im Netzwerk wichtig
  • Jeder Knoten kann einen physischen Standort oder einen Computing-Prozess darstellen, und Kanten repräsentieren Wege, auf denen Daten zwischen Knoten bewegt werden
  • In einer Cloud-Infrastruktur kann pgRouting beispielsweise genutzt werden, um Daten oder Compute-Workloads zwischen verteilten Servern über den effizientesten Pfad zu routen

• Empfehlungs-Engines wie YouTube

  • In Empfehlungs-Engines oder Suchalgorithmen, die Wissensgraphen verwenden, kann pgRouting genutzt werden, um Beziehungen zwischen Entitäten und Ereignissen aufzubauen
  • Im Empfehlungssystem von YouTube zum Beispiel gilt:
    • Knoten repräsentieren Entitäten wie Nutzer, Videos oder Kategorien
    • Kanten repräsentieren Beziehungen wie Nutzer-Video-Interaktionen oder gemeinsam genutzte Kategorien zwischen Videos
  • Solche Graphstrukturen können genutzt werden, um personalisierte Empfehlungen für Nutzer bereitzustellen

Weitere Informationen zu pgRouting

• pgRouting ist eine leistungsstarke Erweiterung für Postgres, die zur Lösung verschiedenster graphbasierter Probleme eingesetzt werden kann
• Weitere Details finden sich in der offiziellen pgRouting-Dokumentation

[curiosityprocessor]

Hat jemand apache age oder pgRouting tatsächlich eingeführt?
Wir führen im Unternehmen gerade eine Graph-Datenbank ein, nutzen aber bereits Postgres als bestehende RDB.
Mit Plugins/Extensions kann man Postgres zwar „gewissermaßen wie eine Graph-Datenbank“ verwenden, aber man hört, dass die Performance in der Praxis nicht ausreicht, daher haben wir über neo4j nachgedacht – wobei die Meinungen auf Hacker News offenbar ebenfalls ziemlich unzufrieden mit neo4j sind.

[GN⁺]

Hacker-News-Kommentare

• Vor fünf Jahren war ich von Graph-Datenbanken und -Bibliotheken enttäuscht und wollte mehrere Nicht-Graph-DBMS hinter einer Python-Schnittstelle platzieren, ähnlich wie bei NetworkX

  • Neo4J scheiterte bei allen Graphen, und SQLite sowie Postgres waren für Netzwerkverarbeitungsaufgaben besser geeignete Optionen
  • Ich frage mich, ob es sich lohnt, das Projekt angesichts der besseren Postgres-Kompatibilität aufzufrischen
  • Mehr Graph-DBs wie MemGraph sind mit CYPHER kompatibel und könnten besser funktionieren als Neo4J
  • Das Ziel war herauszufinden, ob pgrouting ein gutes Werkzeug ist, um eine Memory-Layer für AI/Agenten aufzubauen
  • Die ersten Ergebnisse sind vielversprechend, und ich werde bald mit einem weiteren Artikel nachlegen
  • Es gibt interessante Erweiterungen wie onesparse, das auf SuiteSparse basiert

• Supabase liefert weiterhin großartige Inhalte rund um PostGIS

  • Darunter Themen wie das direkte Bereitstellen von Tiles oder das (missbräuchliche) Nutzen von Features im geografischen Kontext von PG
  • Nicht innovativ oder komplex, aber unterhaltsam und geistig anregend
  • Lob dafür, häufig Inhalte zu veröffentlichen, die das Interesse an der Arbeit mit Datenbanken wecken

• Ich habe mich immer gefragt, warum es kein "SQLite für Graphen" gibt

  • Ich frage mich, ob es eine Art Speicherlayout gibt, das eine In-Process-Lösung mit festplattenbasierter Speicherung behindert

• Ich arbeite an einem einfachen Postgres-Graph-DB-Projekt

  • Abfragen und Tabellenstruktur sind für dieselbe Aufgabe deutlich einfacher

• Ich würde gern Meinungen dazu hören, Adjazenzmatrizen darzustellen, indem man roaring bitmaps in einer bytea-Postgres-Spalte speichert

  • Da RDS plrust und das SPI von PostgreSQL unterstützt, scheint sich das mit croaring-rs umsetzen zu lassen
  • Man könnte viele Graphen darstellen, wobei jeder Graph einem Tenant zugewiesen ist (Unternehmen/B2B-SaaS-Anwendungsfall)
  • Mit plrust könnte man roaring bitmaps in bytea auf dem DB-Server speichern und per SPI den Netzwerk-Overhead minimieren
  • PostgreSQL bietet Transaktionssicherheit und unterstützt außerdem andere spaltenbasierte Daten wie JSONB zum Abfragen von Tenant-ID-Spalten und Beziehungsmetadaten
  • Es müssen viele Tenant-Graphen unterstützt werden, und da ich bereits citus verwende, scheint das auch im großen Maßstab machbar zu sein
  • Vermutlich müsste ich einige Operator-Klassen erstellen, um Beziehungen besser zu indexieren
  • Ich kenne pg_roaringbitmap, bevorzuge aber int64 und würde gern mit RDS starten
  • Ich nutze PostgreSQL intensiv statt Neo4J (u. a. bei Tabellen mit über 20 TB)
  • Großer Dank an den Autor des Blogposts
  • Es sieht so aus, als könnte man pgRouting als Graph-DB verwenden, daher setze ich es auf meine Testliste

• Ich frage mich, ob jemand eine Meinung zu "Apache AGE" hat

  • Apache AGE™ ist PostgreSQL mit Graph-Datenbank-Funktionalität

• Ich frage mich, ob es allein anhand des Datenmodells (also nicht der Abfragesprache) tatsächlich einen Unterschied zwischen "Graph-"Datenbanken und "normalen SQL"-Datenbanken gibt

• Ich frage mich, ob jemand Erfahrung mit der Erstellung von Isochronen mit PgRouting hat

  • Es gibt einen Anwendungsfall für Isochronen-Karten zum Gehen, Radfahren usw.
  • Wenn möglich, würde ich gern nur Postgres verwenden und andere Infrastruktur wie Valhalla, OpenTripPlanner oder OpenRouteService vermeiden

• Postgres bietet immer Erweiterungen, die neue Möglichkeiten für die Datenmodellierung eröffnen

  • Ich frage mich, wie es sich im Vergleich zu den Graph-Funktionen von CedarDB (Postgres-kompatibel) schlägt