绕过二级索引问题的 CQL 数据模型答案

【问题标题】：CQL data model to bypass secondary index issuee绕过二级索引问题的 CQL 数据模型
【发布时间】：2015-01-03 04:23:59
【问题描述】：

我的模型看起来像

StateChange: 
    row_id
    group_name
    timestamp
    user_id

我的目标查询如下：

查询 1 = 使用 row_id = X ORDER BY Timestamp DESC 查找所有状态更改查询 2 = 使用 row_id = X 和 group_name = Y ORDER BY Timestamp DESC 查找所有状态更改

使用我有限的 CQL 知识，这样做的唯一方法是为上述每个查询创建 2 个查询表

查询1：

CREATE TABLE state_change (
    row_id int,
    user_id int,
    group_name text,
    timestamp timestamp,
    PRIMARY KEY (row_id, timestamp)
)

查询2：

CREATE TABLE state_change_by_group_name (
    row_id int,
    user_id int,
    group_name text,
    timestamp timestamp,
    PRIMARY KEY ((row_id, group_name), timestamp)
)

这确实解决了问题，但我现在在 Cassandra 中复制了数据。

注意：在表上创建 group_name 索引是可行的，但我不能再按时间戳排序，因为它现在是二级索引。

寻找只需要一张桌子的解决方案。

【问题讨论】：

标签： database cassandra data-modeling cql

【解决方案1】：

您正在寻找的解决方案不存在。两个不同的查询需要两个不同的表（或至少一个在后台创建表的二级索引）。非规范化是 Cassandra 中的常态，因此您不应该将数据复制视为一种反模式——事实上这是建议的模式

【讨论】：

+1 表示“非规范化是 Cassandra 中的常态，因此您不应将数据复制视为反模式”

【解决方案2】：

Carlo 是正确的，因为您的多表解决方案是这里的正确方法。

这确实解决了问题，但我现在在 Cassandra 中复制了数据。

... 正在寻找只需要一张桌子的解决方案。

Planet Cassandra 最近发表了一篇关于此主题的文章：Escaping From Disco-Era Data Modeling

（完全披露：我是作者）

但最后两段确实说明了你的观点（尤其是最后一句话）：

这是一种非常 1970 年代的思维方式。关系数据库理论起源于磁盘空间昂贵的时候。 1975 年，一些供应商以惊人的一万一千美元出售磁盘空间每兆字节美元（取决于供应商和型号）。即使在 1980 年，如果你想购买一个千兆字节的存储空间，你仍然可以期望花费大约一百万美元。今天（2014 年），你可以花 60 美元购买一个 TB 驱动器。磁盘空间便宜；操作时间是昂贵的部分。和过度使用二级索引会增加你的操作时间。

因此，在 Cassandra 中，您应该采用基于查询的建模方法。本质上，（Patel，2014）为您的列族建模根据查询数据的意义。这是一个与建立表格的关系数据建模不同根据存储数据的意义。 通常基于查询建模导致存储冗余数据（有时数据不依赖于它的主行键）...没关系。

【讨论】：