我使用Cassandra收集时间序列测量值。为了启用良好的分区，在 device-id 旁边，我添加了从UTC开始的日期和基于书面测量创建的存储桶 。时间将添加为群集密钥。最终密钥可以写成
（（device-id，从UTC开始的日期，存储桶），measurement-uuid）
在大多数情况下，针对此架构的查询使用 IN device-id 和 day-from-UTC-beginning 的整行>对于水桶。由于此查询架构Leveled Compaction看起来像一个完美的匹配，因为它很可能确保一个SSTable持有一行。 当附加到表时被禁用，运行增量修复很好。有一次，修复是在写压力下运行的，涉及到很多流。看起来流式传输的数据比上次修复后的数据要多。
我尝试过使用多个表，每天一个。当一天结束并且没有进一步写入给定表时，修复运行顺利。我知道thousands of tables overhead虽然它看起来只是一个可行的解决方案。
在重写场景下，将Leveled Compaction与增量修复相结合的正确方法是什么？
答案 0 :(得分：0)
当你有大量的工作量时，水平压缩不是一个好主意。当读取延迟很重要时，对于读/写混合工作负载更好。此外，如果您的群集已经按下了I / O，那么切换到水平压缩几乎肯定会使问题恶化。所以确保你有SSD。 此时，大小分层是写入繁重工作负载的更好选择。尽管如此，2.1中有一些改进。