SQL scheitert bei 3+ Hops. GraphDBs nicht. Stell dir vor, du findest alle Konten innerhalb von 3 Hops einer verdächtigen Transaktion. Oder du verknüpfst fragmentierte Kundenaufzeichnungen über Systeme hinweg durch gemeinsame E-Mails und Telefonnummern. Das sind Graph Traversal-Abfragen. SQL kann Beziehungen handhaben, aber nicht die Tiefe. Klar, du kannst rekursive CTEs und Selbstverknüpfungen schreiben. Das funktioniert bei 1-2 Hops. Aber geh tiefer und zwei Dinge passieren: - Die Abfrage wird unleserlich - Und die Leistung sinkt Jeder Hop fügt eine weitere Selbstverknüpfung hinzu. Bei Hop 5-6 siehst du dir Abfragen an, die Minuten laufen und unter Last zusammenbrechen. Die gleiche Abfrage in Cypher: 𝗠𝗔𝗧𝗖𝗛 (𝘁:𝗧𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 {𝗶𝗱: '𝗧𝗫𝗡-𝟬𝟬𝟭'})-[:𝗜𝗡𝗩𝗢𝗟𝗩𝗘𝗦*𝟭..𝟯]-(𝗮:𝗔𝗰𝗰𝗼𝘂𝗻𝘁) 𝗥𝗘𝗧𝗨𝗥𝗡 𝗗𝗜𝗦𝗧𝗜𝗡𝗖𝗧 𝗮.𝗻𝗮𝗺𝗲, 𝗮.𝗽𝗵𝗼𝗻𝗲 3 Zeilen. Liest sich wie die Frage, die du stellst. Skaliert in jede Tiefe. Dafür sind Graphdatenbanken gebaut. FalkorDB ist eine, die es wert ist, darüber Bescheid zu wissen. Es ist Open Source. Und es verfolgt einen anderen architektonischen Ansatz im Vergleich zu den meisten Graph-DBs. Die meisten Graphdatenbanken verfolgen Zeiger von Knoten zu Knoten während der Traversierung. FalkorDB macht das nicht. Es basiert auf GraphBLAS, einem Framework für lineare Algebra, das Graphoperationen als spärliche Matrixberechnungen darstellt. Jeder Hop wird stattdessen zu einer optimierten Matrixoperation. Das Ergebnis: - Besseres Cache-Verhalten - Parallele Berechnung über Hops...