ArangoDB, czyli kiedy relacje są ważniejsze niż tabele
Utworzono: 18 maja 2021 Zaktualizowano: 1 października 2026
W jednym projekcie pierwszy raz użyłem grafowej bazy na produkcji, parę słów, po co i czy było warto.
Projekt dotyczy cyfrowego dziedzictwa kultury, zbieramy cyfrowe kopie obiektów z różnych instytucji, bibliotek, muzeów, archiwów, a każda ma swój format danych, więc sporo czasu zjadają same integracje. Główną bazą jest Postgres, wyszukiwanie idzie przez Elasticsearch i to się sprawdza, dopóki chodzi o pojedyncze obiekty.
Tylko że obiekty nie żyją osobno. Obraz ma autora, autor miał nauczyciela, obraz był na wystawie, wystawa była w jakimś mieście, a w tym mieście działała inna osoba, o której mamy list w archiwum. Chcieliśmy, żeby dało się po tych powiązaniach chodzić, a w tabelach wyszło z tego mnóstwo tabel łączących i rekurencyjne zapytania, których potem nikt nie chciał czytać.
ArangoDB trzyma dokumenty i graf w jednym miejscu, obiekt to po prostu dokument JSON, a powiązania to krawędzie między dokumentami. Zapytanie w stylu „pokaż wszystko, co jest najwyżej dwa kroki od tej osoby” wygląda mniej więcej tak:
FOR v, e, p IN 1..2 ANY 'persons/matejko' GRAPH 'heritage' FILTER v.type IN ['artwork', 'exhibition'] RETURN DISTINCT { title: v.title, via: p.edges[*].label }
Zamiast kilkunastu linii SQL z CTE jest kilka linii, które da się przeczytać.
Koszty
Druga baza to druga rzecz do utrzymania. Postgres jest źródłem prawdy, a graf budujemy z niego zadaniami w Celery, trzeba pilnować, żeby jedno z drugim się nie rozjechało, robić backupy obu, a nowe osoby w zespole muszą ogarnąć AQL.
Wybrałbym to jeszcze raz, bo tu powiązania są sednem produktu. Gdyby graf był tylko dodatkiem do zwykłej aplikacji, rekurencyjne zapytania w Postgresie w zupełności by wystarczyły.