代码之家  ›  专栏  ›  技术社区  ›  Manish Kumar

给定卡桑德拉模式的利弊

  •  0
  • Manish Kumar  · 技术社区  · 8 年前

    我有这个架构来存储 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
    

    我使用这个模式,所以我只需要访问一个表就可以得到 邮递 以及它的评论。什么样的优势&这个模式的缺点?

    1 回复  |  直到 8 年前
        1
  •  2
  •   Chris Lohfink    8 年前

    真的,这很好,如果你能弄清楚如何填写id字段的话,它会起作用。

    我认为 comment_id id 在里面 type_comment 是冗余的。可以替换整个 comments 带有的列 content .

    就我个人而言,我会用时间uuid替换post_id,因为Cassandra中没有自动递增的thing-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”,这样您可以更轻松地更改bucketing(即月、日等)。