SQL eșuează la 3+ hopuri. GraphDB-urile nu. Imaginează-ți că găsești toate conturile la mai puțin de 3 hopuri de o tranzacție suspectă. Sau legarea evidențelor fragmentate ale clienților între sisteme prin emailuri și numere de telefon partajate. Acestea sunt interogări de traversare a grafurilor. SQL poate gestiona relații, dar nu și profunzime. Sigur, poți scrie CTE-uri recursive și self-join-uri. Asta funcționează la 1-2 sărituri. Dar dacă mergi mai adânc, se întâmplă două lucruri: - Interogarea devine ilizibilă - Și rezervoarele de performanță Fiecare hop adaugă o nouă uniune proprie. La săritura 5-6, vezi interogări care rulează minute întregi și se destramă sub sarcină. Aceeași interogare în Cypher: MATCH (t:Transaction {id: 'TXN-001'})-[:IMPLICĂ*1.. 3]-(a:Cont) RETURNEAZĂ a.name DISTINCT, un telefon 3 rânduri. Se citește ca întrebarea pe care o pui. Solzi la orice adâncime. Pentru asta sunt construite bazele de date cu grafuri. FalkorDB este unul care merită cunoscut. Este open-source. Și abordează arhitectura diferit față de majoritatea bazelor de date cu grafuri. Majoritatea bazelor de date de grafuri urmăresc pointerii de la un nod la altul în timpul traversării. FalkorDB nu face asta. Este construit pe GraphBLAS, un cadru de algebră liniară care reprezintă operațiile de graf ca calcule de matrice rară. Fiecare salt devine o operație matrice optimizată. Rezultatul: - Comportament mai bun al cache-ului - Calcul paralel pe hops...