Baza grafowa (ang. graph database) to baza danych, w której najważniejsze są nie same dane, tylko powiązania między nimi. Informacje trzymasz w postaci węzłów (ang. nodes — np. osoba, produkt, konto) oraz relacji (ang. edges — np. „zna”, „kupił”, „przelał do”). Relacja jest tu pełnoprawnym obywatelem: ma swój typ, kierunek i może mieć własne właściwości, np. datę zawarcia znajomości. To zupełnie inne podejście niż w klasycznej bazie relacyjnej, gdzie powiązania symulujesz tabelami pośrednimi i sklejasz je w locie zapytaniami.
Jak to działa i do czego pasuje
Najważniejsza różnica jest praktyczna: w bazie grafowej relacje są zapisane bezpośrednio, więc skok z węzła do sąsiada to po prostu pójście po wskaźniku, a nie kosztowny JOIN liczony na milionach wierszy. Dzięki temu pytania typu „znajdź znajomych moich znajomych do 4 poziomu w głąb” są szybkie nawet wtedy, gdy w SQL zamieniłyby się w korowód zagnieżdżonych złączeń, który muli z każdym kolejnym poziomem.
Baza grafowa świeci więc tam, gdzie sednem problemu są połączenia: sieci społecznościowe, systemy rekomendacji („kupili też…”), wykrywanie fraudów (podejrzane łańcuchy przelewów), grafy wiedzy, zależności w infrastrukturze IT czy trasowanie. Jeśli rysujesz coś na tablicy w postaci kółek i strzałek, to model grafowy prawdopodobnie odwzoruje to jeden do jednego.
Przykład z praktyki
Najpopularniejszym przedstawicielem jest Neo4j, który używa języka zapytań Cypher (od kwietnia 2024 ustandaryzowanego jako otwarty openCypher / nowy standard ISO GQL). Wzorzec relacji zapisujesz w nim wizualnie — strzałką ASCII. Chcesz polecić użytkownikowi filmy lubiane przez osoby o podobnym guście?
MATCH (ja:User {name:'Anna'})-[:LIKES]->(:Movie)<-[:LIKES]-(inny:User)-[:LIKES]->(rekomendacja:Movie) RETURN rekomendacja.title
W SQL to samo to kilka złączeń tabeli pośredniej samej ze sobą. Tu czytasz to jak zdanie. Z innych silników spotkasz Amazon Neptune, ArangoDB czy JanusGraph.
Na co uważać
Najczęstszy mit: „baza grafowa jest szybsza od SQL”. Nie — jest szybsza do problemów grafowych. Do raportów agregujących miliony wierszy, sum i prostych odczytów po kluczu klasyczny RDBMS albo kolumnowa hurtownia rozłożą ją na łopatki. Drugi błąd to wciskanie grafu wszędzie „bo modny”: jeśli twoje dane to płaskie tabele bez głębokich powiązań, dokładasz tylko nową technologię do utrzymania. Pamiętaj też, że skalowanie poziome grafu (sharding) jest trudniejsze niż w bazach, gdzie rekordy są niezależne — przecięcie ostrym nożem sieci powiązań zwykle boli.
Pojęcia powiązane: NoSQL, baza relacyjna, model danych, Cypher, GQL, indeks, query language, knowledge graph.