数据库 = PAYLOAD + INDEX
以上不是公理, 却是更好的了解数据库的一个新视角
提问者的数据库设计方案, 有点类似大神Bret Taylor(FB ex-CTO)的一篇blog
http://backchannel.org/blog/friendfee...
相信这种解决方法已经在frendfeed被验证过, 经得起考验
KV的编程的一条核心思想, 就是把那些需要query的东西, 变成已经存在的数据.
比如用户发的所有帖子, 以前需要按照user_id查询, 现在我们把帖子id放到users表的json里面, 那么一句查询(依赖索引)就变成了n条k/v的get操作.(请灵活运用)
我的个人建议, 无需一开始就使用key/value数据库, 但是将mysql设计的可以轻易的用kv数据库代替, 以提高数据库PAYLOAD部分的吞吐能力. 而在INDEX部分, B Tree算法没有过时, mysql就不会过时.
对于mongodb的复杂算法和实现, 我更加倾向于memcachedb/redis这种一句话就可以讲清楚自己在做什么的数据库方案.
总之, 解决问题的思想无需被范式捆绑.
多看一看别人怎么做的, 你的奇思妙想可能已经不是独一无二的了.