应用错误收集

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

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

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

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

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

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

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

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

每次关系发生变化时，您都必须更新文档，这可能会在单个实体发生变化时出现问题。例如，假设您有组织的用户正在github上做贡献，并且您希望搜索具有特定语言的顶级贡献者的组织，每当用户在github上做贡献时，您将不得不重新索引整个组织，计算所有用户的语言贡献百分比等......这是一个简单的例子。
如果您打算使用嵌套字段和partent / child映射，那么在搜索过程中，您将在参考中搜索“adjust for search”文档中的引用：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提供了一组开源插件，为您提供强大的双向集成的盒子。