虛擬分區鍵總是不好？

Question

我無法在卡桑德拉的虛擬分區鍵上找到太多內容，但是我能找到的東西往往與您應該完全避免它們的想法一致。虛擬的，我的意思是一個列，其唯一目的是爲所有行包含相同的值，從而將所有數據放在1個節點上，並給出最低可能的基數。例如：

dummy | id | name 
------------------------- 
0  | 01 | 'Oliver' 
0  | 02 | 'James' 
0  | 03 | 'Nicholls' 

的問候，爲什麼你應該避免虛擬分區鍵的兩個要點是：

1）你的數據「熱點」而告終。一個節點上存儲了大量數據，因此該節點周圍的流量更多，並且您在集羣周圍的分佈很差。

2）分區空間是有限的。如果將所有數據放在一個分區上，最終將無法存儲更多數據。

我可以理解這些觀點，我同意你絕對想要避免這些情況，所以我把這個想法放在我的腦海裏，並試圖爲我的桌子考慮一個好的分區鍵。有問題的表存儲站點，並且在我們的系統中有兩種常見的表格查詢方式。請求單個站點或請求所有站點。

這使我處於一種尷尬的境地，因爲該表或者在沒有任何內容或站點ID的情況下被查詢，並且創建一個唯一的字段分區鍵會給我提供非常高的基數和高延遲請求所有請求站點。

因此，我決定只選擇一個任意的字段，它會給出相對較低的基數，即使它沒有反映數據如何被實際查詢，僅僅是因爲它比基數要麼過分高或過低。儘管這種方法也有問題。

我可以將我的數據分配到第x列，但我們有許多客戶，他們都以不同的方式使用我們的系統，因此1個客戶端的x可以給出我以後的結果，但可能給另一個客戶帶來可怕的結果。

在這一點上，我用盡了選擇。我需要一個表格中的字段，這個字段對於所有的客戶端都是一致的，但是這個字段不存在，所以我現在考慮有一個新的字段，它將包含一個從1-3開始的隨機數，然後在該字段上進行分區，這實質上只是一個虛擬領域。唯一的區別是我想稍微隨機化一些值，以避免熱點和無限制的行增長。

我知道這是一個數據建模問題，它隨系統而變化，當然會出現一些情況，你必須選擇兩個邪惡中的較小者（沒有完美的解決方案），但是什麼我真的專注於這個問題是：

虛擬分區鍵是不應該在卡桑德拉考慮的東西，或者是否存在被視爲可接受的情況？如果你認爲前者，那麼你會如何處理這種情況？

Answer 1

我找不到太多關於卡桑德拉虛擬分區鍵的問題，但我可以找到會隨到另一邊你應該完全避免它們的想法。

我要出去肢體和猜測，你的搜索已經取得了我的文章We Shall Have Order!，在那裏我做了使用「虛擬」分區鍵很清楚我的立場。考慮到這一點，我會嘗試提供一些備用解決方案。

我在這裏看到兩個潛在的問題需要解決。第一：

我需要在我的表中的字段，這將是對所有客戶端一致的，但是這個領域不存在

這通常是通過複製數據到另一個查詢表解決。這是提供多種查詢模式的最佳方式。如果您有一個需要通過站點ID查詢該表的客戶端（服務？），則可以將該表複製到名爲sites_by_id的表中。

CREATE TABLE sites_by_id (
    id BIGINT, 
    name TEXT, 
    PRIMARY KEY (id)); 

這將是更方便你運行卡桑德拉3.0，你可以利用此功能的materialized view。

的另一個問題是這樣的查詢模式：

所有網站都要求

另一種常見的卡桑德拉反模式是綁定的的SELECT（SELECT查詢，而WHERE子句）。我相信你明白爲什麼這些是不好的，因爲它們需要讀取所有節點/分區才能完成（這可能是你爲什麼要查看「虛擬」鍵）。但是，隨着支持這些查詢類型的表增加，隨着時間的推移，它們只會變得越來越慢......無論您是執行未綁定的SELECT還是使用「虛擬」鍵。

這裏的解決方案是重新檢查您的數據模型和業務需求。也許你的數據可以按地區或國家劃分爲網站？也許你的客戶真的只需要今年更新的網站？獲取關於客戶查詢要求的更多細節可以幫助您找到一個很好的分區鍵以供他們使用。否則，如果他們真的需要做所有的時間，那麼doanduyhai的使用Spark的建議將更好地適合您的使用情況。

Answer 2

或所有網站都要求

所以基本上你有一個全表掃描的情況。是不是Apache Spark over Cassandra更適合這種用例嗎？我懷疑這是一個分析用例，不是嗎？

據我所知，你想訪問一個單一的網站的ID，在這種情況下通過分區鍵查找是理想的。這就需要獲取所有網站的其他用例是最適合與星火