我們在快取json資料到redis時經常會面臨是選擇string型別還是選擇hash型別去儲存。接下來我從佔用空間和IO兩方面來分析這兩種型別的優勢。
1、佔用空間
根據資料結構的共識我們知道hashtable型別是要比string型別更佔用空間， 而ziplist型別與string型別佔用的空間基本相差不大。
如下圖就是ziplist的儲存的格式
那我們接下來分別分析redis的string和hash型別佔用空間方面的知識
-
string型別： string型別當然如其名，如果json資料以string型別去儲存，那麼它的空間佔用方面肯定是相當的。
-
hash型別： redis對hash型別是有兩種編碼方式，分別是ziplist和hashtable。
當如下情況時redis的hash型別，底層是用ziplist編碼的：
- 雜湊物件儲存的所有鍵值對的鍵和值的字串長度都小於 64 位元組；
- 雜湊物件儲存的鍵值對數量小於 512 個；
不滿足上述情況時，redis的hash型別，底層編碼格式為hashtable。
2、IO
從IO的角度來分析string和hash型別，我們得有一個共識，我們知道redis是有服務端的，也就是部署redis的所在機器他們會運算能力的。
-
string型別：
- 取資料：根據redis鍵取對應的整個value值。
- 存資料：根據redis鍵存這個value值
- 更新資料： 根據redis鍵更新整個value值
-
hash型別：
- 取資料：根據redis鍵，然後遍歷整個hash鍵值對（相對string的取資料更加耗時）。
- 存資料：根據redis鍵，在value出存鍵值對
- 更新資料：根據redis鍵和hash key更新對應的資料
3、總結
綜上所述，那具體怎麼選擇是用string型別還是hash型別儲存json資料呢？給出以下結論
- 如果你的業務型別中對於快取的讀取快取的場景更多，並且更新快取不頻繁（或者每次更新都更新json資料中的大多數key），那麼選擇string型別作為儲存方式會比較好。
- 如果你的業務型別中對於快取的更新比較頻繁（特別是每次只更新少數幾個鍵）時， 或者我們每次只想取json資料中的少數幾個鍵值時，我們選擇hash型別作為我們的儲存方式會比較好。