将ElasticSearch用作社交应用程序与图形数据库的nosql数据库有哪些缺陷？

Question

我们公司有几个产品和几个团队。 一个团队负责搜索，并将Elasticsearch标准化为nosql数据库以存储他们的所有数据，并计划稍后使用Neo4j来赞美他们的搜索关系数据。

我的团队负责社交应用程序的产品方面（人们有朋友，为公司工作，并且将与在公司工作的每个人一起成为同事）。 我们将图dbs视为一种解决方案（在放弃rdbms中n ^ 2关系的燃烧船之后），特别是neo4j（Cypher查询语言是一件很棒的事情）。

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

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

在这种情况下，对于产品数据库而言，选择ElasticSearch而非Neo4j是否存在任何重大问题（反之亦然）？ 那些处于类似情况的人的指导方针或轶事？

Answer 1

我们是这两种技术的重要用户，根据我们的经验，您最好将它们用于它们的优点。

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

尽管他们的图形插件，如果你想在弹性搜索索引中使用很多社交网络和相似的关系，你将有两个问题：

1. 每次关系发生变化时，您都必须更新文档，这可能会在单个实体发生变化时产生很大影响。 例如，假设您有组织的用户正在github上做贡献，并且您希望搜索具有特定语言的顶级贡献者的组织，每当用户在github上做贡献时，您将不得不重新索引整个组织，计算所有用户的语言贡献百分比等......这是一个简单的例子。

2. 如果您打算使用嵌套字段和partent / child映射，那么在搜索过程中，您将在参考中找到“调整搜索”文档的引用： 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