背景：有一個接入系統專門對采集到的微博、文章、微信、報刊、論壇、博客等等的數據進行解析，到目前為止已經大概存有3億多的量
需求：我們需要通過圖片的ID號得到對應圖片作者是誰（這個可以隨意）
問題：那么我們如何通過redis來解決這個問題並進行優化呢？
首先，這個通過圖片ID反查用戶UID的應用有以下幾點需求：
- 查詢速度要足夠快
- 數據要能全部放到內存里，最好是一台EC2的 high-memory 機型就能存儲（17GB或者34GB的，68GB的太浪費了）
- 支持持久化，這樣在服務器重啟后不需要再預熱
首先否定了數據庫存儲的方案，保持了KISS原則（Keep It Simple and Stupid），因為這個應用根本用不到數據庫的update功能，事務功能和關聯查詢等等牛X功能，所以不必為這些用不到的功能去選擇維護一個數據庫。
於是我們選擇了Redis，Redis是一個支持持久化的內存數據庫，所有的數據都被存儲在內存中（忘掉VM吧），而最簡單的實現就是使用Redis的String結構來做一個key-value存儲就行了。像這樣：
> HSET "mediabucket:1155" "1155315" "939" > HGET "mediabucket:1155" "1155315" > "939"
其中1155315是圖片ID，939是用戶ID，我們將每一張圖片ID為作key，用戶uid作為value來存成key-value對。然后進行了測試，將數據按上面的方法存儲，1,000,000數據會用掉70MB內存; 300,000,000張照片就會用掉21GB的內存。對比預算的17GB還是超支了。
(其實這里我們可以看到一個優化點，我們可以將key值前面相同的media去掉，只存數字，這樣key的長度就減少了，減少key值對內存的開銷【注：Redis的key值不會做字符串到數字的轉換，所以這里節省的，僅僅是media:這6個字節的開銷】經過實驗，內存占用會降到50MB，總的內存占用是15GB，是滿足需求的，但是繼續改進仍然有必要)
於是向Redis的開發討論組詢問優化方案，得到的回復是使用Hash結構。具體的做法就是將數據分段，每一段使用一個Hash結構存儲，由於Hash結構會為單個Hash元素在不足一定數量時進行壓縮存儲，所以可以大量節約內存。這一點在上面的String結構里是不存在的。而這個一定數量是由配置文件中的hash-zipmap-max-entries參數來控制的。經過我們的實驗，將hash-zipmap-max-entries設置為1000時，性能比較好，超過1000后HSET命令就會導致CPU消耗變得非常大。
於是改變了方案，將數據存成如下結構：
> HSET "mediabucket:1155" "1155315" "939" > HGET "mediabucket:1155" "1155315" > "939"
圖片ID為7為，通過取其前四位為Hash結構的key值，保證了每個Hash內部只包含3位的key，也就是1000個。
再做一次實驗，結果是每1,000,000個key只消耗了16MB的內存。總內存使用也降到了5GB，滿足了應用需求。
(同樣的，這里我們還是可以再進行優化，首先是將Hash結構的key值變成純數字，這樣key長度減少了12個字節，其次是將Hash結構中的subkey值變成三位數，這又減少了4個字節的開銷，如下所示。經過實驗，內存占用量會降到10MB，總內存占用為3GB)
> HSET "1155" "315" "939" > HGET "1155" "315" > "939"
優化無止境，只要肯琢磨。希望你在使用存儲產品時也能如此愛惜內存。