Question

我有一张通知表：

CREATE TABLE notifications (
  id timeuuid,
  created timestamp,
  to_user_id timeuuid,
  status varchar,
  msg text,
  PRIMARY KEY ((to_user_id,status),created)
) WITH CLUSTERING ORDER BY (created DESC);

如上所示配置，因为我的第一个任务是拉取收件人（“to_user_id”字段）和所需的通知状态。此外，我正在制作最后N个记录，这就是使用聚类顺序的原因。这很好。

但是，我遇到了第二项任务的问题：更新通知状态。如果我将尝试更新“状态”列，它（显然）会抛出一个错误，即在集合中找到Pk部件状态。

行。考虑到我的用例应该遵循请求，我想到有2个表，第二个看起来像

CREATE TABLE notifications_by_id (
  id timeuuid,
  created timestamp,
  to_user_id timeuuid,
  status varchar,
  msg text,
  PRIMARY KEY (id)
);

但是我们在这里遇到了另一个问题 - 我的主表是第一个并且要更新它我需要“to_user_id”和“status”，它们不是唯一的，在更新请求期间不可用...

请告知“最佳做法”。对于某些上下文 - 您可以将此notifications表视为消息队列，不带acks / nack，消息具有属性，并且能够按“to_user_id”和“status”字段排序。

谢谢！ d。

Answer 1

您需要一个具有更精确主键的表。一旦到位，您可以在主键上执行更新/插入（每个都是Cassandra中的UPSERT）以进行状态更新。

下表包含分区键user_id和status以及GROUPING列created。这种用于分区数据的特定设置在面向用户的表格中更有利，而不是通知。为什么？这将有助于回答“给定用户的给定状态的通知是什么？”的问题。如果通知对象可以通过给定用户的操作之外的某些内容进行更新，则通知应具有status属性。

  CREATE TABLE notifications (
  id timeuuid,
  created timestamp,
  to_user_id timeuuid,
  status varchar,
  msg text,
  --OLD LINE PRIMARY KEY ((to_user_id,status),created)
  PRIMARY KEY ((id),created)
) WITH CLUSTERING ORDER BY (created DESC);

可以创建用户ID通知状态的第二个表，并且两个表与BATCH语句保持同步。最佳做法是在服务器查询后命名表。 notifications_by_user将是第二个查询的适当表名。

如评论部分所述，如果您有兴趣调查Cassandra 3.0的物化视图功能，请查看此Datastax blog post。请注意，在生产中实施之前应了解它们。来自博文，

物化视图处理自动服务器端非规范化，消除了客户端处理这种非规范化的需要确保基础数据和视图数据之间的最终一致性。这个非规范化允许在每个视图中非常快速地查找数据使用正常的Cassandra读取路径。

希望这些信息可以帮助您更好地提供数据。

Answer 2

回答我自己的问题。

我一直在绊倒那个＆＃34;状态＆＃34;我需要两个字段 - 限制它并能够更新它，所以我决定如果我试图从我的等式中删除一个未知数。

新范例实际上是模仿消息查询系统：而不是＆＃34; status＆＃34;专栏，我创建了3个表，即＃34;队列＆＃34 ;: notifications_pending，notifications_ignored，notifications_accepted。事实上，我并不需要阅读一组混合的通知。相反，每个请求只有一个状态。也许我的rdbms习惯提出了作为专栏的状态。

行。随着＆＃34;状态＆＃34;在我的方式，我们有以下模型：

3个表，其中notifications_pending用作队列，其他表 - 更像是档案。
我的状态更新操作现在是两个步骤的组合：从＆＃34;待定＆＃34;表并根据事件类型（接受或忽略）插入所需的特定于状态的表。
所有列均使用集群顺序desc

请分享您的想法！

P.S。当然，一些新问题似乎与前者相似。消息之后的墓碑＆＃34;重新定位＆＃34;，但那是def。单独处理。

需要帮助为Cassandra配置类似MQ的表

2 个答案: