Cassandraの正規化

Question

Cassandraの正規化は反パターンと見なされますが、それが意味する記憶要件が高すぎるとすれば何ができるのでしょうか？例えば

、我々は現在、多くの受信者に配布される「フィード」の大きなテーブルを持っているので、現在のスキーマがそのようなものです：このスキーマでは

CREATE TABLE feed_items_duplicated(recipient_id int, feed_id timeuuid, 
    <data columns d1 to dn> 
    PRIMARY KEY ((recipient_id), feed_id); 

すべてがいいですし、フィードがありますフィードID上に単一範囲クエリを使用して、単一の受信者のために容易に取り込まれた：

SELECT * from feed_items_duplicated where recipient_id = 123 
    and feed_id > minTimeuuid('2013-09-30 22:19:06+0100'); 

問題は、単一のフィードが受信者の数百に分配することができ、各行はDNに列D1と非常に大規模であることができるということです1つ1つに複製そのうちの。

SELECT * from feed_data where feed_id in (f1, f2, f3...); 

だから質問1：

は、ストレージ要件が含まれているために、私たちは別のオプションこれはまだその後の追加のクエリ実行して上記のクエリを実行している必要となる

CREATE TABLE feed_items(recipient_id int, feed_id timeuuid, 
    PRIMARY KEY ((recipient_id), feed_id); 
CREATE TABLE feed_data(feed_id timeuuid, <data columns d1 to dn> 
    PRIMARY KEY (feed_id); 

と考えられていますクラスタ内のすべてのノードに当てはまる可能性が高いため、上記のクエリを実行することをお勧めします。どのf1からfnまでの専用クエリを並行して実行するのと比較してどれほど悪いですか？

もう1つの方法は、feed_dataテーブルに対してわずかな制限範囲（[1-20]と言う）内に任意のクラスタリングキーを作成して、実行する次のタイプのクエリを最大20個しか持たないようにすることです：

このアプローチでは、すべてのクエリが1つの実行ノードに制限されますが、そのようなカーディナリティパーティションキーが低いと、データがノード間で均等に分散されることを保証できますか？

Answer 1

質問1：可能であれば、アクセス時間の劣化が受信者に許容されるかどうか試してみる価値があります。 DataStaxとother nice guysからのCQLクエリの 'in'句に関する推奨事項と警告が多数あります。 'in'クエリの代わりに、私はむしろ​​を考えたいと思います。

質問2：あなたのデータ列[d1 ... dn]が小さくて、劇的に変化しないなら、それは問題ではないと思います。データ再利用の可能性があるのであれば、データアイテムのグループ化は良い考えだと思います。 Feed1 = bundle1 + bundle2、feed2 = bundle1 + bundle3など、ここでbundle1 = data-item1 + data-item2、bundle2 = data-item3などのようにフィードデータを整理できます。

自分自身から：データ構造の最適化戦略があれば、フィードデータに何らかのエビクションポリシーを導入する価値はあるでしょうか？ TTLやその他のようなもの。 "リアルタイム"テーブルをそのまま残し、不要なデータをより効率的なストレージに移動したり、削除したりすることもできます。