SQLは3+ホップで失敗します。GraphDBにはそうではありません。 疑わしい取引から3ホップ以内のすべてのアカウントを見つけられると想像してみてください。また、分散した顧客記録を共有メールや電話番号でシステム間でリンクさせることも可能です。 これらはグラフのトラバーサルクエリです。SQLは関係性は扱えますが、深みは扱えません。 もちろん、再帰的なCTEや自己結合を書くことは可能です。1〜2ホップで動作します。しかし、もっと深く考えると、二つのことが起こります。 - クエリが読み取れなくなる - そしてパフォーマンスタンク 各ホップごとに自己結合が加わります。ホップ5〜6の時点で、クエリは数分間実行され、負荷で崩壊してしまうことになります。 Cypherでも同じ質問があります: MATCH (t:トランザクション {id: 'TXN-001'})-[:INVOLVES*1..3]-(a:Account) 返信する不明瞭な a.name、電話 3行。あなたが尋ねている質問に似ています。どんな深さにもスケールできる。 これがグラフデータベースの目的です。 FalkorDBは知っておく価値のあるツールです。オープンソースです。そして、ほとんどのグラフDBとは異なるアーキテクチャアプローチを採用しています。 ほとんどのグラフデータベースは、トランバーサル中にノードからノードへポインタを追跡します。FalkorDBはそういった対応をしていません。これはグラフ演算を疎行列計算として表現する線形代数フレームワークであるGraphBLASに基づいて構築されています。各ホップは最適化された行列操作となります。 その結果: - キャッシュ挙動の改善 - ホップを越えた並列計算...