2012-12-28 109 views
0

例如,考慮一個複合主散列和範圍密鑰表,其中散列密鑰表示設備ID,並且設備ID「D17」的請求特別嚴重。要提高此「熱」散列密鑰的讀寫吞吐量,請從固定集合(例如1至200)中選取一個隨機數,然後將其與設備ID連接起來(這樣您可以將D17.1,D17.2 D17.200)。由於隨機化,設備ID「D17」的寫入均勻分佈在多個散列鍵值上,產生更好的並行性和更高的整體吞吐量。關於亞馬遜dynamodb數據庫

該策略大大提高了寫入吞吐量,但由於您不知道200個密鑰中哪些包含該項目,因此特定項目的讀取變得更難。您可以改進此策略以獲得更好的閱讀特徵:而不是選擇一個完全隨機的數字,而是選擇一個數字,您可以從項目的固有內容進行計算。例如,如果項目表示擁有該設備的人員,則根據其名稱或用戶標識計算哈希鍵後綴。這個計算應該計算一個介於1和200之間的數字,在給定任何一組名稱(或用戶ID)的情況下,它是相當均勻分佈的。一個簡單的計算通常就足夠了(例如,人名模板200中的字母的ASCII值的乘積+ 1)。現在,寫入均勻分佈在散列鍵(以及分區)之間。而且您可以輕鬆執行get操作,因爲您可以在您想要檢索特定「設備所有者」值時確定所需的哈希鍵。查詢操作仍然需要針對所有D17.x密鑰運行,並且您的應用程序需要客戶端的一些邏輯來合併每個散列密鑰的所有查詢結果(本例中爲200)。但是,該模式避免了讓一個「熱」散列鍵佔用所有的工作量。

任何人都可以請解釋他們在上面的例子中說什麼?

在此先感謝

阿明

回答

1

這簡直就是試圖優化讀/寫吞吐量爲特定的高度使用哈希鍵的策略。你基本上將一個散列鍵分割成(在本例中)200個不同的散列鍵,這樣你就可以根據某種散列的計算來讀寫所需的鍵。真的,讀取需要散列,以便您可以確定要請求的密鑰。

+0

非常感謝您的回答。 –

+0

如果您對此感到滿意,您應該在此答案上勾上勾號大綱(表示感謝) –