MongoDB与Cassandra vs. MySQL的实时广告平台

Question

我正在研究一个非常注重性能的实时广告平台。我一直用MySQL开发，但如果能够实现显着的速度提升，我可以尝试像MongoDB或Cassandra这样的新东西。我一整天都在阅读，但由于两者都在迅速发展，很多信息似乎都有点过时了。

存储的主要数据是每次点击的条目，视图的递增行和每个广告系列的信息（只是一些基本设置等）。需要在插入点击，更新视图总数和生成实时统计报告时找到速度增益。该平台是用PHP开发的。

或许没有这些？

Answer 1

有几种方法可以通过列出的所有技术实现这一目标。这更像是你如何使用它们的问题。您的理想解决方案可以结合使用这些，并考虑使用模式。我觉得那里的信息没有过时，因为现在的概念非常重要。可能有新的NoSQL数据库和现有的数据库修复，但您的问题主要是架构。

像MongoDB和Cassandra这样的NoSQL解决方案因其插入性能而备受关注。人们倾向于抱怨关系数据库的更新/插入性能，但有一些方法可以缓解这些问题。

从MySQL开始，您可以查看O'Reilly的High Performance MySQL，优化架构，添加更多内存，或者在应用程序的其余部分（假设您使用MySQL）或分区/分片的不同硬件上运行此内存数据。另一个需要考虑的方面是您的申请。您可以在插入数据库之前在应用程序级别对插入和更新进行排队吗？这将为您提供一些灵活性，并且在所有情况下都可能有用。根据最终模式的外观，只要您熟悉SQL，MySQL就会为您提供一些提取数据的帮助。如果您需要使用第三方报告工具等，这是一个好处。

MongoDB和Cassandra是不同的野兽。我的理解是，向后者添加节点更容易，但是由于MongoDB内置了复制等功能，因此已经发生了变化。这两个平台的插入不受与关系数据库相同的约束。拉出数据也很快，并且您在数据格式更改方面具有很大的灵活性。权衡是您不能使用SQL（对某些人来说是一种好处），因此获取报告可能会更棘手。没有什么可以阻止您在其中一个平台中收集数据，然后将其导入MySQL数据库以进行进一步分析。

根据您的要求，您应该查看NoSQL数据库以外的工具，例如Flume。这些利用了广泛用于分析的Hadoop平台。对于您正在做的事情，这些可能比数据库具有更大的灵活性。您可能会对Hadoop World中的一些内容感兴趣。

Answer 2

Nosql解决方案比Mysql，postgresql和其他rdbms技术更适合此任务。不要浪费你的时间在Hbase / Hadoop上，你必须成为一名宇航员才能使用它。我推荐MongoDB和Cassandra。 Mongo对于小型数据集更好（如果您的数据最大比ram大10倍，否则您需要分片，需要更多机器并使用副本集）。对于大数据;卡桑德拉是最好的。 Mongodb有比cassandra更多的查询选项和其他功能，但你需要64位机器用于mongo。双方都有一些分析工作。双方都有原子计数器。两者都可以很好地扩展，但cassandra在扩展和高可用性方面要好得多。两者都有php客户端，都有很好的支持和社区（mongo社区更大）。

Cassandra分析项目示例：Rainbird http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011

mongo示例：http://www.slideshare.net/jrosoff/scalable-event-analytics-with-mongodb-ruby-on-rails

http://axonflux.com/how-superfeedr-built-analytics-using-mongodb

doubleclick开发人员开发了mongo http://www.informationweek.com/news/software/info_management/224200878

Answer 3

MySQL的特点：

• 数据库锁定（金融交易更容易）
• 一致性/安全性（如上所述，您可以保证，例如，在您阅读银行帐户余额和更新之前不会发生任何变化。）
• 数据组织/重构（您可以在任何地方使用混乱的数据，但使用表示“类型”或“组件”的表格，然后将它们组合到查询中时，MySQL会更好 - 这称为规范化）。

Cassandra的特点：

• 速度
• 可用性（数据始终可用，无论是100％“正确”）
• 可选字段（可以在MySQL中使用元表等完成，但在Cassandra中是免费的）

