私はArangoDB
のコア開発者の一人で、クエリを最適化しようとしました。私はあなたのdataset
を持っていないので、私は自分のテストdataset
についてしか話すことができませんし、私の結果を検証することができれば幸いです。
まず、すべて私がArangoDB
2.7を実行している場合ですが、この特定のケースでは、2.6と大きなパフォーマンスの違いはないと思います。
私のdataset
では、約7秒でクエリを実行できました。 最初の修正: 友人の声明ではincludeData: true
を使用し、_id
を返すだけです。 includeData: false
GRAPH_NEIGHBORS
と直接_id
を返し、我々はまた、ここに
LET friends = GRAPH_NEIGHBORS('graph',
@user,
{"direction": "any",
"edgeExamples": {
name: "FRIENDS_WITH"
}})
サブクエリを取り除くことができます。これは、私のマシン上〜1.1秒にそれをダウンしました。だから私はこれがNeo4Jのパフォーマンスに近いと思う。
これはなぜ大きな影響を与えますか? 内部的には、最初に文書JSONを実際にロードせずに_id
という値が見つかりました。クエリではこのデータは必要ありませんので、安全に開くことができます。
しかし、今の本当の改善のための
あなたのクエリは、「論理的」道を行くと、最初のユーザーの隣人を取得し、彼らの隣人を見つけるよりも、foaf
を発見し、それをソートされた頻度をカウントします。 これはメモリ内に完全なfoafネットワークを構築し、それを全体としてソートする必要があります。
あなたはまた、別の方法でそれを行うことができます。 1.各foaf
については、ユーザーのすべてのfriends
(のみ_ids
) 2.すべてfoaf
(完全な文書)を検索 3.すべてfoaf_friends
(のみ_ids
) を探します4. friends
とfoaf_friends
の交差点を検索し、それらを
このクエリは、この希望COUNT:
LET fids = GRAPH_NEIGHBORS("graph",
@user,
{
"direction":"any",
"edgeExamples": {
"name": "FRIENDS_WITH"
}
}
)
FOR foaf IN GRAPH_NEIGHBORS("graph",
@user,
{
"minDepth": 2,
"maxDepth": 2,
"direction": "any",
"includeData": true,
"edgeExamples": {
"name": "FRIENDS_WITH"
}
}
)
LET commonIds = GRAPH_NEIGHBORS("graph",
foaf._id, {
"direction": "any",
"edgeExamples": {
"name": "FRIENDS_WITH"
}
}
)
LET common_friend_count = LENGTH(INTERSECTION(fids, commonIds))
SORT common_friend_count DESC
RETURN {user: foaf, common_friend_count: common_friend_count}
を
私のテストグラフで〜0で実行されました。024秒
だからこれは私に率250速い実行時間を与え、私はこれはのNeo4jであなたの現在のクエリよりも高速であることを期待するが、私はあなたのdataset
私はそれを確認することはできませんていないので、それは次のようになりあなたがそれをして、私に教えてくれればよい。 edgeExamples: {name : "FRIENDS_WITH" } it is the same as with
includeData`で
最後に一つ
、このケースでは、私たちは本当のエッジを見つけ、それを検討する必要があります。これは、名前に基づいて別のコレクションにエッジを保存すると回避できます。また、edgeExamplesも削除します。これによりパフォーマンスがさらに向上します(特にエッジが多い場合)。私たちの次のリリースに合わせて調整
今後
滞在は、我々は今照会する方がはるかに簡単にあなたのケースを行いますし、別のパフォーマンスの向上を与える必要がありますAQLにいくつかのより多くの機能を追加しています。
ありがとうございます!私はあなたの答えを確認し、確認し、受け入れるでしょう。 ) –
私たちの場合、あなたの最初の改善は私たちのバージョンよりもはるかに速かったです。特に、最も遅いクエリは改善のメリットがあります。それは確かにNeo4jバージョンに非常に近いAQL結果をもたらしました。 2番目のクエリに関しては、最悪の場合のfoafクエリを高速化しましたが、最良のクエリは少し遅くなりました。(いずれにせよ、最初の改善が私たちを多く助けました)。 –