注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Inside MySQL

MySQL MariaDB InnoDB InnoSQL

 
 
 

日志

 
 
关于我

MySQL技术内幕系列作者, 网易杭州研究院MySQL技术经理, 擅长于MySQL performance tuning、troubleshooting、systems availability and scalability、capacity planning

网易考拉推荐

我眼中的flash cache  

2013-08-15 17:17:04|  分类: SSD |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
想到这个话题是因为昨天在微博上看到 @zolker 贴出了Facebook公司的数据库存储硬件的采购,可以发现Facebook公司从2010年时的机械磁盘,到2011年的flash cache解决方案,直到今天全部使用flash的存储。在这之前 @Fenng 也贴出过Facebook公司各类型应用的服务器选型,可以发现Facebook使用flash cache的比例已经在逐渐下降。同时,根据不负责任打听到的小道消息来看,淘宝公司的数据库硬件选型也更倾向于直接使用flash设备(SSD),而非flash cache的方案。
我眼中的flash cache - insidemysql - Inside MySQL我眼中的flash cache - insidemysql - Inside MySQL
 
然而,我看到的另一个新闻同样很有意思。希捷的一项研究发现,混合硬盘只要有8GB SSD,性能就不弱于纯SSD因为根据希捷的研究发现,只要不运行以数据为中心的应用程序,普通的办公电脑每天只存取9.59GB的不重复数据,所以8GB已经足够了。看下面的图片显示:
我眼中的flash cache - insidemysql - Inside MySQL
 
2011年Facebook flash cache的出现的横空出世还历历在目,淘宝宣称核心商品库迁往flash cache的声音犹在耳边。而现在flash cache似乎已经成为了昨日黄花,或许这就是整个IT行业的feature。但个人认为只要flash或者SSD的价格不能大幅降低,则基于flash cache的解决方案依然有其广大的市场

最近bcache已经被整合到Linux操作系统3.1内核,而在服务器市场sTec的Enhanced IO,LSI的Nytro MegaRAID DAS的集成flash cache功能的RAID卡,希捷的混合硬盘,苹果的Fusion Drive,整个市场依然对flash cache保持较高的热情。若能静下心来想想,或许能得到一丝答案。

世上公司千千万万,然能有Facebook、淘宝这样规模的却屈指可数。你的数据是否需要全部存放在flash上?就拿网易的云阅读的应用来说,我们自己设计了InnoDB的flash cache方案,并在线上跑了1年多的时间。通过观察发现,只需要非常小部分flash cache,就能使得数据库完全运行与SSD的性能之下。为什么?答案其实和希捷的结论差不多,那就是应用实际每天能使用到的非重复数据并不多,配置100G的flash cache完全能使得数据库运行的非常流畅。而在每天凌晨3点~6点的非高峰的时段,又能完全将flash cache中的数据刷回到磁盘。

为什么Facebook、淘宝需要更倾向于flash的存储呢?这和业务量有着很大的关系。他们每天需要访问的非重复数据可能大于flash cache的容量,这种情况下,flash cache会需要回刷磁盘,性能将会受到机械磁盘极大的拖累,响应时间会受到影响。这是cache系统的本质。但试问你的应用,每天的写入量能否有这么大?又或者你的应用是否是没有热点的应用,全随机的场景?so,it depends。

此外还有一个观点认为,加入flash cache层后,太过复杂,特别是在数据库层加入flash cache。对于这个观点,我同意50%。加入cache肯定对系统设计会增加复杂度,但是cache已经是一个非常成熟的解决方案了,例如CPU中的L1、L2、L3 cache,他们也是write back或者write through的模式。对于数据库层的flash cache实现来说,比如之前我写过的InnoDB L2 cache,较之CPU的cache实现要简单的多,这个patch的代码也仅在5000行左右。再看Facebook的flash cache,其代码其实也仅有6000行左右。flash cache的设计并不复杂,技术也都是现成的,问题在于使用时需要一些注意事项,而这可能是使用flash cache中会遇到的问题。例如网易云阅读使用了flash cache,每次在进行ALTER TABLE后cache的命中率会大幅下降,虽然有一些方法和手段来避免命中率的大幅下降,但是这多了一些额外的操作,对用户不够透明。这也是之后InnoDB L2 cache需要优化的方向,尽可能的对用户透明。而flash cache在数据库引擎层实现,可以得知大部分的信息。而对于使用write-allocate方式的Facebook flash cache来说,或许会存在一些困难。

flash cache不是万能的,也就是一种数据存储的手段。就和我之前的博客说的那样,flash适用于对响应时间非常高的场合,flash cache用于普通的应用,disk用于历史数据或者备份的存放。而像网易云阅读那样,从SAS 600G的存储架构,调整为100G SSD + 2T SATA是一个具有现实参考意义的案例

当然,对于采购部门、不差钱的企业,亦或是flash的销售来说他们肯定喜欢公司全面推进到全flash的存储,不过这牵涉到太多公司政治层面的因素,故不做深入的探讨。

——EOF——

PS: 欢迎关注InsideMySQL公众帐号
我眼中的flash cache - insidemysql - Inside MySQL
 
  评论这张
 
阅读(1807)| 评论(1)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017