サイファークエリでのリレーションシップタイプの数が多い

Question

Neo4jでユーザー認可/データ保護スキームのプロトタイプを作成していますが、私のクエリで奇妙な問題が発生しました。バックグラウンドでは、aからbeへのアクセスを試みるユーザーは、正しいアクセスIDを持つことができます。したがって、私たちのエッジは、アクセス識別子を持つタイプのものです。私は多くのノードを作成し、それらのペアを異なるアクセスで接続することによってこのスキームをテストしています。つまり、私は多くのセットを持っています：

(a)-[:ACCESS_A]->(b) 

アクセスが異なる。

エッジの試合でリストのサイズは、ユーザーが持つアクセスの数と共に増加

{some query} with a match (a)-[:ACCESS_A|:ACCESS_B|<...>|:ACCESS_Z]->(b) return b 

：私は彼らのために問い合わせます。

このリストは201件のアクセス権が得られるまで素晴らしいものです。この時点で、プロファイルはdbヒットと時間が経過するまでの時間を示します。 200のリレーションシップタイプでは、プロファイルに1051 dbヒットが表示されますが、201のリレーションシップタイプでは31801が表示されます。これはもう1つのタイプで30倍の増加です！取られる時間も同様に増加する。 199から200に増えるのは約50ヒットだけです。これはノードのヒット数の増加によるものです。

多くの作業の後、ラウンド200番号が問題よりも赤いニシンのように見えます。以前は、私の関係タイプは4文字でした。私はそれらを9文字に変更したとき（テストとして「EDGE_」を付けていた）、問題は、50のタイプで発生し始めました - 50が36のアクセスを持ち、51が291で、より小さなジャンプですが、テスト。

クエリがどこに落ちるかという関係名と関係があるようですが、まだ調査中です。私がテストされ、関心のあることがわかっていませんでした

もの：全体的なクエリ（文字列サイズ）の

• 長：それは
4と9文字の関係タイプと全く異なるクエリサイズで失敗します
• [e：< ...>]句（文字列サイズ）のリストの長さ。上記のように、それはあなたが唯一の200関係タイプとパフォーマンスの問題に実行しているべきではありません、私の知る限りでは、グラフには非常に異なるサイズで

Answer 1

をノードまたはエッジの

数を失敗しました。

バージョン3.0以前では、リレーションシップタイプの数は64kで上限に達しました。その制限はバージョン3.0で削除されました。

Answer 2

私の問題の解決策を発見できました。 Neo4jに多くの異なる関係タイプが存在するかどうかを尋ねると、問題が発生するようです。私はそれらのタイプがすべて存在するときに200以上のものを使用することができました。したがって、解決策は、グラフにないタイプを尋ねないようにすることです。