在DSE 5.0.5（Cassandra 3.0.11）中，哪些设置会减少后台持续写入的读取延迟？

Question

我们有一个5节点DSE cassandra集群和一个应用程序，其作用是异步写入密钥空间A（基于HDD），并从密钥空间B（位于SSD上）同步读取。从表中读取

其他信息：

• A上的表使用TWCS，窗口为48h，而键空间B上的表使用LCS，默认设置为
• Spark作业分区最多读取20h的块
• 两个表都使用带有AES256密钥和1KB块的TDE
• 除了堆大小和GC日志记录之外，Azul Zing还被用作JVM的默认设置

仅使用此方案，键空间B的读取延迟在一天中都很好，但是每天我们都有一个将从键空间A读取并写入B的spark作业。当火花执行器“攻击”键空间A时，读取延迟从键空间B受到一点影响（第99个百分点从8-12ms到130ms几秒钟）。

我的问题是，哪个cassandra.yaml属性可能最有助于减少键空间B上的读取延迟，就在此刻火花作业开始？我一直在尝试不同的memtable / commitlog设置，但是无法将读取延迟降低到可接受的水平

Answer 1

如果我们可以将这些默认值烘焙到数据库中，那么很难在不知道为什么延迟会受到伤害的情况下进行概括

但是，我会尝试猜测

• 降低并发读取的速度，以减少并发请求 - 这将在整个过程中进行交易以获得更一致的性能

• 如果磁盘正忙，请考虑较小的压缩块大小

• 如果您看到GC暂停，请考虑调整您的jvm - Cassandra-8150 jira有一些很好的建议

• 如果您的sstables-per-read超过几个，请重新考虑您的数据模型，以防止您的分区跨越多个TWCS窗口

• 确保您的密钥缓存已启用。如果你可以节省堆，提高它，它可能会有所帮助。

Answer 2

杰夫的答案应该是你的出发点，但如果这还没有解决，请考虑将你的火花工作改为非高峰时间。请记住，LCS针对重读表进行了优化，但从火花开始到＃34;迁移＆＃34;数据，即使用LCS的表，将在一段时间内（直到spark作业完成）成为一个写入繁重的表。这将是LCS利用的反模式。我无法查看服务器详细信息，但我会说，由于在spark工作期间创建了大量SSTable，LCS无法跟上压缩以维持标准读取等待时间。

如果您无法在非高峰时间安排火花作业，那么您应该考虑将键空间B中的压缩策略更改为STCS。