繁体 English 中英

MongoDB vs. Cassandra vs. MySQL 用于实时广告平台

[英]MongoDB vs. Cassandra vs. MySQL for real-time advertising platform

原文 2011-05-28 16:06:46 1 6 mongodb/ database-design/ cassandra/ database/ nosql

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

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

或者这些都不是？

6 个解决方案

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

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

Starting with MySQL you could review O'Reilly's High Performance MySQL , optimise the schema, add more memory perhaps run this on different hardware from the rest of your app (assuming you used MySQL for that), or partition/shard data. 另一个需要考虑的领域是您的应用程序。 您可以在插入数据库之前在应用程序级别对插入和更新进行排队吗？ 这将为您提供一些灵活性，并且可能在所有情况下都有用。 根据您最终模式的外观，只要您对 SQL 感到满意，MySQL 就会在提取数据方面为您提供一些帮助。 如果您需要使用 3rd 方报告工具等，这是一个好处。

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

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

MySQL的特点：

数据库锁定（金融交易更容易）
一致性/安全性（如上所述，您可以保证，例如，在您读取银行账户余额和更新它之间不会发生任何变化）。
数据组织/重构（您可以在任何地方拥有杂乱无章的数据，但 MySQL 更适合表示“类型”或“组件”的表，然后将它们组合成查询——这称为规范化）。
MySQL（和关系数据库）更适合于 AGILE 软件项目中常见的任意数据集和需求。

Cassandra的特性：

速度：用于简单检索大型文档。 但是，它需要对高度相关的数据进行多次查询——并且“默认情况下”这些查询可能不一致（并且数据集可以在这些查询之间更改）。
可用性：与“一致性”相反。 数据始终可用，无论是否 100%“正确”。 ^[1]
可选字段（宽列）：这可以在 MySQL 中使用元表等完成，但在 Cassandra 中是免费和默认的。

Cassandra 是键值或基于文档的存储。 想想这意味着什么。 通常我给 Cassandra 一个密钥，然后我得到一个数据集。 它可以从那里分支出来，但这基本上就是正在发生的事情。 这更像是访问 static 文件。 当然，您可以有多个索引、计数器字段等，但我只是在做一个概括。 这就是 Cassandra 的来源。

MySQL 和 SQL 基于组/集理论——它可以结合数据集之间的任何关系。 获取 MySQL 查询非常容易，将查询设为“键”，将响应设为“值”并将其存储到 Cassandra 中（例如，将 Cassandra 设为缓存）。 这也可能有助于解释权衡，MySQL 允许您始终通过编写不同的查询来重新排列数据表和数据集之间的关系。 Cassandra 没那么多。 并且知道虽然 Cassandra 可能会提供一些功能来做这些事情，但这不是它的目的。

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

[1] 一致性与可用性是大型分布式数据集内的权衡。 让所有节点都知道新数据需要一段时间，例如。 Cassandra 选择快速回复，而不是在回复之前检查每个节点。 当您注销以前读取的数据并覆盖数据时，这可能会导致奇怪的边缘情况。 有关更多信息，请查看CAP Theorem 、 ACID数据库（特别是Atomicity ）以及Idempotent数据库操作。 MySQL 也有这个问题，但是高可用性而不是正确性的想法非常融入 Cassandra 并赋予它许多可扩展性和速度优势。

[2] SQL 过于“冗长”并不是不使用它的好理由——而且我们大多数人不会（也不应该）编写纯文本 SQL 语句。

Nosql 解决方案优于 Mysql、postgresql 和其他 rdbms 技术。 不要在 Hbase/Hadoop 上浪费时间，你必须成为一名宇航员才能使用它。 我推荐 MongoDB 和 Cassandra。 Mongo 更适合小型数据集（如果您的数据最大比内存大 10 倍，否则您必须分片，需要更多机器并使用副本集）。 对于大数据； cassandra 是最好的。 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

