SQL nie radzi sobie przy 3+ skokach. GraphDBs tak. Wyobraź sobie znalezienie wszystkich kont w odległości 3 skoków od podejrzanej transakcji. Lub łączenie fragmentarycznych rekordów klientów w różnych systemach za pomocą wspólnych e-maili i numerów telefonów. To są zapytania do przeszukiwania grafów. SQL może obsługiwać relacje, ale nie głębokość. Oczywiście, możesz napisać rekurencyjne CTE i self-joins. To działa przy 1-2 skokach. Ale gdy idziesz głębiej, dzieją się dwie rzeczy: - Zapytanie staje się nieczytelne - A wydajność spada Każdy skok dodaje kolejny self-join. Przy 5-6 skokach masz do czynienia z zapytaniami, które działają przez minuty i rozpadają się pod obciążeniem. To samo zapytanie w Cypher: 𝗠𝗔𝗧𝗖𝗛 (𝘁:𝗧𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 {𝗶𝗱: '𝗧𝗫𝗡-𝟬𝟬𝟭'})-[:𝗜𝗡𝗩𝗢𝗟𝗩𝗘𝗦*𝟭..𝟯]-(𝗮:𝗔𝗰𝗰𝗼𝘂𝗻𝘁) 𝗥𝗘𝗧𝗨𝗥𝗡 𝗗𝗜𝗦𝗧𝗜𝗡𝗖𝗧 𝗮.𝗻𝗮𝗺𝗲, 𝗮.𝗽𝗵𝗼𝗻𝗲 3 linie. Czyta się jak pytanie, które zadajesz. Skaluje się do dowolnej głębokości. To jest to, do czego zostały stworzone bazy danych grafowych. FalkorDB to jedna z tych, o których warto wiedzieć. Jest open-source. I przyjmuje inne podejście architektoniczne w porównaniu do większości baz danych grafowych. Większość baz danych grafowych śledzi wskaźniki od węzła do węzła podczas przeszukiwania. FalkorDB tego nie robi. Jest zbudowany na GraphBLAS, frameworku algebry liniowej, który reprezentuje operacje grafowe jako obliczenia macierzy rzadkich. Każdy skok staje się zoptymalizowaną operacją macierzową. Rezultat: - Lepsze zachowanie pamięci podręcznej - Równoległe obliczenia w skokach...