关于5分钟的理解

首先是5分钟的一个帖子：http://blog.csdn.net/pennyliang/article/details/5903181

 1987年，Jim Gray和Gianfranco Putzolu推出了著名的5分钟法则[Gray 1987]，他们通过内存，硬盘的性能以及当时的成本，给出了这样的公式：BreakEvenIntervalinSeconds =

(PagesPerMBofRAM /AccessesPerSecondPerDisk) × (PricePerDiskDrive /PricePerMBofRAM)。并由该公式得到了5分钟左右的近似值，因此做出这样的判断，如果一个数据的访问周期在5分钟以内则存放在内存中，否则应该存放在硬盘中。其中：

PagesPerMBofRAM：表示内存每兆字节的Page数，如果page size = 4KB，则该值为1MB/(4KB/page) = 256 page/MB。

AccessesPerSecondPerDisk：每块磁盘每秒支持的最大IO请求数，如下表所示为250Page/(Second*Disk)。

(PagesPerMBofRAM /AccessesPerSecondPerDisk)：表示1兆的空间通过磁盘访问的方式所需要的秒数。256/200 = 1.25(Second*Disk)/MB，表示1兆字节需要1.25个盘秒来完成（类似工作任务按人月来做单位）。

PricePerDiskDrive：表示一块磁盘的成本，如下表所示为48$/disk。

PricePerMBofRAM：表示每兆内存的代价，如下表所示为50$/(2048)=0.024$/MB。

PricePerDiskDrive/ PricePerMBofRAM:表示用来买磁盘的钱可以买多少兆内存。48/0.024=2000MB /disk。

(PagesPerMBofRAM /AccessesPerSecondPerDisk)* (PricePerDiskDrive/ PricePerMBofRAM):表示用磁盘读取的耗费时间界限，2000MB *1.25=2500second，合41min。如果一条数据的访问周期低于41分钟，则应该放在内存中，否则应该放在磁盘中。

对于这个公式我们可以这样理解。

1MB 永久存放在内存中的代价是0.024$/MB，1MB数据使用一次相当于花0.024$换来的。

1MB 存放在硬盘中的代价是 1.25 (second*disk)/MB *48($/disk) / 1个访问周期 = 1.25 *48/2500= 0.024$，1MB数据放在硬盘中，2500秒访问一次，花0.024$。

如果访问周期小于2500秒，放在硬盘中的代价大，周期大于5100秒，放在硬盘中就赚了。

不难计算，如果将固态磁盘看作内存，则可得到48/(780/(32*1024))*(256/200)/60=43分钟。如果将固态硬盘看作硬盘，则可得到780/(50/(2*1024))*(256/35000)/60=4分钟，这是对5分钟法则的很好的近似。另外修改每页的大小，也可以近似得到5分钟这个值，请读者自行计算，[Goetz Graefe 2008]对该问题在2008年做了回顾，得到的结论是：5分钟法则在提出的20年后依然有效，但分化出两个5分钟法则，一个是把闪存看做硬盘，内存和闪存之间依然保持了5分钟法则，另外一个是在更大的page size情况下，闪存和硬盘依然保持了5分钟法则。并且对内存和磁盘的分界时间预测在未来的20是年将会达到5小时左右。

下表数据来自amazon.com, [Intel flash],仅作举例之用。

 

项目

内存（现代某服务器单颗内存）

固态硬盘（Intel某SSD）

硬盘(希捷某服务器硬盘)

价格

50$

780$

48$

容量

2G

32G

500G

其他

服务器一般至少8个以上的内存插槽。

固态硬盘因品牌不同价格差异较大。

4KBpage情况下，35000(IOPS)

 

4KBpage情况下，200次IO/second

备注

 

SSD读和写差距较大。举例使用的读取的IOPS来进行计算。

这里的每秒IO表示随机读写的情况，顺序读写一般可达30000次左右。可以使用HD tune，Iometer等工具进行测试。

在工作中实际接触的服务器可以支持最大单核16G内存，64个扩展槽，达到1TB的内存，但在举例过程中，仅考虑基本情况。有兴趣的读者可以根据工作环境的服务器情况做相应计算，看看得出的结果。

 

五分钟法则有哪些具体的应用呢？搜索引擎的索引非常巨大，每次上线过程都要经过很多步骤，其中一条叫做cache warming，即对那些常用的查询词，人工的对索引系统发起一次查询，使得在硬盘中的索引能够“上浮”到内存中，这样在下一次真实用户来查询时，无需磁盘读取，而直接从内存中读出，那么将多少常用词载入到内存中呢？什么样的查询频率的数据值得载入内存中呢？

