集群顺序不适用于复合分区键答案

【问题标题】：Clustering order does not work with compound partition key集群顺序不适用于复合分区键
【发布时间】：2018-02-28 17:04:14
【问题描述】：

有如下表定义：

CREATE TABLE device_by_create_date (
    year int,
    comm_nr text,
    created_at timestamp,
    PRIMARY KEY ((year, comm_nr), created_at)
) WITH CLUSTERING ORDER BY (created_at DESC)

Comm_nr 是唯一标识符。

我希望看到按created_at 列排序的数据，但添加数据时并非如此。

示例条目：

表 CQL：

如何发出select * from table; 查询，返回按created_at 行排序的数据？

【问题讨论】：

标签： sorting cassandra cassandra-3.0 compound-key

【解决方案1】：

TLDR：您需要创建一个新表。

您的分区键是(year, comm_nr)。 You're created_at 键是有序的，但它是在该分区键内订购的。 SELECT * FROM table WHERE year=x AND comm_nr=y; 将按 created_at 排序的查询。

此外，如果您的键不是(year, comm_nr), created_at，而是year, comm_r, created_at，即使您的创建表语法仅将created_at 指定为具有集群顺序，它也会被创建为WITH CLUSTERING ORDER BY (comm_nr DESC, created_at DESC)。数据在 SSTables 中按键从左到右排序。

以真正的 nosql 方式执行此操作的方法是创建一个单独的表，其中您的键是 year, created_at, comm_nr。您会在创建用户时同时写信给两者，但如果您需要知道谁首先创建了他们的帐户的答案，您将改为查询新表。

【讨论】：

谢谢！假设我想显示 2017 年和 2018 年的所有设备。在这种情况下，我会发出 2 个查询 - 分页结果怎么样？ PagingState 仅适用于每个 ResultSet。自定义实现？
您应该能够摆脱SELECT * FROM table WHERE year IN (2017, 2018) ... 这将是来自应用程序端的“1 个查询”，并且应该以这种方式排序。理解虽然 1 查询在尝试实现一致性时会命中 <Consistency>*<Number of Partition Keys> 节点。因此，您的集群将比常规查询做更多的工作。
没错，但不鼓励使用 IN 吗？
或者，您可以改为在应用层中进行排序的协调（自定义实现），因为通常应用层将比数据层更好地扩展。由于上述缩放问题，不鼓励IN。您在协调器节点（内存压力和网络）上投入了更多工作，并且您通过一次查询访问了更多集群。