SQL以15分鐘的間隔插入大型MySQL表

Question

我對Web開發的大多數方面都非常熟悉，我認爲自己是初級程序員。當我想到應用程序擴展時，我總是很焦慮，並且想了解更多。讓我們假設一個情景。

我正在研究一個Web應用程序，該應用程序輪詢設備並以15分鐘的間隔讀取大約2kb的XML數據。這些數據必須存儲很長時間（至少幾年？）。現在設想這個Web應用程序有100個用戶，每個用戶都有這個設備。

10年後，我們正在談論數以千萬計的表格行。擁有100個用戶，我們有一個cron任務，即查詢每個用戶設備，獲取2kb的XML，並每隔15分鐘將其插入到SQL數據庫中。

假設我的查詢比較簡單，只收集必要的列，使用連接和避免子查詢，是否有任何理由不應該縮放？

Answer 1

假設我的查詢是比較簡單的，只需要收集列 ，使用連接，並避免子查詢，是否有這不應該擴展任何理由 ？

當你變大時，你應該將活動數據集放到內存數據庫（比光盤快），就像Facebook，Twitter等一樣。當他們沒有將活動數據集放入內存/擴大規模時，Twitter變得非常緩慢=>許多人稱這種失敗的鯨魚。這兩者都使用memcached，但如果你只是一個盒子，你也可以使用Redis（我喜歡這個）或APC。如果需要性能，您應該始終安裝APC，因爲APC用於緩存編譯的字節碼。

大多數PHP通過緩存PHP腳本 的字節碼編譯，以避免解析的開銷和 編譯源代碼的每個請求（其中一些或全部的甚至可能永遠不會被執行）加速器的工作。爲了進一步提高性能，高速緩存的代碼被存儲在共享的存儲器中並且從那裏直接執行，從而最大限度地減少了在運行時慢速讀取和存儲器複製的數量。

Answer 2

隨着表格變大，插入通常不會變慢，但索引更新可能需要更長的時間。在某些時候，您可能希望將表格分成兩部分。一個用於歸檔存儲，針對數據檢索進行了優化（基本上是對其進行索引），另一個用於處理較新數據的表格，針對插入進行了優化（索引更少）。

但一如既往，唯一可以肯定的方法就是對事物進行基準測試。用幾千行設置一些克隆表，並且設置一些具有數百萬行的表，然後看看會發生什麼。

Answer 3

您始終可以考慮使用partitioning按日期自動分割數據文件，並將較舊的記錄放到較慢的高容量磁盤陣列中，同時將較新的記錄（和INSERT）保留在高速陣列上。然後，您的索引版本只需要處理數據的一個子集而不是整個處理，並且應該快速進行（磁盤I/O通常是數據庫系統中最慢的部分）。