このNeo4jとRDBMS実行時間の比較は正しいですか？

背景：以下は、本 『Neo4j in Action』で言及されているパフォーマンステストをカバーする本「Graph Databases」からの抜粋です。

グラフの関係は自然にパスを形成します。グラフのクエリまたはトラバースには、次のパスが含まれます。データモデルには基本的にパス指向の性質があるため、パスベースのグラフデータベース操作の大部分は、データのレイアウト方法と高度に連携しており、非常に効率的です。彼らの著書「Neo4j in Action」では、PartnerとVukoticがリレーショナルストアとNeo4jを使用して実験を行っています。

比較は、グラフデータベースがリレーショナルストアよりも接続されたデータの方が大幅に高速であることを示しています。パートナーとVukoticの実験では、最大5つの深さまで、ソーシャルネットワークで友達の友達を見つけようとしています。ランダムに選択された2人の人物がいる場合、それらを結ぶパスは最大で5つの関係です 表2-1に示すように、それぞれが約50人の友達がいる1,000,000人のソーシャルネットワークの場合、結果はグラフデータベースが接続されたデータに最適であることを強く示唆しています。

表2-1。リレーショナルデータベースでの拡張友達の検索とNeo4jでの効率的な検索の比較

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

深さ2（友人同士）では、リレーショナルデータベースとグラフデータベースの両方が十分に機能し、オンラインシステムでの使用を検討できます。Neo4jクエリはリレーショナルクエリの3分の2の時間で実行されますが、エンドユーザーは2つのクエリのミリ秒単位の違いにほとんど気付かないでしょう。ただし、深さ3（友達同士）に到達するまでに、リレーショナルデータベースが適切な時間枠でクエリを処理できなくなっていることは明らかです。完了するまでにかかる30秒は完全に許容できません。オンラインシステムの場合。これとは対照的に、Neo4jの応答時間は比較的フラットなままです。クエリを実行するのに必要な時間はほんの一瞬で、オンラインシステムに十分高速です。

深さ4では、リレーショナルデータベースはレイテンシが損なわれ、オンラインシステムでは実質的に役に立たなくなります。Neo4jのタイミングも少し低下しましたが、ここでの待ち時間は、応答性の高いオンラインシステムで許容できる範囲にあります。最後に、深さ5では、リレーショナルデータベースはクエリを完了するのに時間がかかりすぎます。対照的に、Neo4jは約2秒で結果を返します。深さ5では、ネットワーク全体が私たちの友人です。多くの実際の使用例では、結果とタイミングを整える可能性があります。

質問は：

• これは、ソーシャルネットワークで見つける以外に何をエミュレートするための合理的なテストですか？（実際のソーシャルネットワークには通常、たとえば約50人の友達がいるノードがあることを意味します。「リッチゲットリッチ」モデルはソーシャルネットワークにとってより自然なようですが、間違っている可能性があります。）
• エミュレーションの自然さに関わらず、結果がずれている、または再現できないと考える理由はありますか？

Anatomy of Facebookと呼ばれるこのドキュメントを見て、中央値が100であることを確認します。累積関数のプロットを見ると、平均が200近くと高いことに疑いはありません。したがって、ここでは50は最適な数ではないようです。しかし、これはここでは主な問題ではないと思います。

主な問題は、データベースの使用方法に関する情報の欠如です。

グラフ構造用に特別に設計されたデータストレージが従来のRDBMよりも効率的であることは合理的であると思われます。ただし、RDBMが選択したデータストレージとして最新の傾向にない場合でも、これらのシステムは、データセットのディメンションとの競争で継続的に進化しました。考えられる設計にはさまざまなタイプがあり、データにインデックスを付けるさまざまな方法、並行性に関連する改善などがあります。

結論として、再現性に関しては、データベーススキーマがどのように設計されたかについての適切な説明が研究に欠けていると思います。データベースがこのような尋問の王を支配することは期待していませんが、十分に調整された設計では、それほど大きな違いはないと予想します。

RDBMSでグラフをモデル化するための良い/速い方法と、愚か/遅い方法があります。

• 一部のユーザーは、賢いインデックス作成とストアドプロシージャを使用して、RAMのディスクでCPUの負荷と調整された一時テーブルを交換し、グラフの検索速度を上げています。

• 一部は事前計算されたグラフパスを使用します（これはソーシャルネットワークシナリオでは実現可能性が低いかもしれませんが、ノードの大部分がリーフノードであるツリーでは、時間とスペースのかなり良いトレードオフです

• いくつかは、調整されていないインデックス付き一時テーブルを使用して、ループで単純に計算します。記事で投げられた＃から、それは彼らがしたように臭いがします（30秒-かなり小さいデータセットでのパフォーマンス）

  たとえば、私は自分でツリーを計算しています。

  • 高度に調整されたストアドプロシージャにカプセル化されています

  • エンタープライズサイズのハードウェアSybase ASE15データサーバーで実行されている間、そのサーバーは他のすべてのエンタープライズアプリからの数テラバイトのデータと共有されます。クエリの実行だけに専念しているわけではありません。

  • 私はなかったではない主な高速化ツール、RAMディスク上の一時テーブルへのアクセス権を持っています。

  • 私が取得したデータの一部と一致すると思われる代表的なデータセットは、2.5Mノードの完全なフォレストデータセットから150,000ノードのサブツリーを取得していました（ツリーの深さは無制限で、5から15の間で変化しますが、特定のノードの平均アリティは小さくなります）実験にリストされている50人の友人）

  • このクエリが30〜45秒になるように調整しました。質問の数値がRDBMSのパフォーマンスを示しているように見える、指数関数的なスローダウンはほとんどありません。これは、結果セットに指数関数的な増加がないことを考えると、特に2倍奇妙です（これは、個人的な経験からの一時テーブル）。

したがって、この比較はおそらく誤りであり、不十分なRDBMSサイドデザインに基づいていますが、前の回答で述べたように、コードとテーブル定義の100％をソースなしでソースなしで確認することは不可能です。