すでにグラフデータベースを使用している場合、ElasticSearchを使用するのはなぜですか？

ElasticSearchとグラフデータベースの比較について、Webで詳細な説明を見つけることはできません。

どちらもデータを横断するように最適化されています。
ElasticSearchは分析用に最適化されているようです。
ただし、Neo4jは、インデックスと一部のフルテキスト機能を管理するLuceneにも基づいています。

すでにグラフデータベースを使用しているのにElasticSearchを使用するのはなぜですか？

私の場合、Neo4jを使用してソーシャルネットワークを構築しています。
ElasticSearchがもたらす本当のメリットは何ですか？

更新----------

私はこの段落を見つけました：

elasticsearchが役立つ無数のケースがあります。いくつかのユースケースは、他のユースケースよりも明確にそれを要求します。次に、elasticsearchが特に適しているタスクをいくつか示します。

• 特定のフレーズ（「シェフのナイフ」など）に最も一致する製品説明を多数検索して、最良の結果を返す
• 前の例では、「シェフのナイフ」が表示されるさまざまな部門を分類します（この本の後半のファセットを参照）
• 「季節」のように聞こえる単語をテキストで検索する
• スペルミスを考慮しながら、以前に発行された検索に基づいて部分的に入力された単語に基づいて検索ボックスを自動補完する
• 大量の半構造化（JSON）データを分散方式で保管し、マシンのクラスター全体に指定されたレベルの冗長性を持たせる

ただし、elasticsearchは前述の問題を解決するのに優れていますが、他の人には最適な選択ではないことに注意してください。リレーショナルデータベースが最適化されている問題の解決は特に苦手です。以下にリストされているような問題。

• 在庫に残っているアイテムの数を計算する
• 特定の月に送信されたすべての請求書のすべての明細の合計を計算する
• ロールバックサポートを使用してトランザクションで2つの操作を実行する
• 電話番号や内線番号など、指定された複数の用語にわたって一意であることが保証されているレコードを作成する
• Elasticsearchは一般に、品質による結果のスコアリングなど、データからおおよその回答を提供するのに優れています。elasticsearchは正確なマッチングと統計計算を実行できますが、検索の主なタスクは本質的におおよそのタスクです。
• おおよその回答を見つけることは、elasticsearchと従来のデータベースを分離するプロパティです。そうは言っても、従来のリレーショナルデータベースは精度とデータの整合性に優れているため、elasticsearchとLuceneにはほとんど規定がありません。

おおよその回答が必要ない場合、ElasticSearchは既に使用されているグラフデータベースと比較して役に立たないと断言できますか？

ElasticSearchをデータベースと呼ぶのをためらいます。これはデータベースに代わるものではありませんが、既存のデータベースに加えて、機能、特に高度なテキスト検索を追加するのに適しています。

どこで混乱させられるかわかります。実際には同じニーズを満たすことができますが、常にそうではありません。ElasticSearchは、検索とまったく同じように処理します。グラフデータベースは、ElasticSearchが行うように、リレーションまたはインデックスを指定しません。したがって、根本的にはまったく異なる動作をします。ElasticSearch は、たとえば英語のアナライザーを使用してドキュメントを分析します。これが何をするかは、単語を取り、その単語のさまざまなバリエーションまたは同義語を分析します。たとえばdig、はとして解析されdig,digs,dug,digging,digger ...ます。elasticsearchでクエリを実行すると、クエリも分析でき、それらの単語がクエリされ、関連性によってスコアリングできます。

ElasticSearchは非常に柔軟であるため、優れたツールです。幅広い相対的なコンテンツを見つけることができます。また、干し草のスタックで針を見つけることもできますが、それは比較的簡単です。

グラフデータベースにも利点があります。例えばハッシュタグのようなもの、または多くの変更可能な関係を持つものの間の関連性/関係を見つける。それらは素晴らしいテクノロジーの興味深い部分ですが、ElasticSearchほど強力ではないと言わざるを得ません。その主な理由は、ElasticSearchがこの種のことを対象としており、全文検索を実行できるように分析を処理するためです。ただし、事前に定義されたタグ付け/キーワードに基づいたツイッターの検索のようなシステムを使用する場合は、すでに使用しているグラフデータベースを使用することをお勧めします。

問題は、検索をどの程度堅牢にするかです。非常にきめの細かい（全文）検索を行う必要がある場合は、elasticsearchを使用します。それ以外の場合は、グラフデータベースで常に比較的簡単に検索を実装できます。後でより堅牢な検索エンジンが必要になった場合、検索を実装してElasticsearchに移行することは不可能ではありませんが、それを念頭に置いて検索を実装してください。

これらのデータベースは両方とも、特定のレベルのアプリケーション要件で特定の問題を解決するという特定のニーズを持っています。グラフデータベースは使用していませんが。しかし、過去5年間のプロジェクトの1つで、MySQLでelasticsearchを使用しています。このプロジェクトには、600万件のドキュメントで検索される膨大なデータがあり、それらのエンティティ間に膨大な関係があります（1,000万件の関係ドキュメント）。

ユースケース： 友人が気に入ったホテルを検索し、すべてのホテルをいいねの数で並べ替えます。そして、あなたがそれをよく見るならば。このケースには2つの関係（Friend、Like）が関係しています。だから私はホテルと私の友人の間のいいね関係船を検索する必要があり、それからホテルは彼らが持っているいいねの総数でソートされるべきです。そのため、このような検索には、グラフデータベースが適しています。

Elasticsearchはドキュメント内の完全なテスト検索で素晴らしい仕事をしていますが、上記のような関係を検索することに関してはそれほど良くありません。私のファンであるドキュメント（エンティティ）をリストし、ファンの数で並べ替えます。しかし、これらは1つのレベルの深さであり、より深く検索することになります。Elasticsearchは十分ではありません。

したがって、アプリケーションの要件を理解してから、データベースを探してください。両方が必要になる場合があります。