追隨者系統，MySQL或Redis更好？

Question

我只是想知道選擇什麼解決方案來實現跟隨者系統？

在MySQL中，我將有一個表

userID INT PRIMARY, 
followID INT PRIMARY 

而在Redis的我只想用一個SET，並添加到用戶ID的所有followIDs。

讓我們說有人擁有2000追隨者，並且您想列出所有追隨者？（在包含大約1M個條目的表中） 如果兩個用戶相互追隨，會更快？

非常感謝！

Answer 1

按照現代標準，1M項目什麼都不是。任何數據庫或NoSQL系統都可以在這樣的音量下正常工作，所以你只需要選擇一個你最喜歡的那個。

在絕對性能方面，Redis的將是這種使用情況比MySQL快，這是因爲：

• 整個數據集都在內存
• 哈希表是
• 沒有比B樹更快沒有SQL查詢來解析或執行

但是，請注意關係數據庫比像Redis這樣的關鍵/值存儲更靈活。如果您可以預測所有數據訪問路徑，那麼Redis是一個很好的解決方案。否則，你會更好地服務於一個更傳統的數據庫。

Answer 2

在我看來，去與MySQL。

你會想到做決定的時候，最大的兩個要點是：

1）你有沒有想過你的使用情況？

你說你想實現一個追隨者系統。如果您只是要顯示每個用戶擁有的關注者列表，那麼Redis SET就足夠了。

但是，如果您想獲得「您當前正在關注的用戶列表」的列表？您無法從Redis SET中輕鬆挖掘，對吧？或者如果您想知道User-X是否關注用戶A，那該怎麼辦？如果用戶A擁有10,000個關注者，這會不會很容易呢？

當在不同的場景中查詢不同類型的結果時，MySQL更加靈活。

2）您是否真的需要性能差異？

如您所知，在這些情況下，Redis比MySQL更快。 這是一個簡單的鍵值系統，因此它會超過MySQL的性能。 檢查出的性能結果這樣的：

http://colinhowe.wordpress.com/2009/04/27/redis-vs-mysql/

http://ruturaj.net/redis-memcached-tokyo-tyrant-and-mysql-comparision/

但Redis的和MySQL之間的性能差異真的只啓動後約5,000request /秒 踢。 否則你將不會看到的50ms以上的差異。直到你有一個非常大的流量

性能差異將不再是一個問題。

所以，想着這兩點後，MySQL的將是一個更好的答案。

Redis的將是很好的只有：

1）設定的目的/列表是特定的，並且在未來

2）你覺得沒有必要靈活性，性能差異會實際上對你的架構有影響。

Answer 3

這取決於你想用數據做什麼。你舉了一些例子，但它聽起來不像你真的給出了產品需要做的完整定義。如果你真的想要做的就是向用戶展示他們是否遵循對方？那麼或者你只是在談論2個簡單的查詢就可以了。但是，如果你想要的東西，以顯示兩個用戶的用戶分享他們的交集或者你想建議關閉基於爲用戶配置文件數據的數據。然後，它變得更加有趣，Redis的具有功能，輕鬆讓你的集合的交集非常非常快（我們在速度方面講幅度差異不只是毫秒 - 與差異也較大成倍因爲有更多的用戶/關係因爲如果你想要實時提供數據，所需的sql連接就可以解析數據，從而使數據變得過於複雜）。

sadd friends:alex george paul bart 
sadd friends:alice mary sarah bart 
sinterstore friends:alex_alice friends:alex friends:alice 

注意上面可以與MySQL進行爲好，但你的性能將受到影響，這將是你更可能運行一個批處理作業，然後儲存以備將來使用效果的東西。另一方面，請記住，世界上最大的「朋友」網絡Facebook開始使用mysql來存儲關係。這些關係的圖形已經成批處理，並且在成千上萬個memcached服務器中進行存儲時非常規範化以獲得不錯的性能。

然後，如果您正在尋找除mysq1或redis之外的更多選項，您可能需要閱讀Michael Stonebaker所說的內容（他幫助創建Postgres和Ingres），以便使用RDBMS系統爲圖形數據（如朋友關係）使用RDBMS系統。 http://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate-worse-than-death/。當然，他正試圖出售他的新款VoltDB，但這是值得思考的有趣食物。

所以我認爲你真的需要繪製出應用程序的需求（因爲我認爲它不僅僅是向你展示你的朋友是誰）在預期的負載方面（你只是拋出2000或者是這是你期望處理的），功能和預算。然後真正考察市場上的許多不同選擇。