數據建模（二級索引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集羣密鑰）

回答

相關問題