SQL selhává při 3+ skokech. GraphDB ne. Představte si, že najdete všechny účty do 3 skoků od podezřelé transace. Nebo propojování fragmentovaných zákaznických záznamů mezi systémy pomocí sdílených e-mailů a telefonních čísel. Jedná se o dotazy pro procházení grafů. SQL zvládne vztahy, ale ne hloubku. Jistě, můžete psát rekurzivní CTE a samo-spojování. To funguje na 1-2 skoky. Ale když půjdeme hlouběji, stanou se dvě věci: - Dotaz se stává nečitelným - A výkonnostní nádrže Každý skok přidává další self-join. Na skoku 5-6 se díváte na dotazy, které běží několik minut a pod zátěží se rozpadávají. Stejný dotaz v Cypher: MATCH (t:Transaction {id: 'TXN-001'})-[:ZAHRN*1.. 3]-(a:Účet) VRAŤTE ODLIŠNÉ a.name, a.phone 3 řádky. Zní to jako otázka, kterou pokládáš. Škáluje do jakékoli hloubky. Na to jsou grafové databáze stavěné. FalkorDB je jedna z věcí, o kterých stojí za to znát. Je to open-source. A používá odlišný architektonický přístup než většina grafových databází. Většina grafových databází během procházení sleduje ukazatele z uzlu na uzel. FalkorDB to nedělá. Je postaven na GraphBLAS, lineárním algebraickém rámci, který reprezentuje grafové operace jako výpočty řídkých matic. Každý hop se místo toho stává optimalizovanou maticovou operací. Výsledek: - Lepší chování cache - Paralelní výpočty napříč skoky...