AWS RDS MYSQL寫操作每秒計數

我正在製作一個mysql表並編寫一個API來每秒接收和存儲1000個以上設備的數據。每臺設備將超過100個數據點推送到該PHP服務器。我正在測試360個具有10個數據點的設備，每秒處理3600個寫入計數，這是可以理解的。但是，我注意到寫入操作每秒計數隨着器件數量的增加而增加。我試圖谷歌每秒寫入數量的飽和點，但沒有找到任何。每秒有沒有最大寫入次數？如果寫入次數達到每秒10萬次，系統性能如何？是否有人在mysql數據庫專家請指教我，謝謝。AWS RDS MYSQL寫操作每秒計數

來源

2016-02-23 Phuong Le

你可能能夠找到一個基準，以顯示一些高數非常有限的測試用例。但也有太多的因素影響 '每秒寫入'：

紡紗驅動VS SSD，加上品牌等
RAID
成批插入/ LOAD DATA /單行插入/ MyISAM數據
數
BEGIN ... COMMIT/
併發性 - 無論是多寫，也同時的讀操作
設置：innodb_flush_log_ at_trx_commit，sync_binlog等
版本（5.6做了一些改進; 5.7做得更多; MariaDB的有一定的這些改進，加上其他人）
架構
客戶端和服務器爭奪資源
等

聽說呈現出萬的「交易」每秒5.7基準的。

但是，獲得100K是相當大的挑戰。以下是我建議：

SSD（可能存在於AWS;獲得最大IOPS）
RAID條帶（奇偶校驗疼一些，但可能值得擁有）
的MyISAM，因爲表鎖定的，可能如果你使用多線程插入，不是一個好主意。（我在本次討論的其餘部分假設InnoDB。）
您將如何處理數據？如果您不需要SQL來查看各個值，請將100個值存儲在JSON字符串中並將其壓縮到BLOB中。現在你可以悠閒地讀寫1000次/秒。
FusionIO固態硬盤可能會爲您做壓縮。我不喜歡InnoDB的自動壓縮。在客戶端執行卸載服務器。
索引：一旦你有大量的數據，索引的隨機更新會殺了你。設計PRIMARY KEY，以便插入可以「在表格的末尾」。
每批插入100-10K行 - 小於此數就會導致間接費用;不僅如此，導致撤消日誌等效率低下。
innodb_flush_log_at_trx_commit=2,sync_binlog可能並不重要，因爲配料。
5.7，可能MariaDB的10.1
如果有必要，移動客戶端（一個或多個）以分離的服務器。

至於如何快速收集大量數據，可能有多個線程，請閱讀我的"High speed ingestion"博客。它討論了一對錶 - 一個用於接收數據，另一個用於處理（標準化，壓縮，彙總）和鏟入事實表。

另一個問題......你試圖幾MB推入表中的每一秒;每天累計接近1 TB。你會保存數據多久？你有多少磁盤空間？如果你將刪除'舊'數據，那麼PARTITION BY RANGE是必須的。我的Partitioning blog詳細說明如何使DROP PARTITION和REORGANIZE PARTITION非常便宜地執行刪除操作。

這導致了另一個建議 - 處理數據，但不保存它。好的，也許你需要一小時的數據來處理。在這種情況下，所有上述討論仍然適用（除了INDEX限制）。而我的高速攝取可能仍然值得做。你可以每小時一次乒乓球。一個小時可能是10GB - 足以保存在RAM中，因此避免了I/O瓶頸。

來源

2016-02-23 16:37:56

非常感謝你們。這個答案幫助我噸......我盡我所能地使用關係數據庫來存儲歷史數據，因爲它有利於它，如果我將所有數據縫到blob那麼它沒有什麼不同，使用沒有SQL不是嗎？我想使用像max max全文搜索等sql函數，這真的有助於獲取數據查詢... –

還要考慮配置的RDS的底層EC2實例大小。

來源

2016-02-24 15:13:17

AWS RDS MYSQL寫操作每秒計數

回答

相關問題