实时数据的Cassandra数据建模

Question

我目前有一个应用程序，它将事件驱动的实时流数据持久化到一个列系列，该系列建模为：

CREATE TABLE current_data (
    account_id text, 
    value text,
    PRIMARY KEY (account_id)
)

每个帐户ID每X秒发送一次数据，因此我们每次收到事件时都会覆盖现有行。此数据包含当前实时信息，我们只关心最近的事件（不使用旧数据，这就是我们插入已经存在的键的原因）。从应用程序用户端-我们通过account_id语句查询选择。

我想知道是否有更好的方法来模拟这种行为，并查看了Cassandra的最佳实践和类似的问题(如何为时间序列、服务器指标模拟Cassandra DB)。

想过这样的事情：

CREATE TABLE current_data_2 (
        account_id text, 
        time timeuuid,      
        value text,
        PRIMARY KEY (account_id, time) WITH CLUSTERING ORDER BY (time DESC)
)

不会发生覆盖，每次插入也将使用TTL（可以是几分钟的TTL）完成。

问题是，第二个数据模型比第一个数据模型有多好，如果有的话。据我了解，主要优势将在于 READS - 由于数据是按时间排序的，我需要做的就是一个简单的

SELECT * FROM metrics WHERE account_id = <id> LIMIT 1

而在第一个数据模型中，Cassandra实际上读取了覆盖同一个键的所有行，然后根据其写入时间戳选择最后一行（如果我错了，请纠正我）。

谢谢你。

Answer 1

首先，我鼓励您查看有关阅读路径的官方留档。

数据按时间排序

只有在第二种情况下，当Cassandra读取单个SSTable和MemTable时，这种情况才成立(查看流程图)。

Cassandra 实际上读取覆盖相同键的所有行，然后通过其写入时间戳选择最后一行

这发生在留档中的按时间戳合并单元格步骤（再次检查流程图）。请注意，在每个SSTable中，第一种情况下的行数将是一个。

在这两种情况下，主要的驱动因素是在读取过程中需要检查多少个SSTable。它在某种程度上独立于每个SSTable包含多少记录。

但是在第二种情况下，您有更大的SSTabes，这会导致更长的SSTable压缩。TTL过期还会执行额外的写入。所以第一种情况更可取。