存儲Redis密鑰的最佳方法

Question

我正在使用Redis存儲一些信息並檢測該信息隨時間的變化（例如，考慮用戶和位置）。 使用更長或更短的鍵名有什么價值？ 使用更長的鍵會更清晰，但是使用更長的鍵名是否會在內存或性能上付出很多成本？

以下是示例：

SET L:123456 "<name> <latitude> <longitude> ..."
HSET U:987654321 loc 123456 time <epoch>

要么

SET loc:{123456} "<name> <latitude> <longitude> ..."
HSET user:{U987654321} loc 123456 time <epoch>

Answer 1

這完全取決於您將如何使用它。 如果每個字節都很重要，例如，當您必須為傳輸到雲服務的每個kB支付費用時，您可以計算成本。 數學很簡單； 字節是“在線”字節。 在redis內部，對於較大的值，它同樣簡單。 對於較小的值，Redis會進行一些內存優化。

在您的HSET示例中，您拆分了成員，這僅在大多數情況下需要將它們彼此分離時才有意義。 更好的方法- 可能是： HSET HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' 。 在性能上，單獨的鍵/成員比較長的字符串“花費”更多。 如果僅將整個表或數據集用作一個完整的半靜態實體，甚至可以將其放在一個成員中。

速度和大小： 鍵和值之間存在顯着差異。

關鍵：較短的內存通常更有效地提高存儲效率，並提高速度。 如果您使用redis Sorted Set ，甚至可以使用“數字”作為鍵（已排序的“成員”加“分數”）。 我說“數字”是因為分數從技術上講是float64，但要用作ID，它必須介於-999999999999999和999999999999999之間（包括15位數字），且沒有小數部分。 這確實很有幫助，因為Redis可以對排序集進行快速且可擴展的O（log（n））動態排序（使用跳過列表，已簡化）。

值： MsgPack格式（未壓縮）占用的空間最少，尤其是如果您存儲一次定義和許多值的話。 JSON的內存效率較低，但是當然是一種通用IPC格式，因此不應忽略。 原始字符串，字符分隔，固定長度（ugh），無論您需要什么，都可以使用。 您始終可以先壓縮數據，然后再將其存儲在Redis中。 到目前為止的內存效率 。 說到速度 ，它就不那么簡單了。 如果要使用Lua服務器端腳本（應使用），則不能對壓縮數據執行任何操作。 JSON和MsgPack可以反序列化，但只能是“整體”。 在大多數情況下，這很好。 最靈活的是存儲單獨的值（例如，作為HSET的成員），但這也要付出一定的代價（大多數情況下：代價太高）。 您也可以將所有這些結合起來。 我們最常使用的：兩個或三個以分隔符分隔的值的前綴，后跟一個MsgPack有效負載。

我的一般建議是：從僅使用HSET和ZSET開始，不要拆分屬於它們的數據，在10到25個字符之間使用描述性PascalCased名稱作為鍵，如果鍵中需要定界符（名稱空間），請使用'：' ，序列化為JSON（為簡單起見，但為了輕松切換至MsgPack而使用代碼），使用Lua腳本（即使您不知道Lua，在Redis中使用的子集也很小）。

在您的項目的啟動階段，我不必擔心太多，您可以隨時稍后對其進行更改，並在擁有一些可插值數據后立即進行A / B比較。

希望這會有所幫助，TW

Answer 2

現在，Redis v3.2即將發布，您應該考慮切換到新的地理哈希功能： http : //redis.io/commands/geoadd