Redis 索引值設計問題？

作為一個小白，最近學習 Redis 緩衝，心中有一個疑問：
假如在 mysql 中有一張 user 表用於儲存使用者的相關資訊，表的主要欄位有：id,username,password,email,nick,born,sex,status等等，現在想將 user 資料表中的所有資料全部緩衝到 redis 資料庫伺服器中，請問 redis 的索引值應該怎麼設定呢？
是設為類似於：

user:[id]:username username_valueuser:[id]:password password_valueuser:[id]:email email_valueuser:[id]:nick nick_value...

還是設定為這樣的形式呢：

user:[id] json_string// json_string 是將一條使用者資訊的二維數群組轉換成json字串

請問這兩種形式哪種更好一些？哪種更節約記憶體一些？
希望各位大嬸能解答一下我的疑問，對此表示萬分感謝 =.=

回複內容：

作為一個小白，最近學習 Redis 緩衝，心中有一個疑問：
假如在 mysql 中有一張 user 表用於儲存使用者的相關資訊，表的主要欄位有：id,username,password,email,nick,born,sex,status等等，現在想將 user 資料表中的所有資料全部緩衝到 redis 資料庫伺服器中，請問 redis 的索引值應該怎麼設定呢？
是設為類似於：

user:[id]:username username_valueuser:[id]:password password_valueuser:[id]:email email_valueuser:[id]:nick nick_value...

還是設定為這樣的形式呢：

user:[id] json_string// json_string 是將一條使用者資訊的二維數群組轉換成json字串

請問這兩種形式哪種更好一些？哪種更節約記憶體一些？
希望各位大嬸能解答一下我的疑問，對此表示萬分感謝 =.=

存hash呢 使用者id加個首碼設為key.比如user:888
hash集合裡存常用使用者屬性.
另外不推薦全部使用者無腦存緩衝...這樣有點本末倒置了..mysql會一臉懵逼的(要我何用←_←)...可以試著建立一個簡單的熱度統計 熱使用者存緩衝

實在不行你就給hash設一個逾時 每個使用者資訊第一次登入後就存一段時間....省的你勞神費心...

沒研究過不同資料類型與記憶體的關係
從商務邏輯角度來講，具體怎麼設計儲存看需求來定
比如緩衝只是為了查詢方便與資訊展示，選第二種，mysql或者mongodb有相關操作再更新相應緩衝
如果需要賦予登入、資料CURD等邏輯，同樓上，建議用hash，比如用HMSET，而非String類型

第一種好些吧，可以查到某一個，不需要編碼

個人認為第1種比較好，方便單個擷取和修改，如果是後者，每次擷取或者修改單個屬性都要擷取全部，而且解析json擷取其他序列化和還原序列化的形式都會帶來額外的消耗。
大部分情況，查詢不需要查詢所有的欄位，修改的話，大部分都是只修改1個欄位

我也碰到過資料表緩衝的問題，我的解決方案是使用多種資料類型來配合完成

首先每條資料記錄存成一個字典，用表名+ID然後md5加密後作為字典的名字
然後使用有序集合來儲存每一條記錄的字典名稱與排序權重（我這裡是有排序的需求，所以使用有序集合，否則的話使用集合或者列表都是可以的）

PS:redis中無法進行where查詢之類的操作，所以如果有需要可以將在代碼層進行篩選然後再按分類存進redis，比如我就是對資料進行篩選後存進幾個不同的有序集合，然後再將這些有序集合的名字維護到一個列表中

後者。
操作方便，並且可以避免無底洞現象。

緩衝無底洞現象

不要用json，看似取值方便，但是多處同時更新快取資料的時候簡直是不可描述。寫程式沒有方便不方便，只有你寫的東西可不可靠。

沒有必要全部緩衝，比如性別就不需要，只有經常訪問的才需要緩衝。

redis下用json怎麼說呢。。不是說不可能，只是沒有充分利用redis的價值 開心就好

使用hash結構。推薦第二種，資料存緩衝的第一個意義是加快瀏覽速度，而對一些會修改的資料我正常是多建一個緩衝來儲存要修改的資料，實際展示的資料會是正常緩衝+修改緩衝的資料。

一般業內的做法就是
值儲存成二進位的形式,而不是字串,這樣是省記憶體的,效率也高,缺點就是通過redis-cli沒法看明文,因為已經是二進位形式了
比如你這個
key=user:[id]
value=這個user對象轉成的二進位形式

那麼下次你用java讀這個value後, 會自動轉為你那個對象, 多簡單, 不用一個一個屬性set了

不過你要注意一旦涉及成這樣,就無法通過user的其他屬性進行搜尋了,前提是你要瞭解你的業務, 如果有其他欄位的搜尋你要加一組其他的key value, 在nosql中資料冗餘很常見

nosql都是這樣, 寫程式的一定要瞭解業務, 否則資料結構設計的會不好, 雖然nosql的使用門檻很低,但是設計門檻還是有的

