调整 cassandra 中的写入性能答案

【问题标题】：Tuning write performance in cassandra调整 cassandra 中的写入性能
【发布时间】：2014-02-17 10:18:11
【问题描述】：

我们有这个典型的场景：

包含少于 10 个简单列的 1 个列族。

当我们收到来自客户端的请求时，我们需要在数据库中写入该列族的 10 000 000 条记录，并且我们正在分批写入它们（一批 1000 条）。这通常会持续 5-10 分钟，具体取决于集群中的节点数量和复制因子。

在接下来的几个小时内开始写入后，我们将收到大量更新（每条记录更新 2 次）。

所以我们在一天的某个时间段（一小时）内有很多写入/更新，之后就很少了。

问题是：采取哪些步骤来提高写入/更新性能。我注意到例如 memtable_flush_queue_size 和类似的配置字段，但我没有足够的 cassandra 经验来确切地知道该怎么做。

任何建议都有帮助，

伊万

【问题讨论】：

你为什么又担心写性能？如果到“大量更新”时，您已经完成了原始输入的编写，这无关紧要。

标签： nosql cassandra

【解决方案1】：

增加 JVM 内存（Java 6+ 上最大 12 GB）- 这将自动增加内存表的大小并减少刷新间隔。这也意味着，频繁的更新将在 RAM 中合并，而不是在压缩期间 - 这也将减少磁盘使用量。像往常一样有缺点 - cassandra 需要更多时间来启动，因为提交日志会变大（当 memtable 刷新到 SSTable 时它会被删除）
非常重要：使用单独的磁盘存储数据和提交日志。您可以使用 SSD 存储数据。它对提交日志毫无意义，因为它是顺序写入。
将复制因子更改为 1 将减少集群中的负载，因为每个节点都必须处理其数据而不是额外的副本，但您可能会丢失数据 - 我不建议这样做。

这可能有助于更好地理解：

http://maciej-miklas.blogspot.de/2012/09/cassanrda-tuning-for-frequent-column.html

http://maciej-miklas.blogspot.de/2012/08/cassandra-11-reading-and-writing-from.html

【讨论】：

【解决方案2】：

除了 Maciej 的优点之外，我还要补充一点，使用批处理批量加载正常写入是一种反模式。它的主要作用是使您的工作量更加“突发”，这很糟糕。仅当您需要一起完成写入以保持一致性时才使用批处理。

对于批量加载，请考虑在源中对它们进行批处理并使用 sstableloader，但我不建议在 ~100M 行级别之前投入这些精力。

【讨论】：

bursty 是什么意思，能解释一下为什么是这种反模式吗？是逐个写比批量快还是有其他后果？目前我们还没有全部 10M 行，它们实际上是按 1000 分批来找我们的（为了简单起见，我忽略了客户端和我们之间的层）

【解决方案3】：

您真的需要批处理吗？更新是否依赖于前一行的状态？如果不是，那么我不建议进行批处理，因为批处理请求会发送到一个节点，并且协调节点必须做更多的工作才能根据其分区键将请求发送到其他节点。当您知道所有批处理只有一个分区键时，批处理很有用。现在，如果您将每个请求分开，负载也会得到更多分布，写入吞吐量也会增加。如果您想更详细地了解批处理，请查看以下链接： https://lostechies.com/ryansvihla/2014/08/28/cassandra-batch-loading-without-the-batch-keyword/

【讨论】：

【解决方案4】：

Cassandra 是一个日志结构的数据库。因此，无论是更新还是新写入，它的行为都是相同的。如果一致性不是很关键，您可以将写入一致性级别设置为 1。这应该会有所帮助。并且，您使用的是 CQL 还是 Thrift。如果您使用 thrift，它是同步的，这意味着每个客户端线程将在一个请求上被阻塞。使用更多的客户端线程。

【讨论】：

写入总是发送到所有副本，因此 CL 对写入吞吐量几乎没有影响——仅对可用性/一致性有影响。
我的意思是指出，带有一个的 CL 将只等待一个响应，即使它必须向所有副本发送请求。因此，客户端不必长时间阻塞。