我们目前正在将MongoDB用于我们的“大规模数据”产品之一。为了给出一个简单的想法，我们使用Mongo来存储很多社交媒体数据，如推文/帖子/主题标签等。因此，用例是社交媒体分析。到目前为止，MongoDB面临的唯一问题是全文搜索功能和聚合性能。
文档数量约为2500万，我们在一个实例上使用它。我们的大多数分析都在整个集合上（我们通常没有很多过滤器来减少分析数据集）。最近我们开始关注弹性搜索。它是一个漂亮的工具，搜索速度非常快。因此，我们考虑的一个场景是将其用作Mongo之上的搜索层。
但是，经过评估后，我们发现ES也具有很强的分析能力，特别是在聚合方面。我们的问题是，使用ES作为唯一的数据存储区（作为Mongo的替代品）是个好主意。我们在搜索层而非分析工具方面看到了ES的大部分牵引力。在分析能力中使用ES是否有任何缺点。简而言之，Mongo比ES做得更好？
答案 0 :(得分：4)
在功能方面，Elasticsearch应该很好地涵盖您。过滤器，查询和（流水线）聚合可以完成MongoDB所做的一切工作。
我会主要关注两个解决方案提供的弹性：Elasticsearch不是设计数据库，在某些情况下会发生“坏”事情;虽然它们在resiliency page上有详细记录。使用版本2.3甚至5（目前处于alpha版本） 最新的稳定版本提供了一个非常稳定的基础以及我在实际中看到的所有数据丢失问题世界应用程序（不是实验室场景）是由于配置错误造成的。
免责声明：我为Elastic工作。
答案 1 :(得分：-1)
Elasticsearch应该适用于您的场景。对于热数据（复杂分析），我会使用像Exasol这样的分析数据库。对于热门数据，您确实可以使用Elasticsearch - 我根本不会使用MongoDB。对于冷数据（例如，原始摄取数据），Hadoop可能没问题。
当您在摄取端或数据存储库本身处理大量卷时，Elasticsearch允许您创建每日或每个介质或每个索引的索引 - 查询可能仍然适用于部分索引。与数据库相比，存储库中大多数数据的此“只读”属性可降低总体硬件成本。
对于分析，您可以非常好地使用Elasticsearch进行聚合和其他类型的聚合统计。当谈到更复杂的分析功能时，可以选择合适的分析数据库，也可以在Apache Spark管道中摄取数据时处理它。