数据建模（二级索引vs集群密钥）

我想了解如果我选择选项1：非常高的唯一值列作为分区键（order_id），并在store_id上创建索引和状态。（我可以在ORDER_ID查询| STORE_ID |状态|双方店&状态，也***基于ORDER_ID更新（重要的）状态）数据建模（二级索引vs集群密钥）

选项2： STORE_ID作为partition_key和非常高的独特的价值列作为聚集键（ORDER_ID）和状态创建二级索引（这样我可以在状态过滤）（我可以STORE_ID查询|商店& ORDER_ID |商店&状态|也是**基于商店& ORDER_ID更新状态）

我想知道上述情况下的性能问题。哪一个会是更好的选择。非常感谢您的帮助和时间。

来源

2015-06-23 john cena

选项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';

读为快，分区键限制了我们对执行查询节点的数量。

来源

2015-06-23 23:04:45

数据建模（二级索引vs集群密钥）

回答

相关问题