mysql的数据压缩性能对比详情

这篇文章主要介绍了mysql的数据压缩性能对比,今天对这两种方式分别进行了测试,对比了二者在磁盘占用以及查询性能方面各自的优劣,下面我们大家一起进入文章了解详细内容,需要的朋友也可以参考一下

目录

  • 1. 测试环境

    • 1.1 软硬件
    • 1.2 表结构
  • 2. 测试目的

    • 2.1 压缩空间对比
    • 2.2 查询性能对比
  • 3. 测试工具

    • 3.1 mysqlslap
    • 3.2 测试query
  • 4.测试结论

数据魔方需要的数据,一旦写入就很少或者根本不会更新。这种数据非常适合压缩以降低磁盘占用。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中有这么一条:

?

1

2

3

4

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 一下:

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

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 结果:

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

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的数据压缩性能对比内容请搜索钦钦技术栈以前的文章或继续浏览下面的相关文章希望大家以后多多支持钦钦技术栈!

原文链接:https://www.tuicool.com/articles/fmMn6nn

版权声明:本文(即:原文链接:https://www.qin1qin.com/catagory/4388/)内容由互联网用户自发投稿贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 630367839@qq.com 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022-07-22 11:44:30
下一篇 2022-07-22 11:44:45

软件定制开发公司

相关阅读

发表回复

登录后才能评论
通知:禁止投稿所有关于虚拟货币,币圈类相关文章,发现立即永久封锁账户ID!