Neo4j-Cypher対Gremlinクエリ言語

REST APIを使用してNeo4jで開発を始めています。複雑なクエリを実行するには、Cypher（Neo4jのクエリ言語）とGremlin（汎用グラフクエリ/トラバーサル言語）の2つのオプションがあることがわかりました。

これが私が知りたいことです-Gremlinを使用して実行でき、Cypherで実行できないクエリまたは操作はありますか？またはその逆？

Cypherは、グレムリンよりもはるかに明確に見えます。一般に、Neo4jの人たちはCypherを使用しているようです。しかし、CypherがGremlinと比較して制限されている場合、私は事前にそれを知りたいと思っています。

一般的なクエリでは、Cypherで十分であり、おそらくより高速です。Cypherに対するGremlinの利点は、高レベルのトラバースに入るときです。Gremlinでは、正確な走査パターン（または独自のアルゴリズム）をより適切に定義できますが、Cypherでは、エンジンが最適な走査ソリューション自体を見つけようとします。

私はCypherをそのシンプルさのために個人的に使用しています。これまで、Gremlinを使用しなければならない状況はありませんでした（Gremlin graphMLインポート/エクスポート関数での作業を除く）。ただし、グレムリンを使用する必要がある場合でも、ネット上で見つけた特定のクエリに対しては使用し、二度と戻ってこないことを期待しています。

常にサイファーを非常に速く（数日で）学習してから、（長期的に）一般的なグレムリンを続けることができます。

クエリでは何千ものノードをトラバースする必要があります。サイファーは遅かった。Neo4jチームは、Java APIに対して直接アルゴリズムを実装すると、100〜200倍高速になると語っています。そうすることで、簡単に60の因数を得ることができました。現時点では、自信がないため、システムに単一のCypherクエリはありません。簡単なCypherクエリはJavaで簡単に記述でき、複雑なクエリは実行されません。問題は、クエリに複数の条件がある場合、Cypherでトラバーサルを実行する順序を指示する方法がないことです。したがって、最初にサイファークエリが間違った方向でグラフに乱入する可能性があります。私はGremlinで多くのことをしたことはありませんが、Gremlinではるかに多くの実行制御を取得できると想像できます。

Nepher4jチームのCypherへの取り組みは実に印象的であり、長い道のりを歩んできました。Neoチームは通常、人々をそれに向けて推進し、Cypherが成熟するにつれて、Gremlinはおそらくあまり注目されなくなります。サイファーは、長期的な選択として適しています。

つまり、GremlinはGroovy DSLです。Neo4j RESTエンドポイントを介してそれを使用すると、基礎となるNeo4j Java APIへの完全で自由なアクセスが可能になります。それ（および同じカテゴリの他のスクリプトプラグイン）は、低レベルのパワーに関しては一致できません。さらに、Gremlinプラグイン内からCypherを実行できます。

どちらの方法でも、両方を学ぶための正しいアップグレードパスがあります。私はあなたをより早く動かし、走らせるものを選びます。で、私の プロジェクトで、私は通常、グレムリンを使用して、私は両方がグレムリンDSLの痛みですmatching-表形式の結果や、表現のパターンを必要とするときに（グレムリン内から、またはしない）サイファーを呼び出します。

私は最初にグレムリンを使い始めました。しかし、当時はRESTインターフェースが少し不安定だったので、Cypherに切り替えました。Neo4jのサポートが大幅に向上しています。ただし、Cypherでは不可能であるクエリの種類や、CypherがGremlinで実行できる方法を最適化できないクエリもあります。

GremlinはGroovy上に構築されているため、実際にそれを一般的な方法として使用して、Neo4jで「Java」コードを実行し、サーバーからさまざまなタスクを実行できます。RESTインターフェースからHTTPヒットを取得する必要はありません。とりわけ、Gremlinではデータを変更できます。

ただし、データのクエリだけが必要な場合は、Cypherを使用します。これは、Cypherの方が読みやすく、保守が容易だからです。グレムリンは、制限に達したときのフォールバックです。

Gremlinクエリはプログラムで生成できます。（http://docs.sqlalchemy.org/en/rel_0_7/core/tutorial.html#intro-to-generative-selectsを参照して、私が何を意味しているのかを確認してください。）これは、Cypherの場合は少しトリッキーなようです。

Cypherは単純なクエリに対してのみ機能します。複雑なビジネスロジックをグラフのトラバーサルに組み込み始めると、法外に遅くなるか、まったく機能しなくなります。

Neo4Jは、Cypherがそれを切断していないことを明確に認識しています。これは、Cypherが代替パスエクスパンダ（apoc.path.expand、apoc.path.subgraphAllなど）。

グレムリンは学ぶのが難しいですが、CypherやAPOCよりも強力です。Gremlinで考えられるあらゆるロジックを実装できます。

Neo4Jに切り替え可能なGremlinサーバーが同梱されていることを本当に望みます（周囲の資料から、これは以前はそうでした）。ライブのNeo4Jインスタンスに対してGremlinを実行することはできますが、多くのフープをジャンプする必要があります。私の希望は、Neo4Jの競合他社がGremlinをオプションとして許可しているため、Neo4Jがそれに続くことです。

Cypherは、グラフデータベースをクエリするための宣言型クエリ言語です。宣言型という用語は、命令型のようなプログラミングパラダイムとは異なるプログラミング方法であるため、重要です。CypherやSQLなどの宣言型クエリ言語では、取得するデータを基になるエンジンに通知し、データの取得方法は指定しません。Cypherでユーザーは、MATCH句で対象のサブグラフを定義します。次に、基礎となるエンジンはパターンマッチングアルゴリズムを実行して、グラフデータベース内のサブグラフの類似の発生を検索します。グレムリンは宣言型と命令型の両方の機能です。これは、ユーザーがグラフのナビゲート方法を明示的に指示する必要があるグラフトラバーサル言語です。この場合のこれらの言語の違いは、CypherではKleeneスター演算子を使用して、グラフデータベース内の任意の2つのノード間のパスを検索できることです。ただし、グレムリンでは、そのようなすべてのパスを明示的に定義する必要があります。しかし、グレムリンの繰り返し演算子を使用して、グラフデータベースでそのような明示的なパスの複数の発生を見つけることができます。ただし、Cypherでは、明示的な構造に対して反復を行うことはできません。

長い答えは短い：クエリにはサイファーを使用し、トラバーサルにはグレムリンを使用します。自分で応答タイミングがわかります。

グレムリンを使用する場合は、別のグラフデータベースに移行できます。ほとんどのグラフデータベースはグレムリントラバーサルをサポートしているため、グレムリンを選択することをお勧めします。