事实上，计算机硬件发展到今天，CPU是最快速的，内存的发展次之，最慢的是磁盘，因此体系架构也需要考虑硬件发展的现状，结合五分钟法则和运营成本的考虑，查询频率达到一定频繁程度的查询词的倒排表可以放到内存中，否则应该放在内存中，一般那些诸如电话号码查询，邮编，生僻姓名的查询词通常都在磁盘中，而常用的娱乐明星的姓名，影视歌曲等查询词的倒排表都被事先载入了内存。

除此之外，五分钟法则还可以用来根据业务需要，来指导硬件采购，一些数据库提供商往往能够通过一些科学方法来为客户的实际业务需要来配置最优的服务器。

【推荐阅读】

[Goetz Graefe 2008] The Five-Minute Rule 20 Years Later, Communications of the ACM
Vol. 52 No. 7, Pages 48-59 ,http://cacm.acm.org/magazines/2009/7/32091-the-five-minute-rule-20-years-later/fulltext

[Gray 1987]Gray, Jim; Putzolu, Gianfranco R. (1987), "The 5 Minute Rule for Trading Memory for Disk Accesses and The 10 Byte Rule for Trading Memory for CPU Time", Proceedings of the ACM SIGMOD Conference, pp. 395–398 

 

 

一下是另一个人对5分钟原则的理解：http://wuyu.zju.blog.163.com/blog/static/11032200992762916605/

在与wy师兄的一次数据库设置讨论中了解到了5分钟法则。近日抽空去看了下，不得不感叹，没看之前，要我去分析IO系统的性价比，绝对是无从下手呀。Jim Gray几个简单的假设后，就把整个分析过程剖析成了一件很straight forward的事情。

本文不具体谈5分钟法则的本身，而是谈一下看完5分钟法则后，我对多级缓存系统的一点理解。首先来看5min法则20年版中的一张经典表格：

在使用5min法则前，必须首先明确一个大前提——我们买内存，买硬盘到底是为了干啥。When you buy RAM, you pay for size, but when you buy disks, you pay for I/O performance.在IO密集型的作业中，系统设计师必须非常清晰的了解到，系统的两个瓶颈分别是内存的大小，以及磁盘的IOPS。除此之外的因素都是次要因素。

以一个80%缓存效率，实际磁盘访问约10MB/s的IO应用为例。那么，我们可以计算出不同的page size下的内存（or闪存）大小应该是：

Page size1KB4KB16KB64KB256KBRAM-SATA210G52.5G13.2G3.3G880MRAM-Flash25G8.8G4.6G3.7G3.4GFlash-SATA322G80G20G5.1G1.4G

（1）如果是一个RAM-SATA的单一系统，那么，对于一个普通服务器（一般不超过8G内存）来说，为了最经济的完成这个应用，应该选择64KB以上的page size。

当然，对于不少系统来说，page size只是一个软件参数而已，可以很容易的调整。那么，问题到此就结束了。

但是，对于一些特殊的应用，比如闭源软件无法调整page size，比如MYSQL（innodb BTREE默认为16KB的page size，调整这个数值需要重新编译MYSQL，并且修改page size后，MYSQL稳定性堪忧）等等，page size不是那么容易调整的。这个时候，多层次的缓存系统就派上大用场了。

（2）对于一个RAM-FLASH-SATA的2层缓存系统来说。4KB以上的page size，就能在RAM-FLASH子系统中达到经济性，同时，在FLASH-SATA系统中，由于page size可以很容易的调整，那么1.4G的FLASH就足够了。

（3）即便是最极端的情况，page size必须固定为4KB的情况下，3层缓存系统也能仅仅使用8G的RAM，加上80G的FLASH来轻松达成最佳的经济性。而一个RAM-SATA的单层系统，则需要恐怖的52G内存才能达到最佳经济性。

到这里，我才终于明白了看似不起眼的1G/2G讯盘的意义：对于一个IO密集型的系统，这1G/2G的讯盘是多么的经济——当然，普通PC可能根本用不上它:P。

最后，再提一下系统设计中的page size问题。看了上面两个表格，可能有的同学就要想了，“嘿嘿，那么设计系统的时候，应该一律把page size设置到256KB以上”。我的评价是，这样的设计很有前瞻性，也许10年后确实是这样的：）但是，设计一个系统的时候，你必须考虑的另一个问题是响应速度。在SATA盘上，4KB的page size意味着15ms（寻道等待）+0.1ms（传输）的响应速度；而256KB则意味着15ms+6.4ms的响应速度，相差40%。对于FLASH来说，更是4KB=0.1ms+0.1ms，256KB=0.1ms+6.4ms， 64倍的响应速度差距。

因此，如果IO密集型系统同时也是一个对响应速度有要求的系统的话，那么page size不宜过大。而如果是一个批处理系统的话，为了达到最好的经济性，page size可以设置为很大。比如google的GFS和hadoop中，block size默认是64MB。

本文网址:http://b.imwuyu.com/?p=10004