從redis切換到Mysql。好主意？

我們正在爲使用Rails的餐館構建一個SaaS後端。我們直接與POS集成，所以每個POS都會不斷髮送我們存儲的用於以後處理的客戶訂單。我們在大約1,000個地點進行POS集成，每月向我們發送約300萬個客戶訂單。對於這個寫入重量級的應用程序，我們將所有訂單存儲在redis中，並且工作得很好。我們以令人難以置信的速度增長，我們不斷增加擁有數百個位置的新餐廳，不斷向我們發送瘋狂的數據量。除了有一個問題 - 每個月Redis都會耗盡內存！因爲，所有不需要記憶的東西都在記憶中。從redis切換到Mysql。好主意？

這就是我們考慮切換到mysql的原因。因爲我們並不需要將所有數據都保存在內存中。這裏有我們的數字電流的Redis數據庫：

used_memory_human:39.83G 
    dbsize: 34706870

下面是我們在Redis的存儲爲哈希：

id - integer 
location_id - integer 
stored_at - timestamp 
token - string 
transaction_no - integer 
menu_items - string(comma seprated list of all menu items that customer ordered along with their price & Qty) 
order_amount - decimal 
order_subtotal_amount - decimal 
order_amount_payable - decimal 
order_datetime - timestamp 
employee_id - integer 
employee_name - string 
pos_type - string 
post_version - string 
restaurant_id - integer

所以，找了一些建議：

移動Redis到MySQL是個好主意？長遠來看它將如何影響我們，因爲我們需要不斷更新我們的指數&分割方案以迎合巨大的需求。
什麼其他數據庫（關係型或非關係型）比redis適合這種用例？
或者我們都錯了，因爲redis是用來存儲這種類型的數據的。所以，我們只是每個月都繼續使用redis &升級我們的機器？

來源

2014-10-19 CuriousMind

網絡上的數據必然會增長。任何長期項目都應該預見到這一點，並制定擴展戰略。

隨着您的數據量或流量的增加，您會發現大約每增長一個數量級都需要更改架構來處理它。也許你可以稍微領先一點，但不是永遠。而且你無法預測你的瓶頸將會提前很遠。

一小部分數據對於您的應用程序的每分鐘工作很重要，並且您可以在Redis中保留此子集以利用當前代碼。然後剩餘的數據可以在另一個數據存儲中使用，可能訪問速度稍慢，但處理增長要容易得多。

你可以放棄當前的代碼和移動一切MySQL或其他數據存儲，但要兩兩件事：

沒有數據庫，讓你忽略具有縮放策略。您可以使用MySQL，PostgreSQL或MongoDB，或Hadoop或其他任何軟件，並且您的數據增長速度仍然快於單個服務器上的單個數據庫可以處理的問題。
由於更高效的開發或操作的內部原因，重新編寫應用程序通常不具有成本效益（請參閱Things You Should Never Do, Part I by Joel Spolsky）。

我建議您保留您的Redis應用程序，但嘗試將歷史數據移動到另一個數據存儲區。

我認爲MySQL是一個不錯的選擇，我相信它能夠處理您的數據。我經常與客戶一起工作，他們在MySQL中保存Terrabytes數據，並且每秒處理數萬次事務。但是由於您沒有提供有關您對數據使用情況的任何詳細信息，因此我無法提供有關MySQL是否爲最佳選項的意見。例如，可能Hadoop具有優勢。

來源

2014-10-19 16:22:18

如果MySQL（或任何其他傳統的數據庫）就足夠了，爲什麼你在第一個地方去Redis的？
「我們爲了以後處理而存儲」是含糊不清的。你能詳細解釋一下嗎？我認爲，後面的處理是一種分析類型的活動，其延遲並不重要，只有吞吐量很重要，對嗎？如果是這樣的話，Redis是一種矯枉過正的情況，你不覺得嗎？
您有沒有考慮在將數據轉儲到Redis之前壓縮數據？

從我的理解來看，你的問題是，你的數據總是結構化的，你的READ是非實時的，「耐久性」比你的延遲更重要。如果所有這些假設都是正確的，那麼mysql是一個安全的選擇。如果你碰到WRITE瓶頸，你可以考慮Sharding。

此主題將給你一個公平的想法。 Can redis fully replace mysql?

請務必記住，大多數NoSQL解決方案（包括Redis）速度都很快，因爲它們交換ACID屬性以提高速度。但就此而言，就我的理解而言，ACID屬性更重要。

來源

2014-10-19 16:19:11 KingJulien

隨着即將推出的3.0版本的Redis，羣集功能將準備好投入生產。看看http://redis.io/topics/cluster-tutorial以獲得概述。這不會直接有助於增加數據量，但我認爲這可以使您的設置更容易縮放/分片。

，你也可以考慮什麼是從Redis的移動「舊」數據到另一個系統，例如ElasticSearch與Redis的河的幫助：使用MessagePack可能

https://github.com/leeadkins/elasticsearch-redis-river

壓縮也有一個選項：

來源

2014-10-20 09:22:18 Tobi

從Redis的移動到MySQL是好主意嗎？長遠來看它將如何影響我們，因爲我們需要不斷更新我們的指數&分割方案以迎合巨大的需求。

如果您擔心由於需要將所有數據保存在內存中而導致託管成本降低，那麼我的投票是脫離Redis的，這可能是一個好主意。這並不一定涉及將所有數據從Redis移出，也許只是您關心延遲較少的歷史「較冷」的數據。將Redis的冷數據移出Redis的另一個好處是，遷移過程中發現的任何錯誤都可能會產生較不顯着的影響。

什麼其他數據庫（關係型或非關係型）適合這種用例而不是redis？

這是一個棘手的問題，沒有更好地理解您的使用案例。這就是說我認爲任何數量的可伸縮關係數據庫都可能足以滿足您的工作負載。我腦海中的一個關鍵要求是能夠根據需要輕鬆添加/刪除機器以進行擴展。個人最喜歡的是CitusDB，但有多種選擇。

移植到關係數據庫時需要了解的一個折衷方案是，在管理結構化數據時可能需要做更多工作，然後使用Redis關鍵/值存儲庫進行處理。例如，添加新字段可能涉及到模式更改。 PostgreSQL（和CitusDB）支持一些使這更簡單的半結構化數據類型，我相信還有其他關係數據庫具有相似的功能。

來源

2014-10-30 22:09:47 Ben

從redis切換到Mysql。好主意？

回答

相關問題