3

このことから、グラフ データベースは、複数テーブルの結合と同等の処理をはるかに高速に実行できます。次に、テーブルのサイズに関係なく、同等の結合は同じ速度です。

depth   seconds records
2         0.016 ~2,500 --mysql
3        30.267 ~125,000
4     1,543.505 ~600,000

2         0.010 ~2,500 --neo4j
3         0.168 ~110,000
4         1.359 ~600,000

SQL では、文字通りテーブルのサイズとホップ数を乗算するデカルト結合を使用していることを知っています。そして、グラフデータベースについて私が耳にするのは「ファーストクラスの関係構造」だけです。

ホップ数やテーブルサイズに関係なく、グラフ データベースを高速にトラバーサルするデータ構造 + アルゴリズムとは?

どうすれば RDBMS システムに実装できますか? 左結合とネストされたクエリを考えています。

4

2 に答える 2

1

グラフ内のすべてのノードがその隣接ノードをカウントし、そのカウントを結果に追加するため、グラフ トラバーサルは一般に結合よりも高速です。これは、マルチスレッドなどで簡単に最適化できます。

SQL でこれを行うことはできないと思いますが、(再帰的な) コードを実行することはできます。これにより、多くのクエリが発生し、パフォーマンスが低下する可能性があります。

したがって、本当にグラフ データを操作する場合は、グラフ データベースを使用する必要があります。

于 2012-08-09T08:28:25.213 に答える
0

まず、単純なクエリについて話していると仮定して、ON等価条件のみを含む句 (例: a JOIN b ON a.id = b.id) と結合します。これらは、グラフ トラバーサルによって習得される種類のクエリだと思います。

ジョインはバイナリ検索を使用してジョインのON句を満たすペアを見つけるため、速度が低下しますが、グラフ トラバーサルではこれらの検索が完全に回避されます。グラフ データベースのエッジは、接続するノードのメモリ アドレスをリンク (格納) します。同様に、ノードはそのエッジのメモリ アドレスを格納します。ノード 1 に接続されているノードを見つけたいですか? ノード 1 のすべてのエッジ (メモリ内/ディスク上) に移動し、各エッジについて、他のノード (メモリ内/ディスク上) に移動します。出来上がり!(免責事項:これについてはよくわかりません。ソースコードは見ていませんが、非常に強い予感があります)。

ハッシュ インデックスの等値検索は O(1) (二分探索の O(log n) ではなく) であるため、ハッシュ インデックスを使用して RDBMS でのグラフ トラバーサルの速度をエミュレートするというアイデアがありました。うまくいけば、いくつかのテスト結果とともにこの投稿に戻ることができます。

于 2013-10-10T08:22:50.773 に答える