阅读代码，画图，然后重构，单元测试……搞定了数据库部分。

　　被数据结构的细节所纠缠。由于性能原因，无法使用通用数据库平台，只能自行开发一个数据服务。用各种酶在不同修饰条件下，对几十G 蛋白质数据进行酶切，得到肽离子，建立索引（即使最小的库，都有将近九千万条，而且每新增一种酶或修饰，数量还要翻倍），然后用文件映射方式，通过共享内存提供服务。

　　其实我很欣赏系统最初的体系结构设计。但是由于1.5版deadline很紧张，老板施加了巨大的压力。为赶进度，工程师编程顾不上接口和重构，产生了大量的耦合和拷贝，弄得整个架构动弹不得。我接手后，只好回过头用几倍的时间阅读和重构代码，何苦呢？

　　彻底重新设计了数据访问类，用一个纯虚父类做接口，隔开其他部分。每种具体实现方式作为一个子类，比如目前读取共享内存的代码。还打算把1.0版不通过索引的数据访问方式代码也移植过来，实现另外一个子类，提供给系统内存小于1.5G的用户。

　　固定了接口，新版本就可以再实现其他数据访问方式，比如通过关系型数据库和Web Service提供数据服务。用关系型数据库的话，为保证效率满足Web应用，就必须用集群或网格了。这种情况一般都考虑Oracle，但涉及到老板的银子……听说Google采用MySQL，很希望知道他们的方案。

　　今天跑通了单元测试案例，用的是马（Horse）的蛋白质库，不加任何修饰。Debug版访问所有肽链一遍，2.266秒。以前还真没对付过这种级别的海量数据。

BTW：早上去了趟所里，玩了玩曙光3000，酷。