从 MySQL 切换到 Cassandra - 优点/缺点？

Posted 2023-02-24

【中文标题】从 MySQL 切换到 Cassandra - 优点/缺点？

【英文标题】：Switching from MySQL to Cassandra - Pros/Cons?

【发布时间】：2011-01-20 21:16:24

【问题描述】：

了解一些背景知识 - 这个问题涉及在单个小型 EC2 实例上运行的项目，并且即将迁移到中型实例。主要组件有Django、mysql以及大量用python和java编写的自定义分析工具， 起重。同一台机器也在运行 Apache。

数据模型如下所示 - 大量实时数据来自各种联网传感器，理想情况下，我想建立一个长轮询方法，而不是当前每 15 分钟轮询一次的方法（计算统计数据和写入数据库本身的限制）。数据输入后，我将原始版本存储在 MySQL，让分析工具在这些数据上松散，并将统计信息存储在另外几张表中。所有这些都是使用 Django 呈现的。

我需要的关系特征 -

按排序[Cassandra API 中的 SliceRange 似乎可以满足此要求] 分组方式 多个表之间的多对多关系[Cassandra SuperColumns 似乎适用于一对多] Sphinx 为我提供了一个不错的全文引擎，所以这也是必需品。 [在 Cassandra 上，Lucandra 项目似乎满足了这一需求]

我的主要问题是数据读取非常慢（写入也不那么热）。我现在不想在它上面投入大量资金和硬件，我更喜欢可以随时间轻松扩展的东西。从这个意义上说，垂直扩展 MySQL 并非易事（或便宜）。

所以基本上，在阅读了很多关于 NOSQL 的内容并尝试了 MongoDB、Cassandra 和 Voldemort 之类的东西之后，我的问题是，

在中型 EC2 实例上，我是否会通过切换到 Cassandra 之类的东西在读/写方面获得任何好处？ This article (pdf) 似乎确实暗示了这一点。目前，我会说每分钟几百次写入将是常态。对于读取 - 由于数据每 5 分钟左右更改一次，因此缓存失效必须很快发生。在某些时候，它也应该能够处理大量并发用户。即使创建了索引，在 MySQL 对大型表进行一些连接时，应用程序的性能也会被扼杀——大约 32k 行的东西需要一分钟多的时间才能呈现。 （这也可能是 EC2 虚拟化 I/O 的产物）。表的大小约为 4-5 百万行，大约有 5 个这样的表。

鉴于 CAP 定理和最终一致性，每个人都在谈论在多个节点上使用 Cassandra。但是，对于一个刚刚开始发展的项目，是否有意义 部署单节点 cassandra 服务器？有什么注意事项吗？例如，它可以取代 MySQL 作为 Django 的后端吗？ [这是推荐的吗？]

如果我确实要转移，我猜我将不得不重写应用程序的某些部分来做更多的“管理”，因为我必须进行多次查找来获取行。

仅使用 MySQL 作为键值存储而不是关系引擎是否有意义，并继续使用它？这样我就可以利用大量可用的稳定 API 以及稳定的引擎（并根据需要使用关系）。 （Brett Taylor 在 Friendfeed 上的帖子 - http://bret.appspot.com/entry/how-friendfeed-uses-mysql）

我们将不胜感激任何已经完成转变的人的见解！

谢谢。

【问题讨论】：

如果您有兴趣，请查看这个 Django Cassandra 项目：github.com/vaterlaus/django_cassandra_backend

我很好奇您是否最终切换到 Cassandra。我已经在从 php 和 asp.net 切换到 django 的路上，但我不确定现在从 mssql 和 mysql 切换到 Cassandra 是否为时过早。我每秒也有数百条记录进入。

@itgorilla - 我将 cassandra 用于一项非常具体的任务，现在它运行良好。我意识到将它用于“移动”数据库可能不是一个好主意，我的结果证实了这一点（我同意下面的 codemonkey 的回答）。因此，如果您想要真正快速的写入、搜索和非规范化数据并且想要扩展，Cassandra 是一个不错的选择。 （最高的数字是一分钟写几百万！）

