给定 cassandra 模式的优缺点

Posted 2023-03-22

【中文标题】给定 cassandra 模式的优缺点

【英文标题】：Pros and cons of given cassandra schema

【发布时间】：2016-08-06 01:00:37

【问题描述】：

我有这个架构可以将 post 及其评论一起存储在同一个表中：

CREATE TABLE post ( 
  post_id int,
  access_key text,
  comment_id int,
  title text,
  comments FROZEN <type_comment>,
  PRIMARY KEY ((post_id, access_key), comment_id)
);

CREATE TYPE ks_test.type_comment (
  id int,
  content text
);

这是一个示例数据

post_id | access_key | comment_id | comments                 | title
---------+------------+------------+--------------------------+--------------
       1 | about_post |          1 |                     null | this is post
       1 |   comments |          2 | id: 2, content: 'cmn1' |         null
       1 |   comments |          3 | id: 3, content: 'cmn2' |         null
       1 |   comments |          4 | id: 4, content: 'cmn3' |         null

我正在使用此架构，因此我只需访问一个表即可获得post 及其注释。这种模式的优缺点是什么？

【参考方案1】：

真的很好，如果你能弄清楚如何填写 id 字段，那就可以了。

我认为type_comment 中的comment_id 和id 是多余的。可以用content 替换整个comments 列。

我个人会将 post_id 替换为时间 uuid，因为 Cassandra 中没有自动递增的事物 id。在分布式环境中自动递增全局唯一标识符很困难。有一些事情可以为你做，但实际上，只使用时间 uuid/随机 uuid 是最简单的。

CREATE TABLE post ( 
  post_id uuid,
  access_key text,
  comment_id timeuuid,
  title text,
  content text,
  PRIMARY KEY ((post_id, access_key), comment_id)
);

如果想按日期抓取它可以做类似的事情

CREATE TABLE post ( 
  year int,
  month int,
  access_key text,
  comment_id timeuuid,
  title text,
  content text,
  PRIMARY KEY ((access_key, year, month), comment_id)
);

然后您可以按月抓取，也可以使用范围在该月的时段内抓取。也可以制作一个“time_bucket”来将年/月替换为 iso 时间字符串，例如“2016-01-01 00:00:00”，这样您可以更轻松地更改分桶（即月、日等）。

【讨论】：

我想知道的是？正如您在输出中看到的那样，在某些行中会有null 列值，所以我的记录数会增加那些null 值也会增加。有问题吗？

只有分区/集群键需要设置（不提供其他的物化视图/索引），其他的不存在意味着更少的磁盘空间使用。

您认为这种模式方法的优缺点是什么？

PROs - 它可以很好地工作和分区数据。缺点 - 需要一些尴尬的 id 生成并且有一些冗余数据（但磁盘空间很便宜所以 meh）。

如果所有分区或集群键的值相同，有什么区别吗？