我正在尝试了解如果我选择这是否会成为性能问题 选项1： 非常高的唯一值列作为分区键 (order_id)，并在 store_id 和状态上创建索引。 （我可以查询 order_id | store_id | status | store&status 和 ***update(important) status based on order_id）
选项 2： store_id 作为 partition_key 和非常高的唯一值列作为集群键（ order_id ）并在状态上创建二级索引（以便我可以过滤状态） （我可以查询 store_id | store&order_id | store&status | 也可以**根据 store&order_id 更新状态）
我想知道在上述情况下会出现什么性能问题。哪一个会是更好的选择。非常感谢您的帮助和时间。
【问题讨论】：
选项 1 很有趣，但你需要小心你的索引。有关更多信息，请参阅您的other question（尤其是有关同时查询多个二级索引的部分）。 tables purpose built for your index lookups 可以缓解这种情况（下面将进一步讨论）。
高度唯一的分区键的优点是数据将更加分布在您的集群中。这里的缺点是，当您使用WHERE store_id = 'foo' 执行请求时，需要查询集群中的所有节点，因为分区键没有限制。
选项 2 你必须小心。如果您的分区键只是 store_id，那么每个订单都将放置在此分区中。对于每个订单，将有 n 列添加到商店的单行中，代表订单上的每个属性。关于数据位置，给定商店的所有订单都将放置在同一个 Cassandra 节点上。
在这两种情况下，为什么不按状态查找订单查找表呢？这将消除您对该字段的二级索引的需要。特别是考虑到它的基数相对较小。
CREATE TABLE orders_by_store_id_status (
store_id VARCHAR,
status VARCHAR,
order_id VARCHAR,
... <additional order fields needed to satisfy your query> ...
PRIMARY KEY ((store_id, status), order_id)
);
这将允许您查询具有给定 store_id 和状态的所有订单。
SELECT * FROM orders_by_store_id_status WHERE store_id = 'foo' AND status = 'open';
读取速度很快，因为分区键限制了我们对其执行查询的节点数量。
【讨论】：