经过一年多的工作，我将开发中的应用程序从 cassandra 迁移到了 mysql..

见***.com/questions/18462530/…

【参考方案1】：

Cassandra 和当今可用的其他分布式数据库不提供您习惯于从 sql 获得的那种即席查询支持。这是因为您无法通过连接高效地分发查询，因此重点是非规范化。

但是，Cassandra 0.6（明天正式发布测试版，但如果您不耐烦，您可以自己从 0.6 分支构建）支持 Hadoop map/reduce 进行分析，这听起来很适合您。

Cassandra 为轻松添加新节点提供了出色的支持，即使是添加到最初的一组节点也是如此。

也就是说，以每分钟几百次写入的速度，您可以在很长很长一段时间内使用 mysql。 Cassandra 更擅长作为键/值存储（甚至更好，键/列族），但 MySQL 更擅长作为关系数据库。 :)

目前还没有对 Cassandra（或其他 nosql 数据库）的 django 支持。他们正在讨论为 1.2 之后的下一个版本做点什么，但根据与 pycon 的 django 开发人员的交谈，没有人真正确定那会是什么样子。

【讨论】：

感谢您的回答！几点-当您说重点是非规范化时，这基本上意味着需要完成的任何“连接”都发生在应用程序级别，但是cassandra实际上分发了查询（假设您使用随机分区）？其次 - 我想我现在有几百个写入，但此时我宁愿切换到 KV 存储，而不是必须用几个 100k 写入来完成它:) 最后 - 即使假设 Django-NOSQL 仍然支持不存在，是否有任何东西阻止通过 REST API 实时查询 Cassandra 数据库？

Cassandra 路由是基于行键的，因此任何针对单行的查询只需要打到一台机器上，而且性能非常好。 REST 客户端 api 不适合 Cassandra，因为它允许二进制数据，但更广泛地说，没有什么能阻止您手动使用来自 django 的普通 Python 驱动程序。

【参考方案2】：

如果您是关系数据库开发人员（和我一样），我建议/指出：

在您承诺在生产系统上使用 Cassandra 之前，请先获得一些使用 Cassandra 的经验……尤其是如果该生产系统有一个硬性的完成期限。也许首先将它用作不重要的事情的后端。 事实证明，使用 SQL 引擎进行数据操作的简单事情比我预期的更具挑战性。尤其是索引数据和排序结果集是非常重要的。 数据建模也被证明具有挑战性。作为一名关系数据库开发人员，您带着很多包袱来到谈判桌前……您需要愿意学习如何以非常不同的方式对数据进行建模。

说了这么多，我强烈建议在 Cassandra 中构建 something。如果您像我一样，那么这样做将挑战您对数据存储的理解，并让您重新思考我什至没有意识到自己持有的关系数据库适合所有情况的观点。

我发现的一些很好的资源包括：

Dominic Williams' Cassandra blog posts Secondary Indexes in Cassandra More from Ed Anuff on indexing Cassandra book (not fantastic, but a good start) "WTF is a SuperColumn" pdf

【讨论】：

WTF-is-a-SuperColumn.pdf 的链接失效了，请问您有一份吗？

【参考方案3】：

Django-cassandra 是早期的 beta 模式。 Django 也不是为无 sql 数据库而设计的。 Django ORM 中的 key 是基于 SQL 的（Django 推荐使用 PostgreSQL）。如果您只需要使用 no-sql（您可以在同一个应用程序中混合使用 sql 和 no-sql），则需要冒险使用 no-sql ORM（它比传统的 SQL orm 或直接使用 No-SQL 存储要慢得多）。或者你需要完全重写 django ORM。但在这种情况下，我无法推测，为什么你需要 Django。也许你可以使用其他东西，比如 Tornado？