Apache AGE

Wideo i „powiązane filmy” wyglądają na prosty temat, ale w praktyce potrafią zabić bazę. Na papierze to tylko pytanie: „pokaż mi podobne filmy”. W realu dochodzą tagi, ten sam kanał, wspólne oglądanie, ścieżki przez kilka skoków i nagle zwykły SQL zaczyna mielić ogromne ilości danych. Przy większym ruchu takie zapytania robią się drogie, wolne i męczą replikę odczytu.

Problem polega na tym, że to nie są zwykłe tabelki, tylko graf. Film ma powiązania z innymi filmami, kanałami i zachowaniami użytkowników. W relacyjnej bazie trzeba to składać przez self-joiny i rekurencję, a przy kilku krokach robi się z tego bałagan. To działa na małych danych, ale przy większej skali szybko zaczyna boleć.

Tu właśnie pomaga Apache AGE. Zamiast udawać, że graf to zwykłe tabele, trzymasz dane w modelu grafowym, a PostgreSQL dalej robi za bazę pod spodem. Dzięki temu nie musisz stawiać osobnego silnika tylko po to, żeby obsłużyć relacje między filmami. Masz jeden system, a zapytania o ścieżki i sąsiedztwo są dużo prostsze i zwykle szybsze.

W praktyce wygląda to tak: węzły to np. filmy i kanały, a krawędzie to relacje typu „wrzucony przez”, „ma wspólny tag” albo „oglądany po”. Wtedy pytanie o podobne filmy nie wymaga już kombinowania z wieloma złączeniami. Zamiast tego opisujesz wzorzec i silnik sam ogarnia przejście po grafie. To jest po prostu lepszy model dla takiego problemu.

Duży plus jest też operacyjny. Nie musisz utrzymywać osobnej bazy grafowej, osobnych backupów i osobnych procedur. Zostajesz przy PostgreSQL, tylko dokładzasz warstwę grafową. To upraszcza życie, szczególnie jeśli już masz backend oparty o Postgresa i nie chcesz robić kolejnej technologicznej wyspy.

Najważniejsze jednak jest to, że takie zapytania da się potem sensownie optymalizować. Indeksy na właściwościach wejściowych, dobre modelowanie krawędzi i sensowny kierunek relacji robią dużą różnicę. W efekcie zamiast ciężkich, wielolinijkowych zapytań SQL masz krótszą logikę, łatwiejszą do utrzymania i lepiej pasującą do problemu.