SSD,你真的需要吗?

qingran写了一篇SSD的blog,http://www.qingran.net/2011/07/%e5%a6%82%e4%bd%95%e5%86%99%e4%b8%80%e4%b8%aa%e4%b8%bassd%e4%bc%98%e5%8c%96%e7%9a%84%e6%95%b0%e6%8d%ae%e5%ba%93%ef%bc%9f/ 。我早从他那里听说了很多关于SSD的神奇传说,但是我一直想不通。

数据库的IO,可分为读操作和写操作。如果硬盘读的慢,那就增加内存,提高cache命中率。比如之前,我们的数据库cache命中率在99.99%以上,那么硬盘是随机读还是顺序读什么的根本不重要,除非对数据库的响应延迟有苛刻要求。至于写操作,大部分数据库的cache策略都是write behind而不是write through,写慢点也无所谓。事务在提交的时候,对log buffer有3种处理策略:立即写入硬盘并fsync、立即写硬盘、暂时不管。前两者的区别在于,是否容忍OS崩溃这样的事件。反正咱又不是做银行的事务系统,干嘛要求那么苛刻?因机器意外断电而丢失最近一分钟内的数据,大多数产品经理都能接受。而后两者的效率相差很小。所以即便每次事务提交都写硬盘,即便硬盘的写入延迟很高,只要能放心的相信操作系统帮我临时保管数据,那么这一切都不是问题。所以当我看很多人用SSD来存放InnoDB的log file的时候,我总想问,你真的需要吗?如果用SSD是为了提高读取速度,那先把内存槽插满吧,加到128G再说,或者想想,为什么数据访问没有呈现一定的本地性?

我拿perl写了简单的for循环,连接本地的mysql,随机更新一个3万行记录的表的某一行,测试结果是QPS总是停留在5000左右(单线程、长连接),此时mysql的CPU使用率到90%多了。所以我在想此时的瓶颈究竟在哪,不知道下一步该怎么做更细致的性能分析。

我发现hibernate的二级缓存其实是一个很有意思的东西。在数据库和应用层之间做一个本地cache,每次查询先找它要,查不到再去数据库要。即便数据库查询代价极小,这么做也很有意思。因为数据在数据库内都是以二进制流或者column的方式存储的,把它映射到object上,必然有一个序列化/反序列化的过程。对于一个TPS很高的应用来说,必须得像这样做row-level cache,而不是page based cache。但是我没用过hibernate的二级缓存,有没有谁试过把大部分内存都分给它?以代替数据库原本的cache。比如支持事务的二级缓存+MyISAM那样的cache策略。

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