Redis存儲(chǔ)結(jié)構(gòu)體信息，選hash還是string？

點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)

作者：布魯斯1990

來源：blog.csdn.net/u010145219/article/details/99427693

string和hash都是Redis的一種數(shù)據(jù)結(jié)構(gòu)。string結(jié)構(gòu)常用來緩存用戶信息，通常將用戶信息結(jié)構(gòu)體使用JSON序列化成字符串，然后將序列化后的字符串存入Redis進(jìn)行緩存。

前面說到string適合存儲(chǔ)用戶信息，而hash結(jié)構(gòu)也可以存儲(chǔ)用戶信息，不過是對(duì)每個(gè)字段單獨(dú)存儲(chǔ)，因此可以在查詢時(shí)獲取部分字段的信息，節(jié)省網(wǎng)絡(luò)流量。

因此就引出了這篇文章，存儲(chǔ)結(jié)構(gòu)體信息是用hash還是string？

以下信息出自StackOverflow ?Redis strings vs Redis hashes to represent JSON: efficiency?

這個(gè)問題底下有個(gè)開發(fā)者回答的非常好，這里翻譯出來供大家一起學(xué)習(xí)討論，如果有更好的方案，歡迎提出來 首先，答者建議參考redis官方的內(nèi)存優(yōu)化的文章：https://redis.io/topics/memory-optimization，用來理解官方的開發(fā)者是內(nèi)存優(yōu)化方面基于什么考慮。

之后，答者列出了四個(gè)方案并給出了各個(gè)方案的利弊

1. 存儲(chǔ)整個(gè)對(duì)象，其中JSON序列化過的字符串作為key

INCR?id:users
SET?user:{id}?'{"name":"Fred","age":25}'
SADD?users?{id}

• 優(yōu)勢(shì)：可以認(rèn)為是“最佳實(shí)踐”，因?yàn)槊總€(gè)對(duì)象都是全特性的key，JSON解析特別塊，尤其是一次性查詢很多個(gè)字段的時(shí)候
• 劣勢(shì)：如果只查詢一個(gè)字段，速度就顯得比較慢了

2. 在hash中存儲(chǔ)每個(gè)對(duì)象的屬性

INCR?id:users
HMSET?user:{id}?name?"Fred"?age?25
SADD?users?{id}

• 優(yōu)勢(shì)：這也可以認(rèn)為是最佳時(shí)間。每個(gè)對(duì)象都是一個(gè)全特性的key。不需要解析JSON字符串
• 劣勢(shì)：如果要查詢對(duì)象的全部字段會(huì)比較慢。嵌套類型的對(duì)象（即對(duì)象里面還包著對(duì)象）無法輕易存儲(chǔ)

3. 將對(duì)象轉(zhuǎn)化為JSON字符串，用hash結(jié)構(gòu)存儲(chǔ)

INCR?id:users
HMSET?users?{id}?'{"name":"Fred","age":25}'

這個(gè)方案可以僅用兩個(gè)key，不需要很多key。但是沒法對(duì)每個(gè)用戶對(duì)象設(shè)置TTL(Time to Live，剩余生存時(shí)間)，因?yàn)閷?duì)象僅僅是hash中的一個(gè)字段，而不是全特性的key

• 優(yōu)勢(shì)：JSON解析很快，尤其是一次查詢多個(gè)字段時(shí)，對(duì)主key的命名空間污染更少
• 劣勢(shì)：如果要存儲(chǔ)很多對(duì)象，那么內(nèi)存使用和方案1相當(dāng)。當(dāng)只需要查詢一個(gè)字段時(shí)，會(huì)比方案2速度慢。答者不認(rèn)為這是一個(gè)“最佳實(shí)踐”

4. 存儲(chǔ)對(duì)象的每個(gè)屬性作為單獨(dú)的key

INCR?id:users
SET?user:{id}:name?"Fred"
SET?user:{id}:age?25
SADD?users?{id}

根據(jù)上面的文章，即redis內(nèi)存優(yōu)化，這個(gè)方案不推薦（除非對(duì)象的屬性需要專門設(shè)置TTL或者別的設(shè)置）

• 優(yōu)勢(shì)：對(duì)象的屬性是全特征key，對(duì)于應(yīng)用來說比較好處理
• 劣勢(shì)：慢，內(nèi)存消耗更大，不是一個(gè)“最佳實(shí)踐”。對(duì)主key的命名空間有很大污染

總的來說，方案4是最不推薦的，方案1和方案2非常相似，也很常見。答者更推薦方案1，因?yàn)檫@個(gè)方案允許存儲(chǔ)更復(fù)雜的對(duì)象（也就是說對(duì)象可以有很多層嵌套）。方案3通常用在對(duì)命名空間比較有要求的場(chǎng)景下，比如說不想要太多key，不關(guān)心TTL等參數(shù)

參考資料

• Redis深度歷險(xiǎn)：核心原理與應(yīng)用實(shí)踐
• Redis strings vs Redis hashes to represent JSON: efficiency?