给定的 cassandra 模式的优缺点

Pros and cons of given cassandra schema

我有这个架构来将 post 及其注释一起存储在同一个 table:

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

我正在使用此架构,因此我只需访问一个 table 即可获得 post 及其评论。这种模式的优缺点是什么?

真的很好,如果你能弄清楚如何填写 ID 字段,就会工作。

我认为 type_comment 中的 comment_idid 是多余的。可以用 content.

替换整个 comments

我个人会用时间 uuid 替换 post_id,因为 Cassandra 中没有自动递增的事物 ID。在分布式环境中自动递增全局唯一标识符很困难。有一些事情可以为你做,但实际上,只使用时间 uuid/random 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" 将 year/month 替换为 iso 时间字符串,如“2016-01-01 00:00:00”,这比更改分桶更容易(即月、日等)。