IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

基础系统软件的价值

风轻扬 2011-07-24 15:04:14 累计浏览 1,835 次
本机暂存
    盛大推出云计算服务,看起来想做类似于Amazon AWS的IaaS。看了一下,结构化数据管理的功能很弱,只有最简单的Key-Value服务,只有GET/PUT/DEL,没有条件更新没有锁,没有扫描,这让我觉得很不靠谱。结构化数据管理是99.9%的应用都需要的,而基于盛大云这样简单Key-Value来开发应用是很麻烦的事。比如:

    1、如果把多个实体属性拼起来,没法索引,效率也不高;如果分开,那经常得用很多个GET;

    2、没有索引和扫描,各种数据列表都不容易,比如按时间/阅读次数/评论次数排序的文章列表,你要用一个KV来维护ID列表,这会涉及复杂逻辑(比如按阅读次数排序的列表就不好搞),而且还会数据不一致;

    3、刚说到阅读次数,好把,基于盛大云要维护一个会被并发更新的准确的计数是不容易,很不容易,简单到文章阅读次数,评论次数,好友个数等等。因为没有条件更新和并发控制,你把值读出来,+1再存回去,一并发就错了。

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

    最近侧面了解到隔壁单位的一些消息,挺好玩。据说隔壁单位也有DDB,基本原理跟我们没区别,但功能很简单,稍简单的查询搞不定,分布式事务搞不定,有哥们了解到我们的DDB后惊呼:都是DDB,怎么差距这么大呢!但那边做系统的说这些复杂的功能不能提供,否则会被滥用,不能保证性能。还说有一些大P做一些系统,外人和主管看上去很牛,因为技术很先进。但用的人怨声载道,因为稳定性实在不行,两天必死一次。

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

    做了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性能不行一定得用汇编,我觉得是主次不分。

同分类推荐文章

  1. 使用deepseek进行Oracle恢复,引起重大故障 (2026-06-22 10:56:00)
  2. 接手一个只差临门一脚的数据库恢复 (2026-06-18 00:13:09)
  3. 我做了一个 AI 版的 StarRocks 升级风险扫描工具,直接帮我定位到一个风险 (2026-06-15 01:00:00)

查看更多 数据库 文章 →

建议继续学习

  1. HFile存储格式 (累计阅读 15,971)
  2. 如何成为OpenStack工程师 (累计阅读 15,957)
  3. hbase运维 (累计阅读 14,922)
  4. hbase介绍 (累计阅读 12,366)
  5. Facebook 网站架构 (累计阅读 11,111)
  6. MacBook Air与工作效率 (累计阅读 10,661)
  7. 基于Redis构建系统的经验和教训 (累计阅读 10,522)
  8. 腾讯php程序员面试题目答案 (累计阅读 8,972)
  9. Key-Value小数据库tmdb发布:原理和实现 (累计阅读 8,351)
  10. HBase技术介绍 (累计阅读 8,072)