mysql的數據壓縮性能對比詳情
數據魔方需要的數據,一旦寫入就很少或者根本不會更新。這種數據非常適合壓縮以降低磁盤占用。MySQL本身提供瞭兩種壓縮方式――archive
引擎以及針對MyISAM
引擎的myisampack
方式。今天對這兩種方式分別進行瞭測試,對比瞭二者在磁盤占用以及查詢性能方面各自的優劣。至於為什麼做這個,你們應該懂的,我後文還會介紹。且看正文:
1. 測試環境
1.1 軟硬件
一臺 64位 2.6.18-92
內核Linux
開發機,4G內存,4個2800Mhz Dual-Core AMD Opteron
(tm) Processor
2220 CPU。
MySQL放在一塊7200轉SAT硬盤,未做raid
;
MySQL未做任何優化, 關閉瞭query cache
,目的在於避免query cache
對測試結果造成幹擾。
1.2 表結構
2424753條記錄,生產環境某一個分片的實際數據;
分別建立瞭(partition_by1,idx_rank
) 和 (partition_by1,chg_idx
)的聯合索引,其中 partition_by1為32長度的varchar類型 ,用於檢索;其餘兩個字段均為浮點數,多用於排序;
autokid
作為子增列,充當PRIMARY KEY
,僅作為數據裝載時原子性保證用,無實際意義。
2. 測試目的
2.1 壓縮空間對比
壓縮率越大,占用的磁盤空間越小,直接降低數據的存儲成本;
2.2 查詢性能對比
壓縮後查詢性能不應該有顯著降低。Archive
是不支持索引的,因此性能降低是必然的,那麼我們也應該心裡有個譜,到底降低瞭多少,能不能接受。
3. 測試工具
3.1 mysqlslap
官方的工具當然是不二之選。關於mysqlslap
的介紹請參考 官方文檔 。
3.2 測試query
截取生產環境訪問topranks_v3
表的實際SQL共9973條,從中抽取訪問量較大的7條,並發50,重復執行10次。命令如下:
./mysqlslap --defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql --debug-info
4.測試結論
比較項 | 磁盤空間 | 耗時(秒) | CPU Idle | LOAD | 並發 |
基準表(MyISAM) | 403956004 | 2.308 | 30 | 15 | 50 |
ARCHIVE | 75630745 | >300 | 75 | 4 | 1 |
PACK | 99302109 | 2.596 | 30 | 22 | 50 |
根據上面的表格給出的測試數據,我們簡單得出以下結論:
- 針對測試表,
Archive
表占用空間約為之前的18.7%
,myisampack
後空間占用約為之前的24.6%;二者相差不多,單純從空間利用情況來看,我們似乎需要選擇archive
表; - 我們再看查詢性能,與基準表進行對比。無論在總耗時還是系統負載方面,50並發下的
pack
表查詢性能與基準表相當; 而archive
表在單並發情況下耗時超過瞭5分鐘 (實在等不瞭瞭,kill之)!
那麼,我們似乎可以得出結論,針對需要在線查詢的表,ARCHIVE
引擎基本上可以不考慮瞭。
為什麼這個測試過程中ARCHIVE
引擎如此地慢呢?
我們知道,mysql
提供archive
這種存儲引擎是為瞭降低磁盤開銷,但還有一個前提,那就是被歸檔的數據不需要或者很少被在線查詢,偶爾的查詢慢一些也是沒關系的。鑒於上述原因,archive
表是不允許建立自增列之外的索引的。
有瞭這個共識,我們拿一條測試SQL來分析一下不用索引前後的查詢性能差別為什麼這麼大。
在我們的測試SQL中有這麼一條:
SELECT c1,c2,...,cn FROM mysqlslap.rpt_topranks_v3 WHERE ... AND partition_by1 = '50008090' ORDER BY added_quantity3 DESC LIMIT 500
我們前邊說過,測試的這個表在partition_by1
這個字段上建立瞭索引,那麼,我們初步判斷在基準表和myisampack
表上,這個查詢應該用到瞭partition_by1
的索引; EXPLAIN 一下:
mysql> EXPLAIN -> SELECT ... FROM mysqlslap.rpt_topranks_v3 -> WHERE ... AND partition_by1 = '50008090' -> ORDER BY added_quantity3 DESC -> LIMIT 500\G *************************** 1. row *************************** id: 1 select_type: SIMPLE TABLE: rpt_topranks_v3 type: ref possible_keys: idx_toprank_pid,idx_toprank_chg KEY: idx_toprank_pid key_len: 99 ref: const rows: 2477 Extra: USING WHERE; USING filesort 1 row IN SET (0.00 sec)
正如我們所料,這個查詢用到瞭建立在partition_by1
這個字段上的索引,匹配的目標行數為2477,然後還有一個在added_quantity3
字段上的排序。由於added_quantity3
沒有索引,所以用到瞭filesort
。
我們再看一下這條SQL在歸檔表上的 EXPLAIN 結果:
mysql> EXPLAIN -> SELECT ... FROM mysqlslap.rpt_topranks_v3_<strong>archive</strong> -> WHERE ... AND partition_by1 = '50008090' -> ORDER BY added_quantity3 DESC -> LIMIT 500\G *************************** 1. row *************************** id: 1 select_type: SIMPLE TABLE: rpt_topranks_v3_archive type: ALL possible_keys: NULL KEY: NULL key_len: NULL ref: NULL rows: 2424753 Extra: USING WHERE; USING filesort 1 row IN SET (0.00 sec)
EXPLAIN 說:“我沒有索引可用,所以隻能全表掃描2424753行記錄,然後再來個filesort
。”你要追求性能,那顯然是委屈MySQL
瞭。
到此這篇關於mysql的數據壓縮性能對比詳情的文章就介紹到這瞭,更多相關mysql的數據壓縮性能對比內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- 詳細聊聊MySQL中的LIMIT語句
- Mysql 索引該如何設計與優化
- mysql查詢優化之100萬條數據的一張表優化方案
- MySQL復合索引的深入探究
- MySQL order by與group by查詢優化實現詳解