本次對mysql做了單表億級數據量的壓測。
表的關系簡單,只有兩個int字段,user_id和company_id,且都增加了索引。
通過python腳本,隨機向同一個表隨機插入100W、500W、1000W-1E數據,并且記錄了每次插入數據所耗時間。
先來看下寫入數據的情況吧:
python腳本空轉:
空轉100W:0.14s
空轉1000W:1.74s
單次插入1000W條數據:295.11s
1000W基礎上再插入1000W,輪詢,直到寫入1E數據,記錄每次插入所耗的時間。
可以看到,隨著數據量的不斷增大,每次插入1000W條數據的時間還是比較穩定,上下浮動不大。
我們最終關心的是單表乙級數據量下,查詢速度能有多快。
下面是用python客戶端腳本模擬對1E條數據進行隨機查詢,隨機用的是python的隨機函數;機器資源有限,開發機是公用的,
所以也沒太敢占用太大資源來做壓測,并發用的Python的線程模塊。
本次查詢測試采用三種方法:
1、單進程對數據庫執行隨機查詢1000次操作,執行100次,記錄每次時間
2、并發1000、2000線程對數據庫進行隨機查詢1000次操作,記錄每次時間
3、用mysql官方軟件mysqlslap 對數據庫進行操作
第一種:單次查詢1000次的結果,跑100次,發現時間浮動還是比較大,這可能跟插入的數據散列情況有關,
user_id相同的數據還是有不少,20-100之間,線上業務出現這種數據的情況不大,所以,這些數據不影響最終結果。
第二種:并發1000線程對數據庫進行隨機1000次查詢,
1000線程:最慢時間8s,處理能力 125/s ;
2000線程:最慢時間10s,處理能力 100/s;
第三種:mysqlslap進行測試
開啟2000個線程,執行SELECT * FROM user_company_test_5000 WHERE user_id=7432查詢
平均處理時間8.76s,每秒能處理229個查詢。
用官方的mysqlslap進行測試,跟python腳本的測試結果偏差較大,
猜測原因有兩個:
1:mysqlslap 直接采用socket對Mysql進行連接,所以它除了 mysql處理時間和網絡請求時間沒有其他影響結果的操作
2:mysqlslap只能指定sql,沒有辦法隨機查詢數據,而測試表里面的數據分散不均勻,這也是一個原因。
mysqlslap的數據只能視為最好情況,但第二個python腳本則更接近生產環境,1000次查詢數據也是隨機查詢,
所以第二種能作為生產環境的依據。
再來看看批量查詢,IN 語句最多50個值
好吧,我只開了200個線程,最慢時間93s,最快時間46s,簡直可以用慘不忍睹來講。如果是批量查詢,
那就拆成多條語句來查吧。如果用IN ,必然會影響服務。
結論:跟dba溝通過,理論上每秒能夠支持5000次的查詢量是比較正常的,但我用mysqlslap對單表100W的數據量進行了
測試,2000個client 每秒處理能力也只有700左右,
從第二種數據上看,當單機client達到2000時,每秒還能處理100次左右的查詢,還是不錯的。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com