【问题标题】:Cassandra best practice to overwrite/update a row?Cassandra 覆盖/更新行的最佳实践?
【发布时间】:2017-08-07 04:01:57
【问题描述】:

我们计划使用 Cassandra 3.1 作为我们的数据存储。数据模型将使用 user_uuid 作为分区键/主键,没有集群键。查询模式是访问特定用户的 user_uuid 并使用各种数据更新该行。目的不是简单地添加更多列,而是完全覆盖值/列,例如。时间戳、版本和用户的其他各个方面。预计每天将有大约一百万个不同的用户写入,每个用户每天可能会写入数千次。

这是将 Cassandra 用作数据存储的有效方式吗?通过研究,我了解到在 Cassandra 中更新一行不会创建墓碑,而是会创建“阴影”,当 SSTable 被压缩时会被移除。

如果它不创建墓碑,那么这是为特定用户存储数据的一种安全有效的方式吗?

【问题讨论】:

  • “每天大约有 100 万个不同的用户写入,每个用户每天可以写入数千次”如果我们的一个应用程序团队来找我要求一个新的集群并说 那个,我的回答是,这对Cassandra来说不是一个好主意。
  • 感谢您的回复。特别是什么会让你说这不是一个好主意?
  • 我担心的是,经常更新值(10k/天 ea)会在下面创建如此多的过时数据,以至于您的分区会变得太大且笨拙。当然压缩会收回这一点,但是每天 10k 次就地更新列值实在是太多了。

标签: cassandra


【解决方案1】:

Cassandra 模型是一种仅追加模式 - 键+列对的每次更新或删除都保存为它的新版本,而不是就地更新 - 墓碑只是一个表示该行已被删除的版本。因此,即使使用墓碑也可以节省使用它:)。在读取时,Cassandra 将只返回此类键/值对的最新值。

数据保存在 sstables 中,当其中 2 个被压缩时,处理后只会保存这些表中每个键值对的最新数据。

Cassandra 确实可以满足您的负载要求,对于更新繁重的工作负载,我建议使用分级压缩策略 - 您可以在此处阅读:

http://www.datastax.com/dev/blog/when-to-use-leveled-compaction

关于写入路径:

https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_write_path_c.html

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-09-11
    • 2010-09-20
    • 2017-09-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-03-25
    • 2016-05-19
    相关资源
    最近更新 更多