频繁的Compaction和Memtable Flushing会不会影响集群的写延迟？
在我们的实现中，我们有一堆计数器列族 [about 30]，它们的更新非常活跃。对我们系统的每个请求都会进行大约 15-20 次更新[所有差异 CF]。
我们能够注意到在我们的 cassandra 系统日志中，在高流量时压缩和刷新非常频繁地发生。到那时，我们还经历了负责键 [Day Timestamp, Minute Timestamp, Hour Timestamp] 的节点上的高负载，并且集群的写入延迟比平时增加 [0.6 ms 到 26 ms]
我们没有触及 cassandra 的任何默认值，我们运行 cassandra 的机器具有足够好的配置[32G ram 和 16 核] 4G 到 cassandra
我们尝试禁用 durable_writes 以了解它是否有帮助，但它并没有像我们预期的那样好
最佳答案
简短版本:如果 Cassandra 按照建议配置，将 commitlog 放在与数据目录不同的磁盘上，那么刷新和压缩的影响应该可以忽略不计。
注意事项:
更新主要受 CPU 限制，压缩会占用大量 CPU。如果您在少于 4 个内核的机器或 VM 上运行 [不是您的情况，但为了完整起见]，您可能需要减少 compaction_throughput_mb_per_sec 以降低它。
如果您有足够多的 CF 同时刷新(这听起来可能是每次请求更新 2/3 的 CF 的情况)，那么 Cassandra 可能会暂时阻止写入以确保它不会更快地接受写入而不是它可以刷新它们(否则最终可能会导致内存不足和死亡)。对于跨多个 CF 的大容量插入，4 GB 是一个相对较小的堆；我建议将其增加到 8。启用 JVM GC 日志记录以查看 JVM 工作的难度也很值得——示例设置位于 cassandra-env.sh 中。
最后，您没有提及您正在使用的 Cassandra 版本，但每个主要版本的性能都得到了可靠的提高。特别是如果您使用的是 0.8 之前的版本，我建议您升级。
关于nosql - 压缩和刷新对 Cassandra 中写入延迟的影响，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8937515/