Cassandra是键值或基于文档的存储。想想这意味着什么。通常我给Cassandra ONE KEY，然后我回来了一个DATASET。它可以从那里分支出来，但这基本上是正在发生的事情。这更像是访问静态文件。当然，你可以有多个索引，计数器字段等，但我正在进行推广。这就是卡桑德拉的来源。

MySQL和SQL基于组/集理论 - 它有一种方法可以组合数据集之间的任何关系。获取MySQL查询，使查询成为“密钥”并将响应变为“值”并将其存储到Cassandra（例如，将Cassandra作为缓存）非常容易。这可能有助于解释权衡，MySQL允许您只需编写不同的查询就可以重新排列数据表和数据集之间的关系。卡桑德拉不是那么多。并且知道虽然Cassandra可能会提供一些功能来完成这些工作，但它不是为它而构建的。

MongoDB和CouchDB适合处于这两个极端的中间位置。我认为MySQL可能有点冗长和烦人，特别是在处理可选字段时，如果没有好的模型或工具，则会进行迁移。同样具有可扩展性，我确信有很多用于扩展MySQL数据库的技术，但由于其功能集的限制，Cassandra将始终可以轻松扩展。 MySQL有点无限。但是，NoSQL和Cassandra不会 进行连接，这是SQL的一个关键功能，它允许在单个查询中组合多个表。因此，复杂的关系查询不会在Cassandra中扩展。

Answer 4

我还想将Membase（www.couchbase.com）添加到此列表中。

作为一种产品，Membase已部署在多家广告公司（AOL Advertising，Chango，Delta Projects等）。有许多公共案例研究以及这些公司如何成功使用Membase的例子。

虽然它肯定有争议，但我们发现Membase提供了比任何其他解决方案更好的性能和可扩展性。我们在索引/查询中缺少的是，我们计划的不仅仅是将CouchDB集成为新的持久性后端。

作为一家公司，Couchbase（Membase的制造商）拥有大量专门为广告/定位公司提供服务的知识和经验。

肯定会喜欢和你讨论这个特殊的用例，看看Membase是否合适。

请给我发一封电子邮件（perry -at-couchbase -dot- com）或在论坛上访问我们：http://www.couchbase.org/forums/

Perry Krug

Answer 5

Cassandra与MongoDB 您是否正在考虑将Cassandra或MongoDB作为下一个项目的数据存储？你想比较两个数据库吗？ Cassandra和MongoDB都是“NoSQL”数据库，但实际情况是它们非常不同。他们有不同的优势和价值主张 - 所以任何比较都必须是细致的。让我们从最初的要求开始......这些数据库都没有取代RDBMS，也不是“ACID”数据库。因此，如果您有一个事务性工作负载，其中规范化和一致性是主要要求，那么这些数据库都不适合您。你最好坚持使用传统的关系数据库，比如MySQL，PostGres，Oracle等。现在我们已经开始使用关系数据库了，让我们考虑一下Cassandra和MongoDB之间的主要区别，它们可以帮助你做出决定。在这篇文章中，我不打算讨论具体的功能，但会指出一些高级别的战略差异，以帮助您做出选择。

1. 表达对象模型 MongoDB支持丰富且富有表现力的对象模型。对象可以具有属性，对象可以彼此嵌套（对于多个级别）。此模型非常“面向对象”，可以轻松表示域中的任何对象结构。您还可以在层次结构的任何级别索引任何对象的属性 - 这非常强大！另一方面，Cassandra提供了一个包含行和列的相当传统的表结构。数据更加结构化，每列都有一个特定的类型，可以在创建过程中指定。

结论：如果您的问题域需要丰富的数据模型，那么MongoDB更适合您。

1. 二级索引 辅助索引是MongoDB中的第一类构造。这使得很容易索引存储在MongoDB中的对象的任何属性，即使它是嵌套的。这使得基于这些二级索引进行查询变得非常容易。 Cassandra只对粗略指数有粗略的支持。二级索引也仅限于单列和相等比较。如果你主要是通过主键查询，那么Cassandra将很适合你。

结论：如果您的应用程序需要二级索引并且在查询模型中需要灵活性，那么MongoDB更适合您。

