我正在尝试确定 Cassandra 是否适合我的应用程序，因为不知道我们将来需要扩展多少并且可能会迅速发生。我一直在观看 2013 年 C* 峰会的各个部分。
具体来说，Spotify 的后端开发人员 Axel Liljencrantz 在这里表示，如果您的模型需要您一遍又一遍地更新同一行，您可以预期 Cassandra 的性能会随着时间的推移而下降。
我的模型要求是一种具有已知字段的“文档存储”类型，其值会在几个月内发生变化，因为它满足各种现实生活要求/状态点。需要跨存储的不同类型的文档执行各种查询和计数。
那么：如果所有文档在保持固定的历史数据之前通常具有相同的已知平均寿命，是否有任何合适的方法来缓解这种情况？
通过存储版本号并在信息更新时将整个文档重写到新行来解决此问题是否不明智？
如果您的模型要求您一遍又一遍地更新同一行，您可以预期 Cassandra 的性能会随着时间的推移而下降
--> 这是因为同一行跨越了十几个 SSTables（SizeTiered Compaction）。Cassandra 中提供了新的 Leveled Compaction 可以缓解它，更多信息在这里
我的模型要求是一种具有已知字段的“文档存储”类型，其值会在几个月内发生变化，因为它满足各种现实生活要求/状态点。
如果您的文档有“已知字段”，那么每个表格将有固定数量的“列”。尽管更新很频繁，但这不是问题（前提是您如上所述选择了Leveled Compaction），因为它不是“widerow”
如果所有文档在保持固定之前通常具有相同的已知平均寿命
如果您的文档在最终版本和不可变版本之前几个月经常更改，您可以首先将它们存储在配置为支持频繁更新的列族中。在它们成为最终版本后，将它们移动到另一个配置为稳定且读取效率高的列族