我们公司有几个产品和几个团队。一个团队负责搜索，并且正在将 Elasticsearch 标准化为一个 nosql 数据库来存储他们的所有数据，并计划稍后使用 Neo4j 来补充他们的关系数据搜索。
我的团队负责社交应用程序的产品方面(人们有 friend ，为公司工作，并且与在公司工作的每个人都是同事，等等)。我们正在将图形数据库视为一种解决方案(在放弃了 rdbms 中 n^2 关系的燃烧船之后)，特别是 neo4j(Cypher 查询语言是一个美丽的东西)。
我们的一部分数据与搜索团队使用的数据类似，我们需要确保搜索可以同时搜索他们的数据和我们的数据。搜索团队正在插入我们将 ElasticSearch 标准化为我们的数据库，而不是 Neo4j 或任何图形数据库。我认为这是为了标准化和一致性。
我们显然来自不同的地方，搜索问题与产品问题。他断言 ElasticSearch 可以涵盖我们所有的用例，包括用于查找建议的图形查询。虽然这可能是真的，但我真的希望坚持使用 Neo4j，并使用 ElasticSearch 插件来集成他们的搜索。
在这种情况下，为产品数据库选择 ElasticSearch 而不是 Neo4j(反之亦然)是否有任何主要问题？有过类似情况的人有什么指导方针或轶事吗？
最佳答案
我们是这两种技术的重度用户，根据我们的经验，您最好将两者都用于它们擅长的领域。
就搜索功能、日志管理和方面而言，Elasticsearch 是一款非常出色的软件。
尽管有他们的图形插件，如果你想在 elasticsearch 索引中使用大量社交网络和类似关系，你将遇到两个问题:
每次关系发生变化时，您都必须更新文档，当单个实体发生变化时，这种情况可能会很多。例如，假设你的组织有用户在 github 上做贡献，你想搜索在某种语言上有顶级贡献者的组织，每次用户在 github 上做贡献时，你都必须重新索引整个组织，计算所有用户的语言贡献百分比等......这是一个简单的例子。
如果您打算使用嵌套字段和父/子映射，您将在搜索过程中降低性能，作为引用，此处引用“搜索调整”文档中的内容:https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html#_document_modeling
Documents should be modeled so that search-time operations are as cheap as possible.
In particular, joins should be avoided. nested can make queries several times slower and parent-child relations can make queries hundreds of times slower. So if the same questions can be answered without joins by denormalizing documents, significant speedups can be expected.
关系在像 neo4j 这样的图形数据库中得到了很好的处理。相反，Neo4j 缺乏 elasticsearch 提供的搜索功能，可以进行全文搜索但性能不佳，并且会给您的应用程序带来一些负担。
请注意:当您谈论“存储”时，elasticsearch 是一个搜索引擎而不是数据库(尽管它被广泛使用)，而 neo4j 是一个完全事务性的数据库。
然而，将两者结合起来才是制胜法宝，我们实际上已经写了一篇文章来描述我们称之为 Graph-Aided Search 的过程，其中包含一组用于 Elasticsearch 和 Neo4j 的开源插件，为您提供了一个开箱即用的强大双向集成。
您可以在这里阅读更多相关信息:http://graphaware.com/neo4j/2016/04/20/graph-aided-search-the-rise-of-personalised-content.html
关于elasticsearch - 与图形数据库相比，将 ElasticSearch 用作社交应用程序的 nosql 数据库有哪些陷阱？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38135000/