1. 高可用性 MongoDB支持“单主”模型。这意味着您有一个主节点和许多从节点。如果主站发生故障，其中一个从站将被选为主站。此过程自动发生，但需要时间，通常为10-40秒。在新的领导者选举期间，您的副本集已关闭，无法进行写入。这适用于大多数应用程序，但最终取决于您的需求。 Cassandra支持“多主”模型。丢失单个节点不会影响群集进行写入的能力 - 因此您可以实现100％的写入正常运行时间。

结论：如果你需要100％的正常运行时间，Cassandra更适合你。

1. 编写可伸缩性 具有“单主”模型的MongoDB只能在主数据库上进行写操作。辅助服务器只能用于读取。因此，如果您有三个节点副本集，则只有主节点正在进行写入，而另外两个节点仅用于读取。这极大地限制了写入可伸缩性。您可以部署多个分片，但基本上只有1/3的数据节点可以进行写入。 Cassandra及其“多主”模型可以在任何服务器上进行写入。基本上，您的写入可伸缩性受到群集中服务器数量的限制。您在群集中拥有的服务器越多，它就越容易扩展。

判决：如果写你的可扩展性是你的事，那么Cassandra更适合你。

1. 查询语言支持 Cassandra支持与SQL非常相似的CQL查询语言。如果您已经拥有一个数据分析团队，他们将能够移植大部分SQL技能，这对大型组织非常重要。但是CQL并不是完整的ANSI SQL - 它有几个限制（没有连接支持，没有OR子句）等。此时MongoDB不支持查询语言。查询的结构为JSON片段。

结论：如果您需要查询语言支持，Cassandra最适合您。

1. 绩效基准 我们来谈谈表演。此时，您可能期望对数据库进行性能基准比较。我故意没有在比较中包括性能基准。在任何比较中，我们必须确保我们进行一对一的比较。

2. 数据库模型 - 正在测试的应用程序的数据库模型/模式有很大的不同。有些模式非常适合MongoDB，有些模式非常适合Cassandra。因此，在比较数据库时，使用对两个数据库都运行良好的模型非常重要。

3. 负载特性 - 基准负载的特性非常重要。例如。在写得很重的基准测试中，我希望Cassandra能够吸食MongoDB。但是，在读取繁重的基准测试中，MongoDB和Cassandra的性能应该相似。
4. 一致性要求 - 这是一个棘手的问题。您需要确保指定的读/写一致性要求在两个数据库中都是相同的，而不是偏向于一个参与者。通常在许多“营销”基准测试中，旋钮被调整为对另一方不利。因此，请密切关注一致性设置。

要记住的最后一件事是基准负载可能会也可能不会反映您的应用程序的性能。因此，为了使基准测试有用，找到反映应用程序性能特征的基准负载非常重要。以下是您可能需要查看的一些基准测试： - NoSQL性能基准测试 - Cassandra vs. MongoDB vs. Couchbase vs. HBase

1. 易于使用 如果你在几年前问过这个问题，那么MongoDB将成为不折不扣的赢家。启动和运行MongoDB是一项相当简单的任务。然而，在过去的几年里，Cassandra在产品的这方面取得了长足的进步。随着CQL作为Cassandra的主要接口的采用，它更进了一步 - 它们让很多SQL程序员非常容易地使用Cassandra。

结论：两者都相当容易使用和提升。

1. 原生聚合 MongoDB有一个内置的Aggregation框架来运行ETL管道来转换存储在数据库中的数据。这对于中小型作业非常有用，但随着数据处理需求变得更加复杂，聚合框架变得难以调试。 Cassandra没有内置的聚合框架。像Hadoop，Spark这样的外部工具就用于此。

2. 无架构模型 在MongoDB中，您可以选择不对文档强制执行任何架构。虽然这是较新版本的先前版本中的默认值，但您可以选择为文档强制执行架构。 MongoDB中的每个文档都可以是不同的结构，由您的应用程序来解释数据。虽然这与大多数应用程序无关，但在某些情况下，额外的灵活性非常重要。较新版本的Cassandra（使用CQL作为默认语言）提供静态类型。您需要预先定义非常类型的列。

Answer 6

我会将New Relic视为类似工作量的一个例子。他们每天捕获超过200亿个数据点到磁盘，并使用MySQL 5.6（Percona）作为后端。

此处提供博文： http://blog.newrelic.com/2014/06/13/store-200-billion-data-points-day-disk/