[MySQL源码] Facebook对压缩表的改进

由于公司最近很多地方需要开始有使用压缩表的需求,但根据测试结果,压缩表对OLTP的性能相当不理想,在最近的一次测试中,UPDATE的性能最大可以下降到1/12,几乎不可接受。

 

Facebook2011年开始对压缩表进行改进,花了两个星期从facebook的博客、facebook成员在官方list上提交的bug以及Marklauchpad上提交的patch着手调研,以下内容基本涵盖了Facebook压缩表的改进,以及对应的Rev

接下来,需要做的就是研究这些Patch,如何为我所用。

 

注:除了以下内容,在查看facebook的bzr log时,还发现很多比较小的优化点(例如对innodb层线程调度的改进),但未公布出来,有兴趣的可以看看。

 

1.提供更多的信息来监控/诊断压缩表性能

MySQL本身(包括Percona版本)提供的压缩表内部信息非常少,很难通过这些信息来进行优化,Facebook增加了大量的信息用以显示。

mysql@facebook的代码来看,为table_statistics增加了大量的统计数据,包括IO、索引、压缩表相关信息,我们关注如下几个跟压缩表相关的信息:

COMPRESSED_PAGE_SIZE COMPRESS_PADDING PADDING_SAVINGS COMPRESS_OPS 

COMPRESS_OPS_OK COMPRESS_PRIMARY_OPS COMPRESS_PRIMARY_OPS_OK

 COMPRESS_USECS COMPRESS_OK_USECS COMPRESS_PRIMARY_USECS 

COMPRESS_PRIMARY_OK_USECS UNCOMPRESS_OPS UNCOMPRESS_USECS

另外在update_global_table_stats函数中,facebook做了一些优化,通过原子操作代替锁操作,避免长期持有全局锁 LOCK_global_table_stats

相关:r3668r3670r3678

扩展innodb_cmp表的信息 r3679

更多的global status信息 r3672r3671

 

2.redo log中移除压缩Page,并为压缩表增加了一种新的日志记录 r3641

 

3.增加adpative padding功能,减少每个page上的数据来降低压缩失败率

类似于在page上填写空白,当压缩失败率升高到某个层次时,加大pad值。当失败率维持在很低的水平时,则减小pad值。

动态padding实现 r3754r3759r3764r3768

线性算法计算自适应padding值 r3820

4.减少分配的空白页,以降低文件的大小

相关bug: bug#64673

r3814

 

5.减少压缩Pagemalloc/free次数

避免每次page 压缩/解压时频繁malloc/free 内存 r3808

 

6.更高效的压缩page checksum

对压缩page使用快速checksum r3824 related bug#49852

通过只在需要的时候计算压缩page/非压缩pagechecksum来降低cpu占用 r3816 , r3817 related bug#64170

 

7.移除对adler32的调用 r3818

 

8.允许设置zlib的压缩级别

增加了新的参数innodb_compression_level来控制zlib的压缩级别 r3766

 

9. fix  bug#61341 r3675

 

10.其他

增加innochecksum工具对压缩表的支持 r3813

Fix bug#64258 可动态调整WAIT_FOR_READ r3792

跟压缩表相关,未具说明的bugfix r3779, r3780 maybe related to bug#61208

 

原创文章,转载请注明: 转载自Simple Life

本文链接地址: [MySQL源码] Facebook对压缩表的改进

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *