关于缓存文件格式（单文件文件柜）是否适合使用伙伴算法的讨论

本文来自李明子csdn博客（http://blog.csdn.net/free1985），商业转载请联系博主获得授权，非商业转载请注明出处！

本文成文于2010年11月，背景是笔者所在的GIS产品开发组对资源缓存文件（单文件文件柜）的文件格式选型出现分歧。当时，一部分开发人员提出希望新版的数据引擎基于Linux伙伴算法作为文件格式分配存储，而包括笔者在内的另一部分开发人员坚持沿用原有的基于索引的链式存储文件格式。本文即为笔者当时用于表达自己的观点。遗憾的是，经过项目经理决定，最终采用了基于伙伴算法的文件格式。后来，测试人员采用各种样本对笔者基于两种格式实现的数据引擎的存取效率进行了测试，测试结果显示伙伴算法并无明显优势。以下为讨论正文。

伙伴算法作为Linux的内存换页算法有着成功的应用，但它的使用有着一定的局限性。下面我将逐一结合我们的实际应用进行说明。
一、 硬件限制
伙伴算法速度较快的原因之一是硬件相关性极高。因为内存的访问速度和总大小的限制，致使该算法在硬件实现上与逻辑设计相差相对很小。比如在设计时的两块（或一个块的内部）逻辑层上相邻，所以访问快。在硬件实现中，这两个逻辑相邻的块实际上很可能相邻，即便不相邻其访问速度也不会相差很多。而在文件系统中却不是这样。即便逻辑相邻的两块，在硬盘中也可能分布在不同的扇区。所以，该算法在硬盘中使用的效果是有限的。
二、 适用性
不管什么算法或者格式关键在于是否使用当前系统。将一个高级算法应用于普通应用显然是不合适的。按照原有的“索引定位块首->读取块信息->读取下一块位置……”的方式，读取数据的时间主要依赖于文件的大小（块数），即“读取一块信息，定位到下一块”的次数。我在本地（CPU E8400）做了测试，读取10万数据块的时间为188毫秒，如果以4K（当前默认）为每块大小，那么这个数据量为390M。我觉得已经明显满足了当前需求。
三、 惯例
我翻阅了一些文献，并向其他的有过文件系统设计的工程师进行了咨询，发现大多数主流文件（rar,zip,flv等）在数据文件处理上主要按照“有无索引”、“是否分块”、“块大小是否固定”进行搭配组合形成文件格式，即便是“无限级索引”这种较罕见的格式也没有超出以上所述范畴。当然采用以上惯例除了习惯和已述原因外还有以下原因：
1、 文件转换。当文件在有需要转换为其他格式时，应该提供的是《文件格式说明》，这种不能包含算法的格式说明文档，否则即为“违例”。即便不得不包含算法特征的压缩文件格式都在尽可能将数据与算法进行剥离。在我过去参与的某个项目中，因涉及多个公司同时使用一个文件格式，这点被作为设计原则中的第一条。
2、 功能扩展。无论封装SDK给用户进行扩展还是我们自己进行功能扩展，如果一个文件格式不单单是数据的集合，还掺杂着复杂的数据访问方法，那它的扩展性就非常有限，甚至在格式修改前不能扩展。
四、 分组
在内存中，申请空间的大小相对随机。从一个字节到十几兆都有可能，并且几率曲线趋于平滑。但在我们的系统中，各种资源文件的大小级差并不大，并且每种级别的文件数并不均匀，存在着一定的分布规律。
五、 额外时间开销
伙伴算法的最大缺点就是额外的时间开销。因为它要不断的分割融合存储区，对链表进行操作，所以对于频繁改变（主要是删除）的操作带来的时间开销是不能忽略的。

以上是我根据个人经验和本周检索资料后提出的一些个人观点，尽供各位同事参考。作为数据引擎的主要开发人员，我会根据项目组的最终决定将其实现。在实现层，以上探讨过的文件格式相关操作只有代码行数和可维护性的区别，没有技术难度的区别。