redis存json數據時選擇string還是hash

我們在緩存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編碼的：

  1. 哈希對象保存的所有鍵值對的鍵和值的字符串長度都小於 64 字節；
  2. 哈希對象保存的鍵值對數量小於 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類型作爲我們的存儲方式會比較好。