縮放寫強化應用程序（LAMP，MySQL）（目錄樣式應用程序）

我想知道是否有人因爲文件導入而在寫入密集型數據方面有經驗。縮放寫強化應用程序（LAMP，MySQL）（目錄樣式應用程序）

主要要求是業務用戶能夠導入表示主表之間關係的數據。他們應該能夠實時導出（儘可能）。

設置：

前端（PHP）應用程序寫入主數據庫上。
複製設置 - 主數據庫被複制到兩個SLAVE數據庫服務器。
SLAVE服務器之一被用作前端UI交互（重度查詢）的「讀取」數據庫。
同一SLAVE服務器也用於基於在前端預覽過的查詢「導出」數據。（很多JOIN表）。

主要的挑戰是複製日誌。即使他們已經導入的文件已經被處理，用戶也不滿意前端數據不可用的性能&。複製LAG是罪魁禍首。

轉向NoSQL即LONG Term的目標。現在仍然想改善性能。順便說一句，該應用程序在內部使用，但託管在一個知名的託管公司。用戶數量約爲150個用戶。

導入的數據大約是200k-800k行。每行代表一行。

任何投入，將不勝感激:)

來源

2010-08-04 rmartinez

你有沒有調查爲什麼滯後發生，我不知道實際是什麼滯後？ – Wrikken 2010-08-04 16:13:01

爲什麼要將「NoSQL」作爲長期目標？（完全披露，我對「NoSQL」這個詞提出質疑 - 擁有可與許多數據庫一起使用的標準化查詢語言有什麼問題？我可以欣賞那些希望爲Web應用程序開發和其他用途提供更靈活的數據庫的人，但問題在於，恕我直言，並不是數據庫支持SQL這一事實 - 數據庫的性能，建模和完整性特徵非常重要）你認爲你可以在非關係數據庫中更有效地建模數據？ – 2010-08-05 13:38:48

對於性能和可伸縮性，我們已將NoSQL（即MongoDB）視爲我們的LONG術語路徑。我們的數據非常簡單，可以在非關係數據庫中建模。數據量和數據可用性要求並不簡單。 – rmartinez 2010-08-06 02:54:41

@Wrikken，

（通過回答框接聽）

是，許多「刀片」和更新的。該應用程序利用臨時表（即具有某些前綴的實際物理表）來插入初步數據。並做了很多INSERT INTO .. SELECT * FROM ..

這導致大量語句被複制到最終臨時表被刪除的SLAVE中。我已經建議這樣的類型表應該從要複製的表列表中排除，而不是使用INSERT INTO ... SELECT * FROM應用程序應該只是從應用程序上的構建INSERT，UPDATE，DELETE語句中選擇一切內存空間並執行SQL語句。它應該減少被複制的臨時表相關語句的數量。

來源

2010-08-05 00:07:12 rmartinez

有很多因素在提高MySQL複製滯後性方面發揮作用。也許這播客約在Youtube上的MySQL複製通過他們的DBA可能會爲您提供一些提示&指針：

http://itc.conversationsnetwork.org/shows/detail3299.html

希望這有助於。

來源

2010-08-05 06:38:39

感謝Bug磁鐵。我會檢查這一個。 – rmartinez 2010-08-05 09:35:47

縮放寫強化應用程序（LAMP，MySQL）（目錄樣式應用程序）

回答

相關問題