我正在尝试确定Cassandra对我的应用程序的适用程度，因为不知道我们将来需要扩展多少并且可能会迅速发生。我一直在关注2013年C *峰会的各个部分。
具体来说，Spotify的后端开发人员Axel Liljencrantz，says here如果您的模型要求您反复更新同一行，您可以预期Cassandra性能会随着时间的推移而降低。
我的模型要求是一种具有已知字段的“文档存储”类型，其值会在几个月内发生变化，因为它符合各种实际要求/状态点。需要在存储的各种文档中执行各种查询和计数。
那么：是否有任何合适的方法来缓解这种情况，如果所有文件在保持固定状态之前通常具有相同的已知平均寿命，那么历史数据呢？
通过存储版本号并在信息更新时将整个文档重写为新行，是否构思错误？
答案 0 :(得分：6)
如果您的模型要求您反复更新同一行 ，那么Cassandra性能会随着时间的推移而降低
- ＆GT;这是因为同一行跨越了十几个SSTables（SizeTiered Compaction）。 Cassandra中有新的Leveled Compaction可以缓解它，更多信息 here
我的模型要求是一种具有已知字段的“文档存储”类型，其值会在几个月内发生变化，因为它符合各种实际要求/状态点。
如果您的文档有“已知字段”，那么每个表将有固定数量的“列”。虽然更新频繁，但这不是问题（前提是你选择了如上所述的Leveled Compaction）因为它不是“扩展”
如果所有文件在保持固定之前通常具有相同的已知平均寿命
如果您的文档在最终版本和不可变版本之前几个月频繁更改，则可以先将它们存储在已配置的列族中，以支持频繁更新。在它们成为最终版之后，将它们移动到另一个配置为稳定且读取效率的列族