Cassandra 性能随时间更新行 [英] Cassandra performance updating rows over time

问题描述

我正在尝试确定 Cassandra 对我的应用程序的合适程度，因为不知道我们将来需要扩展多少并且可能会很快发生.我一直在观看 2013 年 C* 峰会的各个部分.

I am trying to determine how suitable Cassandra is for my application, as it is unknown how much we will need to scale in the future and could occur rapidly. I have been watching various segments of the C* Summit 2013.

具体来说，Axel Liljencrantz，Spotify 后端开发人员，在这里说，如果您的模型要求您一遍又一遍地更新同一行，您可以预期 Cassandra 性能会随着时间的推移而降低.

Specifically, Axel Liljencrantz, Backend Developer at Spotify, says here that you can expect Cassandra performance to degrade over time if your model requires you to update the same row over and over.

我的模型要求是一种具有已知字段的文档存储"类型，其值会在几个月内发生变化，因为它满足各种现实生活中的要求/状态点.需要对存储的不同类型的文档执行各种查询和计数.

My model requirement is a "document store" kind of type with known fields, with values that change over a number of months, as it meets various real-life requirements/status points. Various queries and counts need to be performed across different kinds of documents stored.

那么:如果所有文档在保持固定的历史数据之前通常具有相同的已知平均生命周期，那么是否有任何合适的方法来缓解这种情况?

So: Are there any suitable ways to mitigate this, if all documents have typically the same known average life-time before they remained fixed, historical data?

通过存储版本号并在信息更新时将整个文档重写为新行来解决此问题是否不妥当?

Is it ill-conceived to work around this by storing a version number and rewriting the whole document to a new row as information is updated?

推荐答案

如果您的模型要求您一遍又一遍地更新同一行，您可以预期 Cassandra 的性能会随着时间的推移而降低

-->这是因为同一行跨越了十几个 SSTable(SizeTiered Compaction).Cassandra 中有新的 Leveled Compaction 可以缓解它，更多信息 这里

--> It's due to the fact that the same row spans over dozen of SSTables (SizeTiered Compaction). There is the new Leveled Compaction available in Cassandra that can mitigate it, more info here

我的模型要求是文档存储"一种具有已知字段的类型，其值会在几个月内发生变化，因为它满足各种实际需求/状态点.

如果您的文档具有已知字段"，那么将有固定数量的列"；每桌.尽管更新很频繁，但它不是问题(前提是您选择了上面提到的 Leveled Compaction)，因为它不是widerow"

If your document has "known fields", so there will be a fixed amount of "columns" per table. Although the update is frequent it's not a problem (provided that you choose Leveled Compaction as mentioned above) since is is not a "widerow"

如果所有文档在保持固定之前通常具有相同的已知平均生命周期

如果您的文档在最终和不可变版本之前几个月频繁更改，您可以先将它们存储在列族配置中以支持频繁更新.在它们成为 final 后，将它们移到另一个配置为稳定且读取效率高的列族

If your documents change very frequently a couple of months before their final and immutable version, you can store them first in a column family configured to support frequent updates. After they become final, move them to another column family configured to be stable and read-efficient

这篇关于Cassandra 性能随时间更新行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！