Cassandra 简单操作比Mysql慢很多？答案

【问题标题】：Cassandra is much slower than Mysql for simple operations?Cassandra 简单操作比Mysql慢很多？
【发布时间】：2012-02-09 15:22:33
【问题描述】：

我看到很多这样的说法：“Cassandra 的写入速度非常快”、“Cassandra 的读取速度确实比写入速度慢，但比 Mysql 快得多”

在我的 windows7 系统上：我安装了默认配置的Mysql。我安装了默认配置的 PHP5。我安装了默认配置的 Casssandra。

在 mysql 上进行简单的写入测试：“INSERT INTO wp_test (id,title) VALUES ('id01','test')”给我结果：0.0002(s) 对于 1000 次插入：0.1106(s)

在 Cassandra 上进行简单的相同写入测试：$column_faily->insert('id01',array('title'=>'test')) 给我的结果是：0.005(s) 对于 1000 个插入：1.047(s)

对于读取测试，我还发现 Cassandra 比 mysql 慢得多。

所以问题是，我在 Cassadra 上的一次写入操作有 5ms 的时间听起来是否正确？或者有什么问题，应该至少是 0.5ms。

【问题讨论】：

stackoverflow.com/questions/4068946/… 和 stackoverflow.com/questions/2332113/… 可能有一些有用的建议。
如果 Cassandra 在 Linux 系统上更快乐，我不会感到惊讶。
您不能仅使用 1 条记录进行测试。用一百万进行测试。 MySQL 的写入速度会更慢（尤其是如果使用 InnoDB），但在基于主键读取时可能会更快或更快。
@ceejayoz，在linux系统上测试，samre结果
cassandra 是按比例构建的。有了这样的基准（一个客户端只进行 1000 次插入），mysql 将获胜。当您的 mysql 超过 1 台机器时，您将从 cassandra 获得优势，并且您必须将数据分散到多台机器上。

标签： php mysql performance cassandra

【解决方案1】：

MySQL 驱动程序的成熟度，尤其是 PHP 5.3 中改进的 MySQL 驱动程序，可能会对测试产生一些影响。查询中数据的简单性也完全有可能影响结果 - 可能在插入 100 个值时，Cassandra 变得更快。

从命令行尝试相同的测试并查看时间戳是什么，然后尝试使用不同数量的值。你不能做一个单一的测试并以此为基础做出决定。

【讨论】：

假设我尝试发布典型情况：我有数百万用户，每个用户都想上传 1000 个名称（例如，书名）。从我的测试（与命令行相同）每个用户将等待结果超过 1 秒。如果我的用户少于数百万，那么 mysql 会给我 0.1 秒。这听起来对吗？
也应该测试批量插入。

【解决方案2】：

Cassandra 从并行化和批处理中受益匪浅。尝试在 100 个线程中的每一个线程上执行 100 万次插入（每个线程都有自己的连接，每批 100 个），看看哪些更快。

最后，Cassandra 的插入性能应该是比较稳定的（在很长一段时间内保持高吞吐量）。使用 MySQL，您会发现一旦用于索引的 btree 的内存过大，它就会急剧下降。

【讨论】：

问题是关于每个进程 1 或 1000 次插入的通常速度（让我们像一个用户点击按钮一样思考）。请纠正我，如果我并行发送所有这 1000 个插入，那么我的速度会超过 1 秒？
如果你测试确保插入是可比的。不要在 mysql 上启用不在 cassandra 上的功能。确保 mysql 不安全地插入或仅插入日志。

【解决方案3】：

当人们说“Cassandra 比 MySQL 快”时，他们的意思是当您处理 TB 级数据和许多个同时用户时。 Cassandra（和许多分布式 NoSQL 数据库）针对多个节点上的数百个同时读取器和写入器进行了优化，而 MySQL（和其他关系数据库）经过优化以在单个节点上真正快速运行，但是当您尝试跨多个节点扩展它们时往往会崩溃。顺便说一下，这种权衡有一个概括性 - 绝对最快的磁盘 I/O 是普通的旧 UNIX 平面文件，许多对延迟敏感的金融应用程序因此使用它们。

如果您正在构建下一个 Facebook，您需要像 Cassandra 这样的东西，因为单个 MySQL 机器永远无法承受数千个同时读取和写入的惩罚，而使用 Cassandra 您可以扩展到数百个数据节点并轻松处理该负载。见scaling up vs. scaling out。

另一个用例是当您需要对 TB 或 PB 数据应用大量批处理能力时。 Cassandra 或 HBase 非常棒，因为它们与 MapReduce 集成，允许您在数据节点上运行处理。使用 MySQL，您需要提取数据并将其分散到处理节点的网格中，这会消耗大量网络带宽并带来大量不必要的复杂性。

【讨论】：

我读过很多关于 Cassandra 的好处的文章。我的问题是单个服务器的每次写入操作大约需要 5 毫秒。这个速度听起来对吗？例如，如果有人说他的 mysql 一次写入操作需要 5 毫秒（让我们想想普通服务器），我会用“通常应该更快”来回应他
MySQL 在具有 TB 级数据/许多用户的单个节点上表现良好，不是最好的介绍。人们说它很慢然后有交易等等，但你不必做mysql让你做的所有事情。不同之处在于 cassandra 不允许你这样做。 Cassandra 的限制确实让它更好地扩展。 cassandra 的限制之一是它只执行了一项相对较好的操作，即插入。它在读取 KV 或单个范围索引时没问题。之后就没那么多了。然而，随着时间的推移，Cassandra 正在添加更多功能以实现更高的一致性。
Cassandra 的模型倾向于始终快速插入，通常读取速度较慢，目的是人们会做其他事情来绕过读取限制。

【解决方案4】：

许多用户空间因素都会影响写入性能。如：

每个数据库服务器配置中的数十个设置。
表结构和设置。
连接设置。
查询设置。

您是否正在接受警告或异常？ MySQL 样本从表面上看会产生重复键错误。它可能会在什么都不做的情况下失败。 Cassandra 在同样的情况下可能会做什么，我并不熟悉。

我对 Cassandra 的有限经验告诉我关于插入的一件事，虽然其他一切的性能随着数据的增长而下降，但插入似乎保持相同的速度。它与 MySQL 相比有多快，但我没有测试过。

插入速度可能不是那么快，而是尽量不慢。如果您想要一个更有意义的测试，您需要结合并发性和场景的更多变化，例如大型数据集、各种批量大小等。更复杂的测试可能会随着时间的推移测试数据后插入和读取速度的可用性延迟。

如果 Cassandra 插入数据的第一个调用端口是将其放入队列或简单地追加，我不会感到惊讶。如果您查看一致性级别，这是可配置的。 MySQL 类似地允许您平衡性能和可靠性/可用性，尽管它们允许和不允许的内容会有所不同。

除此之外，除非您深入了解内部结构，否则可能很难说出为什么其中一个比另一个表现更好。

我不久前为 Cassandra 的一个用例做了一些基准测试。对于基准测试，它将首先插入数万行。我不得不让脚本休眠几秒钟，否则在事后运行的查询将看不到数据，并且我正在测试的实现之间的结果会不一致。

如果您真的想要快速插入，请追加到 ramdisk 上的文件。

【讨论】：