对于大部分的应用来说,都存在热点数据的访问,即:某些数据在一定时间内的访问频率要远远高于其它数据。
常见的热点数据有“最新的新闻”、“最热门的新闻”、“下载量最大”的电影等。
为了了解MySQL Innodb对热点数据的支持情况,我进行了基准测试,测试环境如下:
【硬件配置】
硬件 |
配置 |
CPU |
Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 |
内存 |
24G(6块 * 4G DDR3 1333 REG) |
硬盘 |
300G * 3个,SAS硬盘 15000转,无RAID,有RAID卡,且开了回写功能 |
OS |
RHEL5 |
MySQL |
5.1.49/5.1.54 |
配置项 |
配置 |
innodb_buffer_pool_size |
4G |
innodb_log_file_size |
200M |
innodb_log_files_in_group |
3 |
sync_binlog |
100 |
innodb_flush_log_at_trx_commit |
2 |
【热点数据模型】
为了模拟热点数据主要存储在内存中的情况,使用范围查询将前20%数据作为热点数据加载到内存,例如:SELECT COUNT(*) FROM BT_KV_SHORT_INT_CHAR_10KW WHERE col1 < 20000000
项目 |
模型 |
表记录数 |
1KW(3G),2KW(6G),5KW(15G),10KW(30G) |
Key |
INT |
Value |
CHAR(250) |
热点数据 |
占总数据20% |
性能测试结果如下:
【查询】详细分析如下:
==>当热点数据小于Innodb buffer pool时(1KW/2KW/5KW),查询操作的性能很高,和表数据小于Innodb buffer pool时的性能相近;
==> 当热点数据大于Innodb buffer pool时(10KW),查询的性能下降明显;
==> 热点数据访问的总体性能优于随机访问;
【插入】详细分析如下:
==>当热点数据小于Innodb buffer pool时(1KW/2KW/5KW),性能随着热点数据的增长而逐渐下降,原因是当Innodb buffer pool接近饱和时,buffer管理需要进行更多的操作;
==>当热点数据超过Innodb buffer pool后(10KW),性能急剧下降,原因是磁盘IO已经成为性能瓶颈;
分析同INSERT。
【删除】分析如下:
==>和INSERT/UPDATE表现略微不同,当热点数据小于Innodb buffer pool时,性能变化不大,因为DELETE操作不需要生成新的Page,节省了buffer管理的操作;
==> 当热点数据大于Innodb buffer pool时,性能下降较大,原因是此时磁盘IO已经成为性能瓶颈。
【总结】
Innodb buffer pool采用LRU的方式管理和淘汰数据,根据LRU算法,热点数据都会优先放入内存,因此热点数据的测试性能比随机访问的要高出不少。
但热点数据超出Innodb buffer pool后,磁盘IO成为性能主要瓶颈,性能会急剧下降。
【应用建议】
实际应用中涉及热点数据访问时,Innodb是一个高性能的较好的选择,但前提是要能够预估热点数据的大小,只有当热点数据小于Innodb buffer pool(即热点数据全部能够放入内存)时,才能够获得高性能。
注:
测试数据只为对比用,不代表一般情况下MySQL的性能就这么高,因为为了能够对比,测试时做了很多准备工作,测试操作也是比较特殊的