長所と与えられたカサンドラスキーマの短所

Question

私は同じテーブルで一緒にpostとそのコメントを保存するには、このスキーマ持っている：私は使用しています

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 

ここ

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とそのコメントを得るために1つのテーブルにアクセスする必要があります。このスキーマの賛否は&ですか？

Answer 1

実際にはうまくいき、idフィールドの記入方法を理解できればうまくいくはずです。

comment_idとidはtype_commentだと思います。 comments列全体をcontentに置き換えることができます。

個人的に私はカスンドラに自動インクリメントのものがないので、私はpost_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"は年/月を "2016-01-01 00:00:00"のようなiso時間文字列で置き換えることができます。バケッティングを簡単に変更できるよりも簡単です（月、日など）。