cassandra 2.0.9：重写列的最佳实践答案

【问题标题】：cassandra 2.0.9: best practices for write-heavy columnscassandra 2.0.9：重写列的最佳实践
【发布时间】：2014-07-24 04:13:11
【问题描述】：

我对 Cassandra 中的集群感到有些困惑。我有一个非常重写入和重更新的应用程序。对于传统的关系数据库，我会将数据划分为两个表：一个表用于不经常更改的数据；另一个表用于存储不经常更改的数据。和一个表（行较短）用于频繁更改的列：

例如：

create table user_def ( id int primary key, email list< varchar > ); # stable
create table user_var ( id int primary key, state int ); # changes all the time

但 Cassandra 似乎针对访问稀疏的列进行了优化，所以我不确定在 Cassandra 模式中模仿这种方法是否有任何优势。

使用 Cassandra，将经常更新的列分离到单独的表/列族（远离不经常更新的列）是否有任何优势，或者我应该将所有列组合到一个表/列族中？如果我有一个复合主键并且集群开始发挥作用，情况会改变吗？

【问题讨论】：

标签： database-schema cassandra-2.0

【解决方案1】：

Cassandra 是这样处理主键的：

主键中的第一个键（可以是复合键）用于分区您的数据。这定义了您的数据保存在（并复制到）哪个节点。然后使用主键中的其他字段对分区中的条目进行排序。整个分区将始终位于一个节点（和副本节点）中。此外，节点中的每个条目都按主键中的“其他”字段排序。 [主键的第一个元素称为分区键，而主键中的其他字段称为聚类键。]

基于此，我想说您不妨简单地拥有一个包含 id、state 和 email 的表格。看起来您正在使用瘦行，我认为您不会获得任何（如果有的话）创建单独的表。

【讨论】：

【解决方案2】：

我已经批准了 ashic 的回答，直到我发现这个： http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

哪些状态（对于重度删除访问）：

...考虑将具有高流失率的数据划分为单独的行，并在不再需要时删除整行。或者，将其分区到单独的表中，并在不再需要时截断它们......

这属于产品的“队列”反模式。

【讨论】：