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!

推薦閱讀: