redis - 使用哈希

Question

我使用redis爲我的web應用程序實現社交流和通知系統。我是redis的新手，對散列和效率有一些疑問。

我讀過這個真棒Instagram post 我計劃實施他們類似的解決方案以實現最小的存儲。

在他們的博客中提到，他們不喜歡這樣

取散型的優勢，我們鬥了所有介質ID爲1000桶（我們只取ID，除以1000，並丟棄其餘的）。這決定了我們陷入的關鍵;接下來，在生存在該密鑰的散列內，媒體ID是散列中的查找鍵，並且用戶ID是該值。一個實例中，給定的1155315媒體ID，這意味着它落入桶1155（千分之一百十五萬五千三百十五= 1155）：在一個

HSET "mediabucket:1155" "1155315" "939" 
HGET "mediabucket:1155" "1155315" 
> "939" 

所以代替具有1000單獨鍵它們存儲它的與千位查找鍵的散列。我的疑問是爲什麼我們不能將查找關鍵值增加到更大。

例如：Media ID of 1155315 will fall into mediabucket:115 by dividing it by 10000 甚至更​​大。

他們爲什麼用一個帶有1000個查找鍵的哈希桶來解決問題。爲什麼他們不能有一個哈希桶與100000查找鍵。是否與效率有關？

我需要你的建議在我的web應用程序中實現高效的方法。

P.S.請！不要說，stackoverflow不是提問的建議，我不知道在哪裏可以找到幫助。

謝謝！

Answer 1

是的，這與效率有關。

我們問總是有幫助的彼得Noordhuis，Redis的的核心開發者之一，投入，他建議我們使用Redis的哈希值。 Redis中的哈希是可以非常有效地編碼在內存中的字典; Redis設置'hash-zipmap-max-entries'配置哈希可以有效編碼的最大條目數。我們發現這個設置最好在1000左右;任何更高和HSET命令會導致明顯的CPU活動。有關更多詳細信息，可以查看zipmap源文件。

小哈希以特殊方式編碼（zipmaps），這是內存有效的，但操作O（N）而不是O（1）。因此，使用一個帶有100k字段的zipmap而不是100個帶有1k字段的zipmap，您無​​法獲得內存優勢，但所有操作的速度都會降低100倍。

Answer 2

基本上，他們希望單個散列中存儲的值的數量不超過1000.他們可能會將其Redis實例配置設置爲與該數字很好地配合使用（您的設置爲hash-zipmap-max-entries）。

每次哈希將超過指定的元素或元素大小的數量時，它將被轉換爲真正的哈希表，並且內存保存將會丟失。

- http://redis.io/topics/memory-optimization

據我瞭解，你的問題是 「到底爲什麼1000，而不是更多嗎？」那是因爲他們必須在空間效率和速度之間進行選擇。空間高效表示的操作複雜度爲O(N)，而不是O(1)作爲正常哈希值 - 它是慢N倍，但佔用較少的內存。

他們測試了不同的值，發現1000是一個很好的折中解決方案 - 佔用空間不大，但仍然足夠快。