分析 - mongodb 或 cassandra答案

【问题标题】：Analytics - mongodb or cassandra分析 - mongodb 或 cassandra
【发布时间】：2011-07-09 14:59:31
【问题描述】：

我今天正在使用 mongodb，我对此非常满意。我需要找到事件记录解决方案的解决方案。该日志包括内容印象和点击的登录（如广告系统）。它是多写少读（主要用于每日报告）。似乎 Casandra 之类的解决方案比 Mongodb 更好，后者似乎更适合面向文档的数据结构。有什么想法吗？

【问题讨论】：

您可能想查看此空间中的其他示例。看看蜂鸟 (projects.nuttnet.net/hummingbird)。
蜂鸟看起来棒极了！ :)

标签： mongodb cassandra analytics

【解决方案1】：

Cassandra 的优点之一是它支持 Hadoop map/reduce，这使它能够访问一个非常强大的生态系统（例如 Pig），包括工具、示例等。

根据数据量和用例，您可能还想利用其过期列功能 (http://www.datastax.com/dev/blog/whats-new-cassandra-07-expiring-columns)。

Gemini 最近也开源了其 Cassandra 实时日志处理工具，可能和你想要的差不多（http://www.thestreet.com/story/11030367/1/gemini-releases-real-time-log-processing-based-on-flume-and-cassandra.html,https://github.com/geminitech/logprocessing）。

【讨论】：

Cassandra 是否适合随机读取 - 我认为这对于实时分析系统很重要？我认为 HBase/MongoDB 更适合实时部分，尤其是当您有动态的、最终用户生成的查询并需要实时访问分析数据时。

【解决方案2】：

我们在其中一个项目中使用了 mongodb 来捕获分布式应用程序的事件日志记录。它工作得非常好，事先对存储量、分片和其他因素进行一些计算是有意义的。

作为建议，使用上限收集并每隔 24 小时左右运行一次 mapreduce 操作，以将日志减少为所需值的聚合表。我注意到，由于“无模式”，mongodb 中的文档会导致 db 文件大小增长得非常快。

【讨论】：

一个更好的主意是使用计数器和 $inc 来“预聚合”。那么就不需要 map/reduce 并且聚合总是有效的。您可以为不同的时间粒度创建不同的聚合。这样做的关键是知道在收集数据时要如何聚合。
预聚合时，我通常不喜欢有上限的集合。我总是喜欢保留所有原始数据。这样，如果我想出一个新的指标或我想要聚合的方式，我可以返回并从原始数据重建聚合。

【解决方案3】：

Cassandra 针对高写入吞吐量（每秒数千次写入）进行了优化，因此至少在该标准上似乎是合适的。但是，如果 MongoDB 性能对您的应用程序来说足够好，并且您熟悉它，那么 Cassandra 可能没有太多优势。

【讨论】：

【解决方案4】：

实际上，这些数据库都不是单独用于分析的。每次为您的解决方案选择 NoSql 解决方案时，您都必须考虑如何操作数据。

Cassandra 非常适合写入具有可预测性能的大量数据，它很容易在多数据中心环境中进行扩展。另一方面，阅读性能取决于一致性因素。

MongoDB 非常适合结构化数据，在您的情况下这不是优势。 MongoDB 确保它们的数据是一致的，但这一事实可能会导致性能下降。 MongoDB 不适合多数据中心环境。

关于访问数据，它们也完全不同。 Cassandra 提供了 CQL (akka SQL)，不支持 Join 、 group 等。与 Cassandra CQL 相比，MongoDB 使用 JavaScript ,Json，它使用自己的 map/reduce 实现来进行连接操作。

总而言之，我认为您在选择其中一个数据库时应该考虑所有这些事实。从我的角度来看，Cassandra 非常适合您的任务，但在开始使用 Cassandra 之前，您应该仔细考虑模型以及将使用哪种查询

附：我建议将 SQL 引擎考虑为 MongoDb 的 Apache Drill 和 Cassandra 的 PrestoDB 用于分析目的

【讨论】：