如果已经使用图形数据库，为什么还要使用ElasticSearch？

对于ElasticSearch和图数据库之间的比较，我在网络上找不到任何深入的解释。

两者均经过优化以遍历数据。
ElasticSearch似乎已针对分析进行了优化。
但是Neo4j也基于Lucene来管理索引和一些全文功能。

如果已经使用图形数据库，为什么还要使用ElasticSearch？

就我而言，我正在使用Neo4j建立社交网络。
ElasticSearch可以带来什么真正的好处？

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

我刚刚找到了这一段：

在无数情况下，elasticsearch是有用的。一些用例比其他用例更明确地要求它。下面列出了一些特别适合Elasticsearch的任务。

• 在大量产品说明中搜索特定词组（例如“厨师的刀”）的最佳匹配，并返回最佳结果
• 以前面的示例为例，分解出现“厨师的刀”的各个部门（请参阅本书后面的分面）
• 在文本中搜索听起来像“季节”的单词
• 在考虑到拼写错误的情况下，根据先前发布的搜索结果，根据部分键入的单词自动完成搜索框
• 以分布式方式存储大量的半结构化（JSON）数据，并在整个计算机集群中具有指定级别的冗余

但是，应该注意的是，尽管Elasticsearch在解决上述问题方面很出色，但对于其他人来说并不是最佳选择。解决关系数据库已优化的问题尤其困难。问题如下。

• 计算库存中剩余多少物品
• 计算给定月份发出的所有发票上所有行项目的总和
• 通过回滚支持以事务方式执行两个操作
• 创建保证在多个给定条件下唯一的记录，例如电话号码和分机号
• Elasticsearch通常非常擅长提供数据的近似答案，例如按质量对结果进行评分。虽然Elasticsearch可以执行精确的匹配和统计计算，但其主要搜索任务是固有的近似任务。
• 查找近似答案是一种将Elasticsearch与更多传统数据库区分开的属性。话虽这么说，传统的关系数据库在精度和数据完整性方面都非常出色，而Elasticsearch和Lucene对此几乎没有规定。

我是否可以断言，如果我不需要近似答案，那么与已经使用的图形数据库相比，ElasticSearch会毫无用处吗？

我犹豫将ElasticSearch称为数据库。它不能替代数据库，但是可以很好地添加功能，尤其是在现有数据库旁边添加功能，尤其是高级文本搜索。

我知道您在哪里会让他们感到困惑。它们实际上可以满足相同的需求，但并非总是如此。ElasticSearch也正是它听起来像，搜索。图数据库没有像ElasticSearch那样指定关系或索引。因此，从根本上说，它们的工作方式完全不同。ElasticSearch 使用例如英语分析器来分析文档。这将需要单词并分析该单词甚至同义词的不同变体。例如，dig将解析为dig,digs,dug,digging,digger ...。当您在elasticsearch上运行查询时，您的查询也可以被分析，然后查询这些单词并可以根据相关性对其评分。

ElasticSearch是一个很棒的工具，因为它非常灵活。您可以找到各种各样的相对含量，也可以在干草堆中找到一根针，并且相对容易。

图形数据库也有其优势。查找诸如哈希标签之类的事物或具有许多可变关系的事物之间的关联/关系。它们是很棒且有趣的技术，但是我不得不说它不如ElasticSearch强大。主要是因为ElasticSearch专门针对此类事情，并且可以为您处理分析，因此您可以进行全文搜索。但是，如果您希望使用更多系统，例如基于预定义标签/关键字的twitter搜索，那么最好使用已经使用的Graph数据库。

问题是您希望搜索有多健壮？如果您需要进行非常精细的（全文本）搜索，则可以使用elasticsearch。否则，您总是可以在图形数据库上相对轻松地实现搜索。一旦您实现了搜索，如果以后发现自己需要一个更强大的搜索引擎，就可以迁移到elasticsearch了，只要考虑到这一点就可以实现搜索。

这两个数据库都有其特定的需求，可以在特定级别的应用程序需求下解决特定的问题。尽管我们尚未使用图数据库。但是，在过去五年中，我们在其中一个项目中将MySQL与Elasticsearch结合使用。该项目具有要通过600万个文档进行搜索的海量数据，并且在这些实体之间具有海量关系（1000万个关系文档）。

用例： 喜欢搜索我的朋友喜欢的酒店，并按喜欢的酒店数量对所有酒店进行排序。如果您仔细观察的话。此案涉及2个关系（Friend，Like）。因此，我需要搜索“酒店”和“我的朋友”之间的“喜欢”关系船，然后应该按照他们的喜欢总数来对酒店进行排序。因此，对于此类搜索，图形数据库很好。

Elasticsearch在文档中进行全面测试搜索方面做得很好，但是当要通过上述关系进行搜索时，效果并不是很好。列出谁是我的粉丝，并按粉丝数量对其进行排序。但是这些是一个层次的深度，当涉及到更深入的搜索时。Elasticsearch不够好。

因此，请了解您的应用程序需求，然后再选择数据库。您可能需要同时拥有两者。