Cassandra 与 MongoDB 您是否考虑将 Cassandra 或 MongoDB 作为下一个项目的数据存储？ 您想比较这两个数据库吗？ Cassandra 和 MongoDB 都是“NoSQL”数据库，但现实情况是它们非常不同。 他们有非常不同的优势和价值主张——所以任何比较都必须是细致入微的。 让我们从最初的需求开始……这些数据库都没有取代 RDBMS，也不是“ACID”数据库。 因此，如果您有一个以规范化和一致性为主要要求的事务工作负载，那么这些数据库都不适合您。 You are better off sticking with traditional relational databases like MySQL, PostGres, Oracle etc. Now that we have relational databases out of the way, let's consider the major differences between Cassandra and MongoDB that will help you make the decision. 在这篇文章中，我不会讨论具体的功能，但会指出一些高级别的战略差异，以帮助您做出选择。

Expressive Object Model MongoDB supports a rich and expressive object model. 对象可以具有属性，并且对象可以相互嵌套（用于多个级别）。 这个 model 非常“面向对象”，可以轻松表示您域中的任何 object 结构。 您还可以在层次结构的任何级别索引任何 object 的属性 - 另一方面，这是非常强大的 Cassandra。 提供了一个相当传统的包含行和列的表结构。 数据更加结构化，每一列都有一个特定的类型，可以在创建过程中指定。

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

二级索引二级索引是MongoDB中的一级构造。 这使得索引存储在 MongoDB 中的 object 的任何属性变得容易，即使它是嵌套的。 这使得基于这些二级索引进行查询变得非常容易。 Cassandra 仅粗略地支持二级索引。 二级索引也仅限于单列和相等比较。 如果您主要通过主键进行查询，那么 Cassandra 将非常适合您。

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

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

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

写入可扩展性 MongoDB 及其“单主” model 只能在主节点上进行写入。 辅助服务器只能用于读取。 所以基本上如果你有三个节点副本集，只有主节点进行写入，其他两个节点仅用于读取。 这极大地限制了写入可扩展性。 您可以部署多个分片，但实际上只有 1/3 的数据节点可以进行写入。 Cassandra 及其“多主机” model 可以在任何服务器上进行写入。 本质上，您的写入可扩展性受到集群中服务器数量的限制。 集群中的服务器越多，它的扩展性就越好。

结论：如果您喜欢写可扩展性，那么 Cassandra 更适合您。

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

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

性能基准让我们谈谈性能。 此时，您可能期望对数据库进行性能基准比较。 我故意在比较中不包括性能基准。 在任何比较中，我们都必须确保我们正在进行苹果对苹果的比较。
数据库 model - 正在测试的应用程序的数据库模型/模式有很大的不同。 一些模式非常适合 MongoDB 和一些非常适合 Cassandra。 因此，在比较数据库时，使用 model 非常重要，它对两个数据库都工作得相当好。
负载特性——基准负载的特性非常重要。 例如，在写入量大的基准测试中，我预计 Cassandra 会冒烟 MongoDB。 但是，在读取繁重的基准测试中，MongoDB 和 Cassandra 的性能应该相似。
一致性要求 - 这是一个棘手的要求。 您需要确保指定的读/写一致性要求在两个数据库中是相同的，并且不偏向于一个参与者。 很多时候，在许多“营销”基准中，旋钮被调整为对另一方不利。 因此，请密切注意一致性设置。

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

易用性如果您在几年前问过这个问题，MongoDB 将是毫无疑问的赢家。 启动并运行 MongoDB 是一项相当简单的任务。 然而，在过去几年中，Cassandra 在产品的这方面取得了长足的进步。 随着采用 CQL 作为 Cassandra 的主要接口，它又向前迈进了一步——他们使大量的 SQL 程序员可以非常轻松地使用 Cassandra。

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

原生聚合 MongoDB 有一个内置的聚合框架来运行 ETL 管道来转换存储在数据库中的数据。 这对于中小型作业非常有用，但随着您的数据处理需求变得更加复杂，聚合框架变得难以调试。 Cassandra 没有内置聚合框架。 为此使用了 Hadoop、Spark 等外部工具。
无模式模型在 MongoDB 中，您可以选择不对文档强制实施任何模式。 虽然这是较新版本中先前版本的默认设置，但您可以选择为您的文档强制实施模式。 MongoDB 中的每个文档都可以是不同的结构，由您的应用程序来解释数据。 虽然这与大多数应用程序无关，但在某些情况下，额外的灵活性很重要。 较新版本中的 Cassandra（默认语言为 CQL）提供 static 类型。 您需要预先定义非常列的类型。