基础系统软件的价值

盛大推出云计算服务，看起来想做类似于Amazon AWS的IaaS。看了一下，结构化数据管理的功能很弱，只有最简单的Key-Value服务，只有GET/PUT/DEL，没有条件更新没有锁，没有扫描，这让我觉得很不靠谱。结构化数据管理是99.9%的应用都需要的，而基于盛大云这样简单Key-Value来开发应用是很麻烦的事。比如：
1、如果把多个实体属性拼起来，没法索引，效率也不高；如果分开，那经常得用很多个GET；
2、没有索引和扫描，各种数据列表都不容易，比如按时间/阅读次数/评论次数排序的文章列表，你要用一个KV来维护ID列表，这会涉及复杂逻辑（比如按阅读次数排序的列表就不好搞），而且还会数据不一致；
3、刚说到阅读次数，好把，基于盛大云要维护一个会被并发更新的准确的计数是不容易，很不容易，简单到文章阅读次数，评论次数，好友个数等等。因为没有条件更新和并发控制，你把值读出来，＋1再存回去，一并发就错了。

总之，这种最简单的Key-Value系统，我一直认为是对系统实现者来说是福音，但对系统使用者来说是绝对坑到祖宗的玩意。如果盛大云就只有这把刷子，没几个开发者愿意用。还好盛大云据说会推出MongoDB服务，这还算有点靠谱。

我越来越觉得这不是正确的做事方式。我觉得做基础系统软件，是希望能够让用户（也就是基于这些基础软件来做应用的人）能够很简单的做出正确、稳定并且高效的应用。很简单的做出应用是指开发效率高；系统不出错并且稳定，这几点是最重要的，高效是在满足前面这几点之后再追求的。系统常出错或不稳定，性能再高也没用，这点可能不用多说。但开发效率的重要性，是工作之后再深刻的体会到的。

做了5年系统，有一件事最失败。我们在DDB里支持了Master/Slave读写分离，希望对数据实时性要求不高的查询去访问slave。这样系统好伸缩，撑不住了加个slave就行了。唯一的缺点是slave上读不到实时的最新数据，可能晚个几秒。我们想几秒有啥关系呢，我写了篇博客，其他人过几秒钟才看到，这有毛关系？但这个功能作了两三年了，几乎没人用。开发者说，要用这个，代码得多很多判断逻辑，每个Dao都要加个参数标明能不能访问slave。这得增加多少开发成本，多出多少bug啊。进度这么紧张，系统正确性这么重要，你好意思再让他们用吗？后来我们被逼上绝路，硬是基于复制实现了系统的准在线扩容，这次大家都满意。这才是帕累托改进！

之前看Codd的图灵奖获奖感言，把关系数据库跟生产力扯到一起，觉得这哥们比较虚，上纲上线。Dijistra多实在，那么大成就，说是humble programer。这几年，看了不少真实的数据库应用，感觉Codd所言不虚。如果没有关系数据库，如果没有陈述式的SQL，没有ACID，开发应用不知道会复杂多少，系统bug不知道会多多少，开发人力成本不知道会增加多少。看基于RDBMS开发的应用，Service调Dao，Dao操作数据库基本上就一两条SQL，业务逻辑清晰无比。要是换成盛大云那样的简单Key-Value，复杂可想而见，基本类同Python和C的开发效率差别。

基础系统软件跟产品一样，首先要考虑的是用户的感受，而不是实现的难易或技术的先进。用户最需要的就是系统用起来爽，只要写几行业务逻辑代码，剩下的基础系统软件都帮他搞定。这样，开发效率才能上去，系统质量才能上去，在互联网领域竞争中才能领先。反之，即使基础系统软件稳定、可靠、性能高效，但用户在此基础之上没法直接写业务逻辑，得重复干系统层应该干的事，开发效率和系统质量都没法保证。像网易这样规模的公司，如果没有DDB、DFS，让开发者像用一个单机数据库和文件系统那样简单，那每个产品都要自己来分库、分表、分存储、搞索引，一大堆烦杂的事，花气力也一定搞不好。

搞系统的人喜欢做性能优化。性能优化了，自然是好的，但一定要明白系统的性能是个整体。如果为了让底层系统好实现，好优化，把底层系统的功能弱化，则底层系统的性能是高了，但却导致上层做了更多的系统性工作，反而导致系统整体来看更复杂，性能更差。这些工作，总是要做的。要么在底层系统做，由更专业的人做一次；要么在上层做，由不专业的人来做多次。哪种好一目了然，基础系统应该做多点。

所以一直对很多NoSQL系统、最终一致性不太感冒。虽然可伸缩性没问题了，但系统功能退步了，应用开发难了，这样的系统不会有主流市场。
NoSQL只有功能不断丰富到可与RDBMS相比、数据保证强一致性，我觉得才有戏。目前只有Google Megastore还凑合，开源的还都不行。选Key-Value/Entity不选关系模型和SQL、选最终一致性不选ACID，总感觉是做基础系统的人推脱责任。当然可以以此起步，千万不可以此为目标。那些吼吓ACID一定性能和可伸缩性不行的人，就相当于吼吓Java性能不行一定得用汇编，我觉得是主次不分。