【问题标题】:Scenario for using Elasticsearch as primary DB as opposed to MongoDB使用 Elasticsearch 作为主数据库而不是 MongoDB 的场景
【发布时间】:2018-06-12 06:51:31
【问题描述】:

我们目前正在将 MongoDB 用于我们的“大规模数据”产品之一。简而言之,我们使用 Mongo 来存储大量社交媒体数据,例如推文/帖子/主题标签等。所以用例是社交媒体分析。到目前为止,我们在使用 MongoDB 时面临的唯一问题是全文搜索能力和聚合性能。

文档的数量约为 2500 万,我们在单个实例上使用它。此外,我们的大部分分析都是在整个集合上进行的(我们通常没有很多过滤器来减少分析数据集)。最近我们开始研究 Elastic Search。它是一个漂亮的工具,搜索速度非常快。因此,我们正在考虑的一种方案是将其用作 Mongo 之上的搜索层。

但是,经过评估,我们发现 ES 还具有出色的分析能力,尤其是在聚合方面。我们的问题是,使用 ES 作为唯一的数据存储(作为 Mongo 的替代品)是一个好主意。我们看到 ES 的大部分吸引力在于搜索层而不是分析工具。在分析能力中使用 ES 是否有任何缺点。简而言之,Mongo 在哪些方面比 ES 做得更好?

【问题讨论】:

    标签: mongodb elasticsearch


    【解决方案1】:

    就功能而言,您应该被 Elasticsearch 很好地覆盖。过滤器、查询和(流水线)聚合可以完成 MongoDB 所做的一切,甚至更多。

    我主要会注意这两种解决方案提供的弹性:Elasticsearch 并非设计为数据库,在某些情况下可能会发生“坏”事情;尽管它们在resiliency page 上有很好的记录。使用 版本 2.3 甚至 5(目前处于 alpha 阶段) 最新的稳定版本 提供了一个非常稳定的基础以及我在实际中看到的所有数据丢失问题世界应用程序(不是实验室场景)是由于配置错误造成的。

    免责声明:我为 Elastic 工作。

    【讨论】:

      【解决方案2】:

      Elasticsearch 应该适合您的场景。对于热数据(复杂分析),我会使用像 Exasol 这样的分析数据库。对于温暖的数据,你确实可以使用 Elasticsearch——我根本不会使用 MongoDB。对于冷数据(例如原始摄取数据),Hadoop 可能没问题。

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

      至于分析,您可以很好地使用 Elasticsearch 进行聚合和其他类型的聚合统计。当涉及到更复杂的分析功能时,请选择一个体面的分析数据库,或者您可以在 Apache Spark 管道中的摄取期间处理它。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2022-06-23
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-07-10
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多