Redis選擇Hash還是String存儲(chǔ)數(shù)據(jù)？
在stackoverflow 看到一個(gè)問題，Redis strings vs Redis hashes to represent JSON: efficiency?內(nèi)容如下：
I want to store a JSON payload into redis. There's really 2 ways I can do this:
One using a simple string keys and values.
key:user, value:payload (the entire JSON blob which can be 100-200 KB)
SET user:1 payload
Using hashes
HSET user:1 username "someone"
HSET user:1 location "NY"
HSET user:1 bio "STRING WITH OVER 100 lines"
Keep in mind that if I use a hash, the value length isn't predictable. They're not all short such as the bio example above.
Which is more memory efficient? Using string keys and values, or using a hash?
string 和 hash 直觀測(cè)試
首先我們先測(cè)試用數(shù)據(jù)測(cè)試一下，測(cè)試數(shù)據(jù)結(jié)構(gòu)如下：
- values = {
- "name": "gs",
- "age": 1
- }
使用for 生成10w個(gè)key，key的生成規(guī)則為：
- for i in range(100000):
- key = "object:%d" % i
把數(shù)據(jù)分別以hash 和 string(values 使用 json encode 為string )的形式存入redis。
結(jié)果如下：
hash 占用 10.16M
string 占用 10.15M
這看起來(lái)和我們印象中hash 占空間比較大的觀念不太一致，這是為什么呢?
這里是因?yàn)镽edis 的hash 對(duì)象有兩種編碼方式：
- ziplist(2.6之前是zipmap)
- hashtable
當(dāng)哈希對(duì)象可以同時(shí)滿足以下兩個(gè)條件時(shí)， 哈希對(duì)象使用 ziplist 編碼：
- 哈希對(duì)象保存的所有鍵值對(duì)的鍵和值的字符串長(zhǎng)度都小于 64 字節(jié);
- 哈希對(duì)象保存的鍵值對(duì)數(shù)量小于 512 個(gè);
不能滿足這兩個(gè)條件的哈希對(duì)象需要使用 hashtable 編碼。上述測(cè)試數(shù)據(jù)滿足這兩個(gè)條件，所以這里使用的是ziplist來(lái)存儲(chǔ)的數(shù)據(jù)，而不是hashtable。
注意
這兩個(gè)條件的上限值是可以修改的， 具體請(qǐng)看配置文件中關(guān)于 hash-max-ziplist-value 選項(xiàng)和 hash-max-ziplist-entries 選項(xiàng)的說(shuō)明。
hash-max-ziplist-entries for Redis >= 2.6
hash-max-ziplist-value for Redis >= 2.6
ziplist
ziplist 編碼的數(shù)據(jù)底層是使用壓縮列表作為底層數(shù)據(jù)結(jié)構(gòu)，結(jié)構(gòu)如下：
hash 對(duì)象使用ziplist 保存時(shí)，程序會(huì)將保存了鍵的ziplist節(jié)點(diǎn)推入到列表的表尾，然后再將保存了值的ziplist節(jié)點(diǎn)推入列表的表尾。
使用這種方式保存時(shí)，并不需要申請(qǐng)多余的內(nèi)存空間，而且每個(gè)Key都要存儲(chǔ)一些關(guān)聯(lián)的系統(tǒng)信息(如過期時(shí)間、LRU等)，因此和String類型的Key/Value相比，Hash類型極大的減少了Key的數(shù)量(大部分的Key都以Hash字段的形式表示并存儲(chǔ)了)，從而進(jìn)一步優(yōu)化了存儲(chǔ)空間的使用效率。
在這篇redis memory optimization官方文章中，作者強(qiáng)烈推薦使用hash存儲(chǔ)數(shù)據(jù)
Use hashes when possible
Small hashes are encoded in a very small space, so you should try representing your data using hashes every time it is possible. For instance if you have objects representing users in a web application, instead of using different keys for name, surname, email, password, use a single hash with all the required fields.
But many times hashes contain just a few fields. When hashes are small we can instead just encode them in an O(N) data structure, like a linear array with length-prefixed key value pairs. Since we do this only when N is small, the amortized time for HGET and HSET commands is still O(1): the hash will be converted into a real hash table as soon as the number of elements it contains will grow too much (you can configure the limit in redis.conf).
This does not work well just from the point of view of time complexity, but also from the point of view of constant times, since a linear array of key value pairs happens to play very well with the CPU cache (it has a better cache locality than a hash table).
hashtable
hashtable 編碼的哈希對(duì)象使用字典作為底層實(shí)現(xiàn)， 哈希對(duì)象中的每個(gè)鍵值對(duì)都使用一個(gè)字典鍵值對(duì)來(lái)保存：
- 字典的每個(gè)鍵都是一個(gè)字符串對(duì)象， 對(duì)象中保存了鍵值對(duì)的鍵;
- 字典的每個(gè)值都是一個(gè)字符串對(duì)象， 對(duì)象中保存了鍵值對(duì)的值。
hashtable 編碼的對(duì)象如下所示：
第二次測(cè)試
- values = {
- "name": "gs",
- "age": 1,
- "intro": "long..long..long..string"
- }
第二次測(cè)試方式和第一次一樣，只是把測(cè)試數(shù)據(jù)中加了一個(gè)大的字符串，以保證hash 使用hashtable 的方式存儲(chǔ)數(shù)據(jù)
結(jié)果如下：
hashtable： 1.13G
string： 1.13G
基本一樣，這里應(yīng)該主要是Hash類型極大的減少了Key的數(shù)量(大部分的Key都以Hash字段的形式表示并存儲(chǔ)了)，從而進(jìn)一步優(yōu)化了存儲(chǔ)空間的使用效率。
NOTE: 讀取和寫入的速度基本一致，差別不大
回到這個(gè)問題，對(duì)于string 和 hash 該如何選擇呢?
我比較贊同下面這個(gè)答案：
具體使用哪種數(shù)據(jù)結(jié)構(gòu)，其實(shí)是需要看你要存儲(chǔ)的數(shù)據(jù)以及使用場(chǎng)景。
如果存儲(chǔ)的都是比較結(jié)構(gòu)化的數(shù)據(jù)，比如用戶數(shù)據(jù)緩存，或者經(jīng)常需要操作數(shù)據(jù)的一個(gè)或者幾個(gè)，特別是如果一個(gè)數(shù)據(jù)中如果filed比較多，但是每次只需要使用其中的一個(gè)或者少數(shù)的幾個(gè)，使用hash是一個(gè)好的選擇，因?yàn)樗峁┝薶get 和 hmget，而無(wú)需取出所有數(shù)據(jù)再在代碼中處理。
反之，如果數(shù)據(jù)差異較大，操作時(shí)常常需要把所有數(shù)據(jù)都讀取出來(lái)再處理，使用string 是一個(gè)好的選擇。
當(dāng)然，最簡(jiǎn)單的就是聽從官方的建議，放心的使用hash 吧。
還有一種場(chǎng)景：如果一個(gè)hash中有大量的field(成千上萬(wàn)個(gè))，需要考慮是不是使用string來(lái)分開存儲(chǔ)是不是更好的選擇。
參考鏈接
[1] Redis strings vs Redis hashes to represent JSON: efficiency?: https://stackoverflow.com/questions/16375188/redis-strings-vs-redis-hashes-to-represent-json-efficiency
[2] redis memory optimization: https://redis.io/topics/memory-optimization
[3] Redis 設(shè)計(jì)與實(shí)現(xiàn)： http://redisbook.com/preview/object/hash.html
