更新数据的cassandra压缩策略
cassandra compaction strategy for data which gets updated
我正在尝试为以下用例提出压缩策略。
我们 table 的 ttl 为 3 年。我们场景中的大部分数据将在插入后 1 个月内更新。
所以基本上所有对记录的更新都会在一个月内发生，平均在 2 周内发生。
可能会有一些异常值可能会在一个月后更新，但这种情况很少见。
现在我正在考虑使用 window 1 个月（或可能是 2 周）的 TWCS
我知道我们的用例不是完美的时间序列数据。但一个月后，大部分数据将永远不会收到更新，并将驻留在一个 sstable.
中
但是我不确定使用 window 1 个月的大小是否会有任何副作用。
此外，如果更新超出 window 大小（即一个月后），这会造成任何重大问题吗？
请告诉我上述情况的最佳策略是什么？
TWCS 可能是个不错的选择。但这取决于数据大小。如果您的数据量很大，您将在 1 个月后获得大量 sstables。我认为拥有 Weekly/Biweekly SStables 会更合理。
但这将我们带到下一个问题："What happens with out-of-order updates?"
问题是 sstable 不会被删除，即使它全部过期，因为另一个 sstable 中的数据 "shadow"。因此，文件在您的硬盘中停留的时间会比您预期的要长。此外，由于 TWCS 在 window 完成后压缩数据一次，因此您的数据将分布在多个 sstables 上并可能影响您的读取性能。
这里有 2 个选项：
- 从 TWCS 开始，看看进展如何，但了解其潜力
缺点。
- 从 STCS 开始，然后创建一个节点
write-survey mode, or change in a single node the compaction strategy via JMX.
如果你有一篇关于 TWCS、墓碑和阴影的优秀文章：http://thelastpickle.com/blog/2016/12/08/TWCS-part1.html
永远记住你以后可以改变你的压缩策略，这不是为了 "free" 或 "painless"，但可以做到。
我正在尝试为以下用例提出压缩策略。
我们 table 的 ttl 为 3 年。我们场景中的大部分数据将在插入后 1 个月内更新。
所以基本上所有对记录的更新都会在一个月内发生，平均在 2 周内发生。
可能会有一些异常值可能会在一个月后更新，但这种情况很少见。
现在我正在考虑使用 window 1 个月（或可能是 2 周）的 TWCS 我知道我们的用例不是完美的时间序列数据。但一个月后，大部分数据将永远不会收到更新，并将驻留在一个 sstable.
中但是我不确定使用 window 1 个月的大小是否会有任何副作用。
此外，如果更新超出 window 大小（即一个月后），这会造成任何重大问题吗？
请告诉我上述情况的最佳策略是什么？
TWCS 可能是个不错的选择。但这取决于数据大小。如果您的数据量很大，您将在 1 个月后获得大量 sstables。我认为拥有 Weekly/Biweekly SStables 会更合理。
但这将我们带到下一个问题："What happens with out-of-order updates?" 问题是 sstable 不会被删除，即使它全部过期，因为另一个 sstable 中的数据 "shadow"。因此，文件在您的硬盘中停留的时间会比您预期的要长。此外，由于 TWCS 在 window 完成后压缩数据一次，因此您的数据将分布在多个 sstables 上并可能影响您的读取性能。
这里有 2 个选项：
- 从 TWCS 开始，看看进展如何，但了解其潜力 缺点。
- 从 STCS 开始，然后创建一个节点 write-survey mode, or change in a single node the compaction strategy via JMX.
如果你有一篇关于 TWCS、墓碑和阴影的优秀文章：http://thelastpickle.com/blog/2016/12/08/TWCS-part1.html
永远记住你以后可以改变你的压缩策略，这不是为了 "free" 或 "painless"，但可以做到。