本来觉得这个博客应该只关注于web技术，只讨论些wordpress，各种前端技术，乃至互联网公司发展方式的问题。但转念想来此博客关注度又不高，便违背SEO专注的精神也不会有啥流量损失。何况一个人还是把技术问题分在几个博客说也未免太夸张，这个博客既然是技术博客，自然应该什么技术问题都可以在这里畅所欲言。

于是决定把自己种种技术相关的文章都搬迁到这里，以丰富这个站点的内容，而关键的是要开始记录自己至今参加的第一个需要编码的多人合作项目历程。希望能够坚持每周写一篇，把从需求到设计到最后编码遇到的种种问题与思考都记录下来。

项目组由一个博士，一个准博士，包括本人在内的三个硕士组成。准博士算是项目负责人，但是具体经验不足，还是需要博士进行辅助。发过来的项目要求只有简单几句，概括说来就是实现一个key-value存储系统，key为两种定长，value只有8字节整数。总规模可以达到20亿条记录，10次找key只准1次io，最多利用总数据量5%的缓存。

这要求很是古怪，目前kv存储系统设计都会大量利用内存来做缓存，甚至很多都是所谓“内存数据库”。这里却对内存使用要求如此严格，但又要达到寻找key时90%的命中率，简直是不可能完成的任务。而且对性能还没有提成明确要求，已经可想见最终要求之苛刻。

调研从系统与测试方面进行，选择了最简单的hashdb与同样以节约内存闻名的tokyo cabinet，hashdb不到500行代码，自然只是大概学习一下。而就资料来看tokyo cabinet也只是面对千万级别的设计，在到达上亿数据时性能会急剧下降。

而后发现使用在工业环境的tokyo cabinet其实现居然如此简单，而且只能将数据存在一个文件中，很明显限制了最大存储的数据量，这彻底颠覆了本人对其的印象。测试下来自然性能也没传说中的那么牛，而且明显到达上亿级别测试结果不会好，一时全组陷入沮丧当中。

后来再多方考察使用TC做后端存储的flare等设计思路，才突然想到不应该将TC看成一个完整的系统，而应该视为一个最底层的存储引擎。这个引擎足够简单，但是足够好用，你可以在上面开发更多东西。一个文件并非对应一个TC数据库管理系统，而是只对应一个数据库，甚至一个表，比如可以将20亿数据拆分成几个TC数据库来存，这样就能存储在多个文件中(就是说DBA还得弄分片分表，TC使用类似innobase的file_per_table设置)，也就可以扩展最大存储数据量了。当然性能如何，能否满足本项目苛刻的要求又是另一个话题，但是工业环境下是可以这样使用TC的。所以工业环境下使用软件不应该被限制住思维，一个不够，多搞几个，完成任务就行。

回到项目上，显然TC的hash引擎设计使用mmap来进行性能优化不适合本项目，再看B+树引擎设计也同一般B+树类似，没看出特色来，所以架构设计方面仍然是一筹莫展，只期待下周的需求讨论华为方能够更明确设计目的与要求。老师自然不满意这种简单的设计，要求我们看看更先进的系统，但是能用的kv系统真的不多，Berkerly DB算是最大而全的吧，可以了解一下架构设计，但对项目感觉帮助不大。

说到需求讨论，本人准备了各种问题，从系统基于的设备到可靠性与可扩展性要求乃至是否并发访问，结果博士来了句“问这些不相关的干什么，其实对方真正只是要一个能够管理大数据量而同时节省内存的算法而已”，仔细一看发过来的需求，还真是如此。所以项目需求最需要明确的是这个系统是用来干什么的，如果是一个为了算法测试用的原型系统，考虑那么多工程问题干什么呢？也许是本人太想鼓捣个工业环境用的系统玩玩了吧，以致忽略了对方提出项目的真实目的。所以需求明确是最必要的，而问出系统使用验收的环境是更关键的。

chao

微信支付

支付宝