2012-07-01 51 views
5

Redis在概念上與我使用的傳統SQL數據庫有所不同,我試圖弄清楚它是否適合我的項目......我一直在環顧四周,但似乎無法找到對我的問題的答案。Redis和查詢值

我有一組需要存儲的用戶,每個用戶都有一個唯一的ID和與其關聯的多個值(如他們的名字)。好像我可以簡單地存儲這些作爲哈希:

user:fef982dcfe1a7bcba4849b4c281bba95 
"username" "andrewm" "name" "Andrew" 

我也有一堆的消息我想存儲,每一個都具有一些特性,如發件人和收件人:

message:1a7bcba4849b4c281bfef98a952dcfeb 
"sender" "fef982dcfe1a7bcba4849b4c281bba95" "recipient" "82dcfe1a7bcba4849b4c281bba95fef9" "message" "Hi!" 

我的問題是,我將如何去檢索由特定用戶發送的所有消息(由他們的散列表示)。我應該使用傳統的關係數據庫,還是使用像MongoDB這樣的NoSQL數據庫(我之前使用過)?如果是這樣,有沒有人對高性能商店有任何建議?我不會做任何真正的搜索(即MySQL LIKE查詢) - 只是關鍵值查找,真的。

回答

7

用Redis建模這些數據當然是可行的,但是您需要考慮數據結構和訪問路徑。使用Redis時,訪問路徑不會隱式管理(就像使用RDBMS/MongoDB中的索引一樣)。

對於所提供的例子,你可以有:

user:<user hash> -> hash of user properties 
user:<user hash:sent -> set of <msg hash> 
user:<user hash>:received -> set of <msg hash> 
message:<msg hash> -> hash of message properties 

添加/刪除的消息將意味着保持*:發送和*:接收到對應於發件人和收件人組,在添加/刪除頂部消息對象本身。

檢索發送或接收的消息給定用戶僅僅是一個SMEMBERS命令,或整理,如果你也想檢索消息的同時屬性:

# Get a list of message hash codes only in one roundtrip 
smembers user:<user hash>:received 

# Get a list of message contents in one roundtrip 
sort user:<user hash>:received by nosort get message:*->sender get message:*->message 

有關使用的基本原理排序,請參閱:

注意1:與Redis最好使用整數作爲鍵而不是UUID或散列碼(特別是在集合中),因爲它們以更有效的方式存儲。

注意2:如果您需要訂購消息,則必須使用列表而不是集合。結果是隻有最舊的消息才能被刪除,並且只有新消息才能以有效的方式添加。您可能還會爲所有消息添加全局列表。

+0

非常感謝您的解釋 - 這非常有幫助。我會進一步看看:) –

+0

嗨,謝謝,非常有幫助。如果「添加/刪除消息意味着維護*:發送和*:接收集合」,它是否需要更多的空間來存儲數據,因此在內存中佔用更多空間?如果這種「多店鋪」經常完成,會不會成爲業績問題?感謝您的幫助 – Loic

+0

是的,它代表了更多的數據存儲。關於性能,您應該使用流水線來分攤執行給定操作的多個命令的影響。請參閱http://redis.io/topics/pipelining –