大型写入性能问题

Question

我和我的公司购买了大约 80,000 美元的硬件来完成一个目标。我们在 Cassandra 集群的多个应用程序数据库中每秒大约有 22,000 次写入。我们构建了 2 个双 3.5Ghz Xeons 节点、128GB RAM、Areca 1883，所有这些都是顶级的高吞吐量。我们还有一个用于 Commitlog/saved_caches 的 SSD RAID 10 阵列，因此不会延迟。

我们遇到的问题是数据量。在大约 4 天内，我们收集了 1.8TB 的数据。我们无意发布数据。然后我们得到了一个 JBOD 机箱并放入 6TB Platter 驱动器，每个 10 个，总共 20 个，大约 110TB 的空间。单次复制运行良好，问题是当我们运行双次复制时。

我们很乐意添加更多节点，我们知道这是正确的方法，但在 20,000 美元一个节点上它的成本很高。我的问题是，如果我们的写入速度是问题，那么在每台机器上增加 10 个驱动器应该允许双倍的写入速度，这是真的吗？

有没有人发生过一些类似的事情并对 Cassandra.yaml 进行了一些调整？

当我们进行双重复制时，我们确实运行了一段时间 htop，CPU 似乎确实有点密集（平均读取 24%，但看起来非常接近最大值）。 RAM 已全部使用，128GB。

任何关于此事的想法都会被考虑和调查。

谢谢，

肯

Answer 1

一般来说，您不能通过增加磁盘来提高写入速度，除非您确定自己受 IO 限制。 Cassandra 批量写入（突变首先进入提交日志，然后是 RAM 中的一个表，然后当该表达到某个阈值时批量写入 sstables - 线性写入，因此它通常很快，即使在旋转磁盘上也是如此）。在某些时候，您将最大化提交日志驱动器，填充内存表的速度比刷新速度快，或者只是到达 GC 无法跟上的地步。

有相当大的 Cassandra 用户在给定服务器上运行多个 Cassandra 实例只是为了获得额外节点的好处，而无需“仅仅”添加磁盘。通过运行两个 JVM，您可以减少单个节点的暂停时间，并且仍然可以利用您的（超大）硬件。如果您可以为各个服务器分配多个 IP，这是最简单的，但在不同端口上运行也可以。这是相当不典型的，您需要密切注意您的配置以避免相互踩踏，但它会起作用，并且比简单地运行大型节点更有效地利用您的硬件。

Answer 2

如果我没看错，你总共只有 2 个节点？

如果您只有 2 个节点，我怀疑磁盘带宽是否会成为问题。 Cassandra 通常比其他任何东西都更受 CPU 限制。

写入通常会进入内存，因此只有当 memtables 作为 SStables 刷新到磁盘时，磁盘才会发挥作用。现在，可能会影响您的性能的是那些 SStables 需要被压缩的时候。当压缩开始发生时，猜测系统的哪个部分会增加压力，没错，就是 CPU。

您也会在使用这样的大磁盘进行修复时遇到问题。通常我发现持续的事务吞吐量受到压缩和修复的限制，而不是原始写入性能。

使用两个节点和单个复制，您将在两个节点之间分配负载，一半分配给一个节点，一半分配给另一个节点。如果您将复制因子设置为 2，那么现在每次写入都将发送到两个节点，这就像时光倒流回到拥有单机数据库一样。

所以我认为购买少量高端机器是一个糟糕的选择。如果每台机器都更便宜，你会得到更好的性能。您需要更多的机器来分散负载并获得更多的 CPU。

您还提到了磁盘盒。我希望您不要尝试将网络存储与 Cassandra 一起使用。它需要磁盘是本地的。