如何正确设置 cassandra 事件存储表结构答案

【问题标题】：How to setup cassandra event store table structure correctly如何正确设置 cassandra 事件存储表结构
【发布时间】：2020-03-08 02:07:20
【问题描述】：

我是 Cassandra 数据库的初学者。我准备了事件存储表的示例，如下所示：

CREATE TABLE IF NOT EXISTS eventstore.Event(
                                Id uuid, 
                                Data text, 
                                Version int,
                                AggregateId uuid,
                                EventIdentity uuid,
                                Date timestamp,
                                  PRIMARY KEY (AggregateId, Version)
                                ) WITH CLUSTERING ORDER BY (Version ASC)

地点：

Id -> 每个事件的唯一 GUID

数据 -> JSON 事件数据

版本 -> 事件版本的 int 值

AggregateId -> 命名为 Aggregate 的 ID

EventIdentity -> 事件类型 ID

日期 -> 事件发生时的时间戳

我不确定我的主键是否正确（AggregateId，Version）以及按版本进行聚类。我想知道我的表是否会正确分区。按 AggregateId 分区，其中包含按版本排序的此聚合的所有事件。

【问题讨论】：

在 Cassandra 中，一切都取决于您计划对该表执行的查询。您能用查询示例更新您的问题吗？

标签： cassandra cql event-sourcing

【解决方案1】：

按 AggregateId 分区，其中包含按版本排序的此聚合的所有事件。

如果这是您的分区目标，那么您已经正确配置了 PRIMARY KEY。我要做的唯一补充就是围绕这个声明：

Id -> 每个事件的唯一 GUID

如果您真的想确保唯一性（并且如果聚合事件可能共享版本），我会将您的 ID 添加到 PRIMARY KEY 定义的末尾：

PRIMARY KEY (AggregateId, Version, Id)

两个后续问题：

1) 您预期的查询模式是什么？如果您的WHERE 子句中始终包含AggregateId 和/或Version，那么您应该没问题。如果不是，您可能需要重新考虑 PK 定义。

2)AggregateId:Version的比例是多少？您需要确保分区不会受到无限增长，并注意 Cassandra 的 20 亿个单元格/分区限制。

但总体而言，您似乎走在了正确的轨道上。

【讨论】：