2 Data File:
[ Size ] 可以放在 Data File 中, 但需要推荐的做法是
(1) Offset (Location) + Size 存储在 CDB / Memory. (Index)
正常方法, 先从磁盘上读 Size, 这里隐式使用了 Kernel Readahead.
—没有看代码, 如果不是用下面的方法的话, 上面这句就说中了.
而显式使用 mmap / sendfile (), 因为文件, offset, size 均已知, 可以节省一次磁盘寻道 (SSD 不明显).
—你可能会说, 把 Index 中的下一条也读进来, 两个 offset 经过简单运算不就是 size 吗?
如果可行 & 不会有太大性能损失, 倒也是可以接受的.
(2) 如果没有数据恢复的需求, 去掉 Data File 中的 Size 字段.
(留着倒是也无妨, 如果非二进制数据居多的话也有一定的恢复作用, 应该用不上)

3 目标?
Worker 定位 —这是架构问题. 略
类似 memcached 的内存缓存 O(1). 命中则直接返回.
索引查询 O(1), 倾向于内存.
磁盘开 O_DIRECT, 一次磁盘查询.
(如果不用传统文件系统, 直接块操作则更好)

Reference & Thanks to:
LinkedIn Voldemort 简单介绍

雅虎的答案不令人满意,
而现在,
试卷交到了谷歌中国的手中.

即便人们普遍相信谷歌中国不会离开,
标题所述的方式, 也必是谷歌, 投资人与用户的共赢.

ps:
谷歌人的头脑是为了赚昧心钱而工作的, 对吗?

Ideapool v1 Features:
1 类 Wikipedia, 以条目为基本单位.
2 条目之间的联系由 Link 完成.
3 如果 A-B 间有联系, B-C 间有联系, 则 A-C 间也有联系.
添加 Link 时, 自动生成条目的其它联系.
使用一点点算法保证条目的联系数量大于等于 5.
(直连的 Link 永远显示, 即超过 5 个直接 Link 时不再计算其它 Link).
4 Link 需要手动添加 (严重的缺点, 非常不适合懒人).

Ideapool v2 Features:
1 以片断为基本单位. (Tweet 事实上也是片断)
2 一个片断就是一个想法, 可以包含文字, 链接… (参考 Tumblr ? 事实上 Twitter 也算是做到了)
3 条目的联系与聚合由树和 Tag/Keyword 完成.
树: 回复树, 参考 Plurk.
Tag/Keyword: 用 Twitter 的同学会用 #keywords 来标记一类 Tweets.

—
到这里可能觉得没什么.

继续:
4 Tags 可以像 Delicious 一样浏览和查询.
5 附加
用过的 Tags 自动识别.
如何实现 Links?
如果做成多用户系统?
内容管理?
6 目标
用户只需输入内容,再加一点简单的整理便形成一整套归类的知识库.

如果你考虑要实现一个, 使它更为易用是你的责任.

—

另一个项目的 idea 也写在这里吧.

背单词.

首先准备不同等级的阅读材料.
—材料从哪里来? 偶不管.
—用户在英文网站阅读也可以直接划段拿过来阅读.
1 划词 / 点单词出含义 (谁都会)
2 收藏 (同上)
3 阅读
如果这篇文章很简单, 单词你全都认识, 点 [ 全认识 ].
同理 [ 很简单 ] / [ 读不明白 ].
— 这里怎样使用户能够接受呢? 这问题留给你了.
4 猜你不会的词
从 3 收集来的数据要派上用场了. 读 n 篇文章之后再读某一篇, 你可以猜出用户不会什么单词了.
(或者根据已知的词汇表推不会的词)
这需要点算法, 看看贝叶斯相关的内容, 你会知道怎么做的.
此外需要注意词根, 名词识别, 拼写纠正等问题.
5 背单词
如果你不会做带算法的背单词, 那改做导出用户不熟的单词也是可以的.

ps:
这两个项目如果半年内真的没做的话, 偶要看看其他人做出来的效果. hoho.