使用Elasticsearch作为主数据库而不是MongoDB的场景

我们目前正在使用MongoDB作为我们的“大规模数据”产品之一。简单介绍一下，我们使用Mongo来存储大量社交媒体数据，如推特/帖子/标签等。所以这个用例就是社交媒体分析。到目前为止，MongoDB面临的唯一问题是全文搜索能力和聚合性能

文档的数量大约为2500万，我们在单个实例上使用它。此外，我们的大多数分析都是在整个集合上进行的（我们通常没有很多过滤器来减少分析数据集）。最近我们开始研究弹性搜索。这是一个漂亮的工具，搜索速度极快。所以我们考虑的一个场景是将其用作Mongo顶部的搜索层

---

但是，经过评估，我们发现ES也具有很强的分析能力，尤其是在聚合方面。我们的问题是，使用ES作为唯一的数据存储（作为Mongo的替代品）是一个好主意吗。我们从搜索层而不是分析工具的角度看到了ES的大部分吸引力。在分析能力中使用ES有什么缺点吗。简而言之，Mongo在哪些方面比ES做得更好？

就功能而言，Elasticsearch应该很好地涵盖这些功能。过滤器、查询和（流水线）聚合完成了MongoDB所做的一切，还有更多

我将主要注意这两种解决方案提供的弹性：Elasticsearch不是设计的数据库，在某些情况下可能会发生“坏”事情；尽管他们在网站上有很好的记录。使用2.3版甚至5版（目前是alpha版），最新的稳定版本提供了一个非常稳定的基础，我在现实世界的应用程序（不是实验室场景）中看到的所有数据丢失问题都是由于错误的配置造成的

---

免责声明：我为Elastic工作。

Elasticsearch适合您的场景。对于热数据（复杂分析），我会使用像Exasol这样的分析数据库。对于温暖的数据，您确实可以使用Elasticsearch——我根本不会使用MongoDB。对于冷数据（例如，原始摄取数据），Hadoop可以

当您处理摄入端或数据存储库本身的大量数据时，Elasticsearch允许您每天或每种介质或每种其他介质创建索引-查询可能仍然可以跨部分索引工作。与数据库相比，存储库中大多数数据的这种“只读”属性降低了总体硬件成本

至于分析，您可以很好地使用Elasticsearch进行聚合和其他类型的聚合统计。当涉及到更复杂的分析功能时，请选择一个像样的分析数据库，或者您将能够在ApacheSpark管道中处理它