Cassandra修复-在启用分级压缩的增量修复情况下，大量流式处理
我使用Cassandra收集时间序列测量值。为了实现良好的分区，除了设备id之外，我还添加了从UTC开始的日期和基于书面度量创建的bucket。时间作为集群键添加。最后一个键可以写为 （（设备id，从UTC开始的日期，桶），测量uuid） 在大多数情况下，针对此架构的查询会从UTC开始使用in for bucket时，获取具有给定设备id和日期的整行。因为这个查询模式看起来像是一个完美的匹配，因为它极有可能确保一行由一个SSTable持有。 当附加到表被禁用时，运行增量修复是正常的。一旦修复在写入压力下运行，就会涉及大量流。看起来流式传输的数据比上次修复后追加的数据多 我试过使用多张桌子，每天一张。当一天结束，并且没有对给定的表进行进一步写入时，修复运行顺利。我知道，尽管看起来这是唯一可行的解决方案Cassandra修复-在启用分级压缩的增量修复情况下，大量流式处理,cassandra,Cassandra,我使用Cassandra收集时间序列测量值。为了实现良好的分区，除了设备id之外，我还添加了从UTC开始的日期和基于书面度量创建的bucket。时间作为集群键添加。最后一个键可以写为 （（设备id，从UTC开始的日期，桶），测量uuid） 在大多数情况下，针对此架构的查询会从UTC开始使用in for bucket时，获取具有给定设备id和日期的整行。因为这个查询模式看起来像是一个完美的匹配，因为它极有可能确保一行由一个SSTable持有。 当附加到表被禁用时，运行增量修复是正常的。一旦修复在写
在写操作繁重的情况下，将分级压缩与增量修复结合起来的正确方法是什么？在写操作繁重的情况下，分级压缩不是一个好主意。当读延迟很重要时，读/写混合工作负载更好。此外，如果您的集群已经面临I/O压力，那么切换到分级压缩几乎肯定只会使问题恶化。因此，请确保您有SSD。
此时，对于写操作繁重的工作负载，大小分层是更好的选择。不过，在2.1中对此有一些改进。正如我提到的，重读访问模式是扫描整行。我测试了分层压缩的大小，它带来了大量开销。移动到Leveled使读取延迟降至我的场景所需的最小值。据我所知，光碟IO不是问题所在，我已经安装了JBOD，它可以很好地处理压力。问题是，当键空间处于写入压力下时，为什么在修复过程中会出现如此多的流？这是与压实相关的事情吗？