数据建模(二级索引与聚类关键字)



我正在努力了解如果我选择选项1:非常高的唯一值列作为分区键(order_id),并在store_id和status上创建索引。(我可以查询order_id|store_id|status|store&status,也可以***基于order_id更新(重要)状态)

选项2:store_id作为partition_key,非常高的唯一值列作为集群键(order_id),并创建状态的辅助索引(这样我就可以根据状态进行筛选)(我可以查询store_id|store&order_id|store&status|,也可以**基于store&order_id更新状态)

我想知道在上述场景中会出现什么性能问题。哪一个将是更好的选择。非常感谢你的帮助和时间。

选项1很有趣,但您需要小心索引。有关更多信息,请参阅您的另一个问题(尤其是关于同时查询多个二级索引的问题)。通过专门为索引查找构建的表(下面将进一步讨论),这种情况可能会得到缓解。

高度唯一的分区键的优点是,数据将在集群中更加分散。这里的缺点是,当您使用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';

读取速度很快,因为分区键限制了我们执行查询的节点数量。

最新更新