注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风轻扬

活着就是为了追求幸福

 
 
 

日志

 
 
关于我

关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术

网易考拉推荐

基础系统软件的价值  

2011-07-21 14:59:29|  分类: 数据库 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
盛大推出云计算服务,看起来想做类似于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性能不行一定得用汇编,我觉得是主次不分。
  评论这张
 
阅读(5825)| 评论(16)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017