使用ElasticSearch作为社交应用程序的NoSQL数据库与使用图形数据库相比存在什么陷阱？

Question

我们公司有多个产品和多个团队。其中一个团队负责搜索，并正在标准化使用Elasticsearch作为nosql数据库来存储他们所有的数据，并计划使用Neo4j来补充他们的搜索关系数据。

我的团队负责社交应用程序的产品方面（人们有朋友，为公司工作，并将与在他们公司工作的所有人成为同事等）。我们正在寻找图形数据库作为解决方案（在放弃RDBMS中n ^ 2关系的情况下），特别是neo4j（Cypher查询语言非常好）。

我们的一部分数据类似于搜索团队使用的数据，我们需要确保搜索可以同时搜索他们的数据和我们的数据。搜索团队正在推动我们标准化使用ElasticSearch作为我们的数据库，而不是Neo4j或任何图形数据库。我认为这是为了标准化和一致性。

我们显然来自非常不同的地方，搜索关注点与产品关注点。他断言ElasticSearch可以涵盖我们所有的用例，包括类似于图形的查询以查找建议。虽然这可能是正确的，但我真的想坚持使用Neo4j，并使用ElasticSearch插件与他们的搜索集成。

在这种情况下，选择ElasticSearch还是Neo4j作为产品数据库（反之亦然）是否存在任何重大问题？有没有任何指导方针或类似情况的轶事？

- InverseFalcon

---

Elasticsearch提供了图形功能。问题实际上是关于您想如何使用它，以及您是想要具有一些图形功能的数据存储，还是带有非常少搜索功能的图形数据存储。 - pickypg

@pickypg 如果我理解有误，请纠正我，但那似乎主要用于浏览和以图形方式可视化数据，并探索数据的有趣关系特征。这两种用例都非常棒，所以我应该澄清一下，我更感兴趣的是以面向图形的方式轻松建模数据和关系，并进行查询（使用图形数据库无痛）。有整合两者的解决方案，我会倾向于选择最佳方案。 - InverseFalcon

这里有一个与之相对应的_graph API端点。老实说，我不知道它对你的兴趣有何比较。 - pickypg

Answer 1

我们是两种技术的重度用户，根据我们的经验，你最好用它们各自擅长的领域。

Elasticsearch在搜索功能、日志管理和facets方面是一款非常好的软件。

尽管有它们的graph插件，如果你想在elasticsearch索引中使用大量社交网络和类似的关系，你将会遇到两个问题：

1. 每次关系变化时，你都必须更新文档，这可能会导致大量操作。例如，假设你有组织拥有在Github上做出贡献的用户，并且你想搜索某一语言中前贡献者所在的组织，那么每当用户在Github上做出贡献时，你都需要重新索引整个组织，并计算所有用户的语言贡献百分比等等... 这只是一个简单的例子。

2. 如果你打算使用嵌套字段和父/子映射，你将会损失搜索性能，来自“搜索调优”文档的引用如下：https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html#_document_modeling

文档应该被建模得尽可能便宜的搜索时间操作。

特别是，应该避免连接查询。嵌套可以使查询变慢数倍，父/子关系可以使查询变慢数百倍。因此，如果通过去规范化文档来避免连接查询可以回答相同的问题，则可以期望显著加快速度。

关系在图形数据库中像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

- Christophe Willemsen

---

非常好的回答，很高兴能从有经验的人那里获得建议！ - InverseFalcon