Row Cache For Innodb

栏目: 数据库 · 发布时间: 5年前

  • 最近在做 MySQL 的优化,看到现在MySQL分表分库后导致的内存利用率较低的问题,进行了优化,如果你也有类似的问题,可以试试下面的Patch
  • Patch下载:  http://code.google.com/p/row-cache-for-innodb/
  • 问题
  • 当一个MySQL存不下全部的数据时,那么分库分表是一种常规的解决方案.但是一旦分库分表之后,关系型数据库对应的关系实际上被弱化了,很多查询不得不转换为类似K-V的查询.一般情况下为了使分库分表的数据尽量的平均都采用去模(mod)的算法来分配数据,这样就导致热门数据也会很离散的分布在各个表的各个区段上,分布很离散.  而Innodb的Buffer Pool则是按Page(默认为16k大小)来进行缓存,那么可能热门数据只占16k中的2k甚至更少(对于辅助索引来说会更少,可能只有几百个字节),那么被载入到Buffer Pool中的数据会被读取的可能就很少了,也就是说Buffer Pool的内存利用率是很低的.
  • 解决
  • 既然是由于Buffer Pool无差别缓存一个Page导致内存利用率低,那么我们可以直接缓存row来提高内存利用率. 所以Row Cache For Innodb就诞生了. Row_Cache 在Buffer Pool之上再建一层缓存.在innodb访问B-Tree的时候判断索引是唯一索引,且查询条件是唯一查询的时候(就是典型的K-V查询)便会进入到Row Cache的查找逻辑中. 由于只缓存Row内存利用率会很高,即能缓存的热门数据会比Buffer Pool多很多. 按照压测的结果来看240w的热门数据(数据分布较离散) 使用18G的Buffer Pool是无法完全载入到内存的.导致随机select数据还会有大量的IO操作存在QPS维持在一个较低的水平.但是使用Row Cache后240w的数据只使用了5G内存就能全部载入到内存中,QPS能提升几倍
  • 额外收货
  • Row Cache使用Hash算法+LRU算法进行缓存数据的管理,所以将原来Buffer Pool中的B-Tree查询转化为Hash-Table的查询,使数据能被较快命中,节省了CPU使用也提升了响应时间
  • Row Cache中的Hash-Table管理采用区段锁而非Buffer Pool的单一全局锁,降低了锁竞争而导致的上下文切换.而且对LRU 和 内存池 也和Hash-Table区段对应,各个区段独立维护各自的资源
  • 适合的使用场景
  • 查询以K-V形式为主 类似 select * from table where key = ? 这样的查询,而且key字段需要建唯一索引
  • 读>写
  • 热门数据较集中,且基本都能放在内存中
  • Row Cache和handlersocket配合应该是不错的选择
  • 性能测试
  • 使用了淘宝某核心系统对Row Cache的效果进行了性能测试和稳定性测试.
  • 机器配置:
  • CPU:16核的Xeon(R) E5520  @ 2.27GHz
  • 内存:24G
  • 硬盘: 12个盘的RAID10
  • MySQL版本: 5.1.48版本使用innodb_plugin 1.0.9
  • 测试场景
  • 8000w的基准数据(实际Row不止,还有这些基准数据对应的扩展数据,路由数据,全部加起来有近10亿数据),240w的热门数据(相对基准数据而言),对热门数据进行随机访问和更新删除插入等操作
  • 读写比为100:1的混合测试, 这是比较典型的互联网应用
  • 测试结果(上图是只使用18G Buffer Pool的结果,下图为使用5G Row Cache + 13G Buffer Pool的结果)
  • 全部Statement的对比
  • Row Cache For Innodb
  • Row Cache For Innodb
  • 可以看到等稳定后 QPS是原来的3倍以上
  • 对update/insert/delete操作的对比
  • Update
  • Row Cache For Innodb
  • Row Cache For Innodb
  • Insert
  • Row Cache For Innodb
  • Row Cache For Innodb
  • Delete
  • Row Cache For Innodb
  • Row Cache For Innodb
  • 可以看到在使用Row Cache后对于Update/Insert/Delete这样的操作TPS也提升了一倍有余
  • 虽然Row Cache是针对Select操作的优化,但是当Row Cache为Select剩下大量IOPS之后,这些IOPS可以被利用到Update/Insert/Delete这样的操作上,间接是TPS也获得了提升.
  • CPU/Iowait对比
  • CPU
  • Row Cache For Innodb
  • Row Cache For Innodb
  • Iowait
  • Row Cache For Innodb
  • Row Cache For Innodb
  • 从CPU的走势可以看出当使用Row Cache后其命中率达到一定的层次后,IO资源会被释放,CPU占主导地位,由于使用Row Cache后QPS较高所以上图中CPU较高但相对BP而言,Row Cache将B-Tree查询转化为Hash-Table查询反而是节省了CPU资源,提高了响应时间
  • 缺点
  • 从上面的图可以看出,使用Row Cache后预热时间大大加长,由于Buffer Pool一次读进16k数据,而Row Cache则是一条条row进行读取,需要花较长的时间才能达到较高的缓冲命中率,从而才能发挥Row Cache的威力
  • 如果大家对Row Cache感兴趣可以到  http://code.google.com/p/row-cache-for-innodb/downloads/list 上下载patch来试用一把
  • 安装和使用说明见  http://code.google.com/p/row-cache-for-innodb/wiki/Installation

  • 以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

    查看所有标签

    猜你喜欢:

    本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

    Spring揭秘

    Spring揭秘

    王福强 / 人民邮电出版社 / 2009.8 / 99.00元

    没有教程似的训导,更多的是说故事般的娓娓道来,本书是作者在多年的工作中积累的第一手Spring框架使用经验的总结,深入剖析了Spring框架各个模块的功能、出现的背景、设计理念和设计原理,揭开了Spring框架的神秘面纱,使你“知其然,更知其所以然”。每部分的扩展篇帮助读者活学活用Spring框架的方方面面,同时可以触类旁通,衍生出新的思路和解决方案。 本书内容全面,论述深刻入理,必将成为每......一起来看看 《Spring揭秘》 这本书的介绍吧!

    HTML 压缩/解压工具
    HTML 压缩/解压工具

    在线压缩/解压 HTML 代码

    随机密码生成器
    随机密码生成器

    多种字符组合密码

    HEX CMYK 转换工具
    HEX CMYK 转换工具

    HEX CMYK 互转工具