2012-09-11 55 views
0

我們的MySQL數據庫中有很少很大的表(3個表,每個2〜5 GB)。我們運行物流應用程序,將路線,時間表,容量,位置,價格規則等實體組合在一起,而那些巨大的表格包含來自所提及實體的「連接」數據。MySQL巨大的表,遷移到NoSQL的性能改進?

我們必須擁有這些表格,因爲在線運行JOINS會完全消除性能。我們確實有索引;),緩存機制,有效的準備好的語句,正確的事務管理設置,但性能不足(〜數千客戶,〜數百或VIP客戶)。

我們的客戶正在做的大多是99%只讀操作,如搜索連接,日程安排,定價,然後有時會有UPDATE/INSERT操作的一些1-2%,如預訂一些旅程,容量等....

我們的想法是使用一些無SQL數據庫(propably的MongoDB)作爲第二個數據庫,我們會把所有預生成只讀數據到一些鍵值或樹結構。我們相信性能會更好,這個解決方案的訣竅是什麼?你有這樣的任務的個人經驗嗎?

我們計劃製作快速原型,但沒有人真正體驗過NoSQL。

+0

你有多少_rows_;它可能是你的數據庫的大小很大,因爲你正在存儲大量的數據;但行有所不同。您是否已經在統一表上運行['EXPLAIN'](http://dev.mysql.com/doc/refman/5.0/en/explain.html)以查看您的查詢性能?對於只讀表格,最好添加索引(甚至是組合索引)以加快查詢速度。讀/寫表上的大量索引會降低寫入性能,但在只讀表上,它們提供了良好的性能優勢。一旦你有了這個,那麼它更容易評估其他解決方案。 –

+0

在這些巨大的桌子裏,行數大約在8〜19百萬之間。我們確定了導致最痛苦的TOP 20查詢,我們對其中的一些進行了優化。 –

+0

你是否已經消除了硬件瓶頸? –

回答

1

當你的數據模型中有很多連接數據時,那麼MongoDB肯定是而不是是正確的選擇,因爲它不支持連接。您對數據模型的描述並不多,但是當您可以將大多數數據嵌入到其他實體中而不是存儲在單獨集合中的方式進行轉換時,MongoDB可以爲您工作。歸功於分片和副本集合,它可以很好地擴展,尤其是對於寫入訪問。

還是你考慮用Memcached緩存三個巨大的表? 3 x 5 GB = 15 GB - 這對於服務器保存在內存中並不多。

2

你們所有的人都應該熟悉memcache的k-v結構吧? 站在你的團隊中,NoSQL可以被認爲是存儲的memcache。 您可以使用memcache將數據重組爲NoSQL。

然後你會發現所有的事情變得容易。

總之,忽略高級功能,邁出第一步。