Question

我试图理解并熟悉cassandra数据模型。本文介绍了一些基本的建模规则：

https://www.ebayinc.com/stories/blogs/tech/cassandra-data-modeling-best-practices-part-1/

选项3显示了非规范化数据模型：

我是否正确行事，＆＃34; user_by_item＆＃34; table有以下结构吗？

CREATE TABLE "user_by_item" (
    item_id int,
    users list<User>
    PRIMARY KEY (item_id)
)

如果是：很明显我可以通过一个查询按item_id获取所有用户。但是当时无法翻阅用户列表。

我是否理解了表格结构的正确性以及如何管理项目列表，特别是如果它们变得非常大？

Answer 1

首先，那篇文章是6岁。在它的时间里，这是一篇很棒的文章，但从那以后，Cassandra已经重大。例如，Cassandra 1.1中没有收藏品，我认为是撰写本文时最新的版本。

我是否正确行事，＆＃34; user_by_item＆＃34; table有以下结构吗？

是的，我认为你理解它。在users_by_item上将item_id用作单个PRIMARY KEY，同时将用户存储为集合是您可以执行此操作的一种方式。但是，它限制了您的查询灵活性，可以立即撤回所有用户。

构建该查询表的查询友好方法可能是user_id上的群集密钥：

CREATE TABLE user_by_item (
  item_id int,
  user_id int,
  email text,
  name text,
  PRIMARY KEY ((item_id),user_id)
);

这样，我可以查询绑定到项目111的所有用户：

aploetz@cqlsh:stackoverflow> SELECT * FROM user_by_item WHERE item_id=111;

 item_id | user_id | email   | name
---------+---------+---------+------
     111 |     123 | jp@ebay |  Jay
     111 |     456 | jd@ebay | John

(2 rows)

如果我知道他的user_id：

，我也可以查询周杰伦

aploetz@cqlsh:stackoverflow> SELECT * FROM user_by_item WHERE item_id=111
                               AND user_id=123;

 item_id | user_id | email   | name
---------+---------+---------+------
     111 |     123 | jp@ebay |  Jay

(1 rows)

这为我提供了更多的查询灵活性，同时还按item_id存储了所有用户数据。

专业提示：

除非必须，否则不要用双引号将表名封装起来。它迫使Cassandra维持其案例，但可以使数据检索在以后成为令人沮丧的经历。
在为Cassandra建模时，通常的做法是使用自然键，如name =＆＃34; Jay。＆＃34;像_id这样的代理键的重点在于，可以从主表中引用某些内容，而不会在每次需要/存储时将其拼写错误。在Cassandra，我们没有像外键那样的东西，所以自然键可以帮助你剪掉一些不必要的列。
Cassandra中的主键无法更改。因此，上述规则的例外情况是，如果预测主键值会发生变化（例如，Jay合法地更改了他的name），那么使用代理键会成为一个好主意。

Cassandra：非规范化和分页

1 个答案: