关于Scalability的一些思考与疑问

标签: scalability 思考 | 发表时间:2013-02-08 00:35 | 作者:elar
出处:http://www.cnblogs.com/

自从看了scala以后,一直在想着scalable program的事情。在google上搜索scalable programming,首先映入眼帘的就是wikipedia的scalability这个词条。

那么,scalability是什么?

wikipedia上给出的定义是“ scalability is the ability of a system, network, or process, to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth.”在这句话里面,我认为它提到了scalability出现的两种情况。

一是“handle a growing amount of work in a capable manner”,另一个是“to be enlarged to accommodate that growth”。

前者考虑的是如何制定行之有效的策略来满足因工作量/负载增长而出现的scalability的需求,后者考虑的是scalability的需求出现后,怎么满足/容纳这样的工作/负载强度(计算资源or存储能力上)。前者指的更多的应该是高并发下的算法负载,是否会因为并发数太高而导致算法失效或性能退化等。后者考虑更多的也许是硬件资源,如CPU计算能力、存储能力和网络带宽等。

在诸如存储、路由、网络这些领域,scalability对系统而言都是很重要的属性。就拿存储来说,如果通过增加存储设备的数量,就可以在一定比例上提高存储的容量的话,那么这个存储系统就可以认为是scalable的。但是,这种scalable是否有一个scalability的上限呢?虽然可以一直通过增加设备的数量来增强某个硬件方面的能力,但是这样的可扩展性是否存在退化的趋势,即当数量不断增加时候,可扩展性反而没有原来那么好了。如下图所示:

scalability该如何衡量呢?用什么样的公式计算,什么样的标准来做判断呢?硬件设备的scalability是否天生难逃退化的命运,怎样减缓这种退化趋势呢?

按照wikipedia上的说法,对于“软”性的元素(比如算法、路由协议、程序等),scalable意味着在高并发下它们依旧可行。这个比较容易理解,就像数据库的索引,低并发时候一条条数据查找也是可以的,但是高并发时,这个方法似乎就耗费太多时间了,所以可能需要更优的算法好让在高并发情况下,算法也可以在规定时间内做出相应,给出计算结果。

如果说,高并发是软性元素需要scalability的梗,那么硬件需要scalability的梗是否也是这个呢?

常见的硬性元素有计算能力、存储能力、带宽等。存储需要scalability的原因显然不止高并发这一项,大数据存储就是很好的另一个理由。计算能力也是一样,不一定高并发才需要计算的scalability,在时间和计算能力直接需要权衡时,也会喜欢计算是拥有scalability的,比如对某项计算,只要这一个星期能算法就可以,那么一台PC可能就足够了,但是对于同一个任务,如果需要一个小时内得出结果,那么就需要更多的设备并行计算以更快求解(假设该任务可以并行化的话)。那么,带宽呢?带宽要如何做到scalable?多插根网线?显然不是这样,这也是我想不明白的地方。openstack通过将compute、storage、network整合到一个平台上来进行资源的按需使用,它的network又是如何做到整合在一起的呢?我这个服务器带宽不够时,怎么获得更多带宽?是否还是得依靠电信商?

上面说的都是比较笼统的元素,比如存储设备、带宽、算法什么的。当scalable真切的跟我们程序员的工作结合到一起的时候,我认为它还包含一门语言的可塑性、可修改性和可再造性。对一个项目而言,理论上说做了详设以后,用什么语言实现都是可以的。但问题是,在显示生活中,我们往往是在一个既定的框架上进行开发,更甚者,我们是在修改一个已经存在的系统。这种情况下,这个框架/系统所使用的语言的可塑性就很重要了。有没有一种办法可以避免牵一发而动全身?有没有一种语言可以在增加模块间交流的情况下却不改变接口?数据结构能否从算法中解耦?太多疑问。

想要需求不变是不可能的。所以,对系统进行修改、更新是不可避免的。那么,对系统的更改为什么导致了复杂性的增加?是因为业务本身变得复杂,还是因为使用的语言本身也导致了系统复杂性的增加?业务复杂性的增加或许可以通过业务重组等方式来进行改进,那么由于编程语言的固有特性和不可变性带来的系统额外的复杂性增加是否有避免的方法呢?什么样的语言可以灵活的做出各种变化呢?语言又有哪些变化需要应对呢?在系统更改的过程中,究竟是什么东西被改变和增加,这些东西里面有没有一些是由于编程语言额外造成的?怎样才算是灵活的语言,需要满足那些需求?

 

 

 

本文链接

相关 [scalability 思考] 推荐:

关于Scalability的一些思考与疑问

- - 博客园_首页
自从看了scala以后,一直在想着scalable program的事情. 在google上搜索scalable programming,首先映入眼帘的就是wikipedia的scalability这个词条. 那么,scalability是什么. 一是“handle a growing amount of work in a capable manner”,另一个是“to be enlarged to accommodate that growth”.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.

动车追尾的思考

- David Ruan - 扬韬
1、两列运行的动车追尾,绝对属于重特大责任事故. 雷电导致前车失灵,已经是责任事故了. 前车失灵,信号没有外发,又是责任事故. 调度体系没有发觉列车失灵,也是责任事故. 后车没有察知前车失灵,还是责任事故. 最后,后车发现问题,紧急制动系统有没有用也值得怀疑,因为后车司机据说是人工制动并殉职于岗位的.

重新思考电子书

- Alex - 爱范儿 · Beats of Bits
Hart,“古登堡计划”发起人,2011 年 9 月 6 日去世,享年 64 岁. 从 1971 年 Hart 制作第一本电子书,启动“古登堡计划”开始到 2011 年,Kindle、Nook 流行,正好经过 40 年. 如今电子书阅读器、电子书变得越来越流行,在北京的地铁上,你会经常看见低头拿着 Kindle、Nook、iPad、汉王的人们.

《系统思考》读后感

- 章明 - 所有文章 - UCD大社区
经别人推荐(都忘了是谁推荐的了~),买了这本《系统思考》,看完前几章,发现这是一本非常好的书. 全书的精华也都在前面几章,后面都是一些具体的案例分析. 为什么必须从整体研究系统. 将系统分块通畅破坏了你所试图研究的系统. 如果你破坏了系统内的连接,你就破坏了系统本身. 更奇妙的是,很多系统表现出他们的任何组成部分都不具备的特征.

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

Google Reade关闭的思考

- - 猫星石 ~CafeNeko
关于google reader所引起的口诛笔伐已经看的足够多了,所以这里我并不想再去谈Google的这个决定正确与否. 我想说的是关于”后GR时代”的一些思考. 关于GR的好我已经听的太多,曾几何时我也是重度的GR脑残粉. 但是早在GR宣布准备关闭时,我一边看着GR里面永远也不会清空的条目,我就在想,我真的还是GR的脑残粉吗.

表单设计的思考

- - 腾讯ISUX - 社交用户体验设计 - Better Experience Through Design
我们几乎每天都会接触形形色色的表单,登录账号、填写信息以获取服务、发布内容等. 然而填写表单的过程往往不是特别愉悦的,我们需要消耗时间输入信息,点击提交,可能还需要等待审核;尤其是碰到较为复杂、流程长的表单,如果用户体验较差,很容易让人产生挫败感,在中途选择放弃. 那么,如何提高用户填写表单的效率,防止他们出错或中途流失,提升愉悦度及转化率呢.

谈CIO思考之重点

- - 人月神话的BLOG
在这里主要针对中大型企业有专门的IT部门和独立开发运维团队的情况,对于这种企业的CIO,核心的一些思考点在哪里,和常规软件企业又有哪些差异. 对于企业IT部门是成本中心,在开源节流上,利润中心的重要性和关注度还是远远高于成本中心,这也是很多企业IT部门往往不受重视的原因,CIO本身也没有太多的决策权,在本身没有太多独立开发能力时候更多仅仅是一个运维中心的角色.

推行TDD的思考

- - 简单文本
目前来看,推行TDD的障碍大约有如下几点:. 分析需求并进行任务分解的能力; 3. 将测试作为开发起点的开发习惯; 4. 开发人员的重构能力,包括如何识别坏味道和如何运用重构手法; 5. 单元测试的基础设施,尤其是测试数据准备;. 开发人员对于软件质量,常常偏重于软件的外部质量,体现在他们的工作效益上,就是被测试人员发现的缺陷数.