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類型作為我們的存儲方式會比較好。