Redis中最快的僞索引是什麼？

Question

Redis的Little Book解釋瞭如何通過電子郵件地址查找用戶標識，以便隨後通過用戶標識查找用戶散列並獲取完整的用戶對象。它通過電子郵件地址實際上是用戶的索引。你只需要每次添加到查找散插入這樣一個新的用戶：

set users:9001 "{id: 9001, email: leto@dune.gov, ...}" 
hset users:lookup:email leto@dune.gov 9001 

此操作在我看來，涉及哈希裏面隱藏查找的是Redis的必須執行的拉出值所需郵件字段。可能有數千個電子郵件字段，我們只要求其中一個。

如何使用電子郵件中這樣的索引鍵：

set users:9001 "{id: 9001, email: leto@dune.gov, ...}" 
set users:lookup:email:leto@dune.gov 9001 

因爲這不是在Redis的小書建議我相信它不是最好的做法。

任何人都可以解釋爲什麼第一種方法更好？他們有效嗎？

謝謝，我正在學習Redis。

Answer 1

在我看來，每一種方法都有自己的優點和缺點：

散列法：

• 你可以得到所有電子郵件（鑰匙）或ID的（值）的列表相當快（O（N），其中N是條目的地圖數）
• 對於小數量的條目，這將是相當的內存使用效率（非常小，雖然，可能並不適用於任何實際使用情況）
• 您僅限於2^32-1條目（再次，可能不是問題，unl您計劃在地球上的大多數人使用您的應用程序）
• 略微慢，因爲redis需要做兩個O（1）查找，而不是隻有一個......邊際差異，如果明顯的話。
• 不易碎片友好，因爲它們都將處於相同的redis實例中。

的關鍵方法：

• 沒有限制的條目
• 由於快速的號碼，該號碼將是
• 只有通過使用KEY得到所有用戶的列表，這是O（n）（對於數據庫中的每個條目 - 對於實況環境來說是很大的禁止）
• 對碎片友好

這些都是我能想到的所有差異。我傾向於傾向於關鍵方法，除非我需要列出所有用戶出於某種原因，僅僅因爲它更直接並且利用分片更好地擴展。另外，如果我可以避免它，我可能不會將JSON數據存儲爲用戶數據，因爲將字段存儲在散列中可能更具有內存效率。此外，您可以獲取並設置您確實需要的字段，而不是整個blob。也可以在沒有事務的情況下以原子方式在散列中進行增量，這很有用。但這一切都取決於你的數據...如果你有一個大的嵌套結構，可能最簡單的方法就是將它序列化並扔到那裏，而不是創建許多不同的本地結構並將它們連接在一起。