すでにグラフデータベースを使用しているのに、なぜElasticSearchを使用するのですか？
ElasticSearch とグラフデータベースの比較について、Webで深い説明はありません。
どちらもデータをトラバースするように最適化されています。
ElasticSearchは分析用に最適化されているようです。
ただし、Neo4jはLuceneにも基づいており、インデックスと一部のフルテキスト機能を管理しています。
すでにグラフデータベースを使用しているのに、なぜElasticSearchを使用するのですか？
私の場合、私は Neo4j を使用してソーシャルネットワークを構築しています。
ElasticSearchがもたらす実際のメリットは何ですか？
UPDATE ----------
私はこの段落を見つけました：
Elasticsearchが役立つケースは無数にあります。一部のユースケースでは、他のケースよりも明確にそれを要求します。以下に、elasticsearchが特に適しているいくつかのタスクを示します。
- 多数の製品の説明から特定のフレーズ（「シェフのナイフ」など）に最も一致するものを検索し、最良の結果を返す
- 前の例の場合、「シェフのナイフ」が表示されるさまざまな部門を分解します（この本の後半のファセットを参照）
- 「季節」のように聞こえる単語をテキストで検索する
- スペルミスを考慮しながら、以前に発行された検索に基づいて部分的に入力された単語に基づいて検索ボックスを自動補完する
- マシンのクラスター全体で指定されたレベルの冗長性を使用して、大量の半構造化（JSON）データを分散方式で格納します。
ただし、elasticsearchは前述の問題の解決には優れていますが、他の人にとって最良の選択ではないことに注意してください。特に、リレーショナルデータベースが最適化されている問題を解決するのは得意ではありません。以下のような問題。
- 在庫に残っているアイテムの数を計算する
- 特定の月に送信されたすべての請求書のすべての品目の合計を計算する
- ロールバックサポートを使用して2つの操作をトランザクションで実行する
- 電話番号や内線番号など、指定された複数の用語で一意であることが保証されているレコードを作成する
- Elasticsearchは一般に、品質による結果のスコアリングなど、データからのおおよその回答を提供するのに優れています。 elasticsearchは正確なマッチングと統計計算を実行できますが、その検索の主なタスクは本質的に近似的なタスクです。
- おおよその答えを見つけることは、elasticsearchを従来のデータベースから分離するプロパティです。そうは言っても、従来のリレーショナルデータベースは、elasticsearchとLuceneがほとんど備えていない精度とデータ整合性に優れています。
おおよその回答が必要ない場合、ElasticSearchはすでに使用されているグラフデータベースと比較して役に立たないと主張できますか？
ElasticSearchをデータベースと呼ぶのをためらっています。これはデータベースの代わりではありませんが、既存のデータベースに加えて、特に高度なテキスト検索などの機能を追加するのに適しています。
あなたが彼らを混乱させることができる場所がわかります。彼らは実際には同じニーズに対応できますが、常にそうとは限りません。 ElasticSearchは正確にsearchesのように動作します。グラフデータベースは、ElasticSearchとは異なり、関係やインデックスを指定しません。したがって、基本的には動作がまったく異なります。 ElasticSearch analyzesたとえば、英語のアナライザーを備えたドキュメント。これで何ができるかは、単語を取り、その単語のさまざまなバリエーションまたは同義語さえ分析します。たとえば、DigはDig,digs,dug,digging,digger ...として分析されます。 elasticsearchでクエリを実行すると、クエリも分析でき、それらの単語がクエリされ、関連性によってscoredになります。
ElasticSearchは非常に柔軟であるため、優れたツールです。さまざまな関連コンテンツを見つけることができます。または干し草の山から針を見つけることもでき、比較的簡単です。
グラフデータベースにも利点があります。たとえば、ハッシュタグなどの関連性や関係、または多くの変更可能な関係を持つものを見つける。これらは素晴らしい技術であり、興味深い技術ですが、ElasticSearchほど強力ではないと言っておく必要があります。主にElasticSearchがこの種のものに向けられており、フルテキスト検索を実行できるように分析を処理するためです。ただし、事前定義されたタグ付け/キーワードに基づくTwitterの検索などのシステムをもっと使用したい場合は、すでに使用しているグラフデータベースを使用したほうがよいでしょう。
問題は、検索をどれだけ堅牢にしたいかです。本当にきめ細かい検索（全文検索）が必要な場合は、elasticsearchを使用します。それ以外の場合は、グラフデータベースで常に比較的簡単に検索を実装できます。検索を実装したら、後でより強力な検索エンジンが必要になった場合にelasticsearchに移行することは不可能ではありません。それを念頭に置いて検索を実装してください。
これらのデータベースはどちらも、特定のレベルのアプリケーション要件で特定の問題を解決するという特定のニーズがあります。グラフデータベースは使用していませんが。しかし、過去5年間のプロジェクトの1つで、MySQLでelasticsearchを使用しています。そのプロジェクトには、600万のドキュメントで検索される膨大なデータがあり、それらのエンティティ間には膨大な関係があります（1000万の関係ドキュメント）。
ユースケース：友達から高く評価されたホテルを「いいね！」で検索し、すべてのホテルを好きな数で並べ替えます。そして、それをよく見れば。このケースには2つの関係（Friend、Like）が関係しています。そのため、ホテルとマイフレンドの間のLike関係の船を検索する必要があります。その後、ホテルは、Likeの合計数でソートする必要があります。したがって、このような検索には、グラフデータベースが適しています。
Elasticsearchは、ドキュメントの完全なテスト検索で優れた機能を果たしていますが、上記のような関係を検索する場合、それはそれほど良くありません。私のファンであるドキュメント（エンティティ）をリストし、ファンの数で並べ替えます。しかし、これらは1レベルの深さであり、より深く検索することになるとElasticsearchは十分ではありません。
アプリケーションの要件を理解してから、データベースに進んでください。両方が必要になる場合があります。