- 浏览: 318485 次
- 性别:
- 来自: 长沙
文章分类
最新评论
-
完善自我:
支持一下!
揭秘IT人才特点:中美印日四国程序员比较 -
悲剧了:
好文,看玩thinking in java的提到的异常处理,看 ...
高效的Java异常处理框架(转) -
yin_bp:
开源框架bbossgroups页支持组件异步方法调用哦,详情请 ...
Spring 3中异步方法调用 -
flyjava:
sun的悲哀
Apache怒了,威胁说要离开JCP
可伸缩性带来的好处
从理论上来说,我认为有两种基本方式可使得系统具有可伸缩性这种至关重要的属性。一种方式是,在设计级别逻辑优化系统。您可以独立于任何软件工具和基础结构元素来考虑系统,然后在物理上建立系统。在实践中,这就意味着最大限度地减少瓶颈和关键资源的影响,同时在尽可能充分利用任务的内在并行性。 另一种方式则截然相反。您主要依靠某种硬件和软件组合的内置特性,而您的解决方案和创造性只发挥次要的作用。基本上,您将可伸缩性和互操作性的责任留给为了完成此任务而选择的工具。 顺便提一句,在前互联网时代,多年来人们一直在使用前一种方法,那时,大家尤其关心性能和强大的功能,似乎忽略了可伸缩性问题。(如果没有大范围的 Internet 互连,这确实是一个相对次要的问题。) 几年前,由于缺乏功能丰富、价格适中的集成解决方案,人们主要考虑的是设计问题,将注意力放在了数据库结构和各种运算的计算成本上。 目前的情况是,由于出现了价格比较便宜并且功能强大的硬件,使得优化和设计有效性在项目的整体管理中已经退居次要地位,可伸缩性独立于硬件的这种观点似乎占据了主导地位。 计算复杂性的黄金法则是:只有最快的算法才能最充分地利用速度更快的硬件。考虑可伸缩性问题时应该牢记这一点。
增长因素
不过,可伸缩性也可以说是抽象的。遗憾的是,可伸缩性并非一个您可以通过编程方式来打开和关闭的系统属性,您也不能以某种方式直接进行控制。相反,这是一种系统特性,它是基于所有其他特性、整体设计和实现以及所选择交互模型的组合的。 我们不可能利用某种监视工具或分析工具轻松地检测出分布式系统内在的可伸缩性级别。另一方面,一些实现方面的因素(关键资源是否充足、设计瓶颈、冗长但必不可少的任务以及操作的过分序列化)构成了有限可伸缩性的某种客观理由。 但是,如果未在真实工作环境下对系统进行压力测试,您就不能判断某个特定的系统是否具有足够的可伸缩性。 可伸缩性在某种程度上与性能有关,如果系统结构严谨,并采用了合理而周密的架构,就不会存在可伸缩性问题。 看到像可伸缩性这样看不见摸不着的系统特性突然成为系统性能下降的主要罪魁祸首,真让人感到惊讶。在设计组件时,您应该适当地考虑运算的计算成本,而且无论系统未来将怎样发展,您都要作好最充分的准备。 可伸缩性一直是一个影响系统增长的因素。简而言之,当前性能无法满足预期数量用户需要的系统就是需要增长的系统。如何才能在结构上提高这种系统的性能呢?简单地说,只要使用更强大的硬件或更好的硬件和软件组合就可以。 如今,这两种方法都已经用更具迷惑力、更加市场化的措辞重新表达了。以硬件为中心的方法称为向上扩展 。巧妙地结合硬件和软件的方法称为向外扩展 。 要控制系统的增长,请确保进行向上扩展或向外扩展。但同时要确保系统的能力一直保持提高状态。 可伸缩性,美妙的可伸缩性。这就是最合适的定义吗?
向上扩展
基本上,向上扩展系统意味着将一切的一切都迁移到更强大的新硬件系统的保护下。一旦新系统就绪,您就可以备份表和应用程序,然后进行联机了。这样对现有代码和系统组织结构的影响最小。
不过,不要以为向上扩展的过程很容易。向上扩展有不足的一面,其中有几个要点值得我们多加关注。首先最重要的一点是,向上扩展的系统存在单点故障,最终将受制于某种硬件限制。向上扩展通过使用更强大的计算机来提高服务器处理能力。单个硬件处理能力的增长有一个物理上限,虽然目前可能还无法预见,但总有一天会达到这个上限。
其次,接近此上限无论在时间上还是金钱上都需要相当大的成本(超过某个限度之后,技术可能需要发展几年,才能成倍地提高处理能力)。最后,但是也是重要的是耗电量和办公室空间。
这就是说,由于对现有结构的影响有限,向上扩展有理由成为首选方案。
向外扩展
与提高作为服务器的单个硬件的处理能力正好相反,向外扩展将提高系统的整体处理能力。向外扩展的系统本质上是模块化的,它由一个计算机群集构成。对这样的系统进行向外扩展,意味着向网络添加一个或更多额外的计算机。 在向外扩展的、高度分区的环境中,您应该使用一种更抽象的、独立于硬件的处理能力概念。总处理能力是由跨越各节点的数据和应用分区所调节的每个计算机的物理速度总和。 向外扩展对系统的增长没有任何限制,在这一点上,我们的确终将受益。不过,向外扩展在重设计和重实现方面需要投入大量精力。一直根据单服务器逻辑构建的系统必须经过重新考虑和重新组织,才能满足向外扩展的要求。 您必须确定如何对跨越多个 DBMS 服务器的数据进行分区。应用程序到数据的路径必须通过正确的执行计划周密地优化。对用户活动经常进行适当的、预防性的分析是在系统生命周期中优化系统的关键。 做到这些以后,您就拥有了一个几乎无限的系统,您可以在中间层以及数据层向系统添加处理资源,以满足不断增长的用户数量和工作负荷的需要。 注意,对于一个可伸缩的系统来说,问题的关键不在于期望的用户数量可以达到多高。真正要考虑的是,预期这个用户数量增长的速度有多快。用户数量的相对增长比绝对数量重要得多。 与构建一个目前有一百个用户、但预期用户数量将随时间的推移而急剧成倍增长的系统相比,为一个相对稳定的一亿用户群设计系统要容易得多。由此,您就可以理解为什么工业级电子商务 Web 应用程序对可伸缩性要求特别高了,这是因为这些类型的系统可能面临突发的大幅用户增长。
SQL Server 2000 如何向外扩展
可以肯定,向上扩展相对来说比较容易实现,至少对少量数据和用户来说成本相对较低,但从软件角度来看,到目前为止,向外扩展技术更有趣,更具有挑战性。如果没有在后端层运行的最新软件产品的帮助,您就不可能合理地进行向外扩展。 COM+ 和 Windows® 2000 中看到的群集模型就是一个向外扩展模型。业务层中的所有服务器都有完全相同的 COM+ 组件副本。然后,在后台运行的 Windows 2000 负载平衡服务根据各组件的工作负荷,负责将新的请求分配给这些组件。 从应用程序的角度来看,您看到的是一个实体 - 一组 COM+ 组件。您会基于这些组件来编写代码,而不必考虑运行这些组件的不同服务器的数量,并且可以忽略基础负载平衡器的作用。在这里,向外扩展就像添加一个安装了适当的组件集、配置齐全的新 Windows 2000 服务器一样简单。 在这个群集模型中,两个截然不同的实体互相合作:应用程序的组件和系统的负载平衡器。这样的模型不可能很容易地应用于数据层。实际上,您只有一个软件实体 - DBMS。 SQL Server 2000 支持另一个不同的群集模型,称为联合服务器 。这种网络使得应用程序可以看见所有正在运行 SQL Server 的一组服务器。所有这些 SQL Server 公共实例都是自治的、独立托管的,它们具有不同的表,甚至采用不同的设置。 DBMS 的主要工作负荷是数据。应用程序主要负责在多个服务器之间对数据进行均衡的分发。SQL Server 2000 本身提供内置功能,以支持跨多个服务器进行物理分区的可更新数据视图。 您可以决定使表分布在通过网络提供的多个 SQL Server 的实例上。您随时都可以根据需要将这些数据包装在一起。您可以通过分区视图 实现此目的,这是一种特殊的视图,它拥有 SQL Server 2000 运行时提供的特殊支持。
分区视图
分区视图适用于联合表 ,即跨越两个或多个服务器的关键表。联合表是通过一个名称为水平分区 的过程来创建的,这个过程将给定的表分为了更小表的联合体。从应用程序的角度来看,联合表就像一个单独的视图。 为了平衡工作负荷,成员表被放在各个不同的计算机中。它们的格式与原始表相同,但每个表只包含一部分行。成员表可以使用任意名称,但是为了增加位置透明度,建议您为这些成员表提供与原始表相同的名称。 构成表通常设计为包含相同大小的数据部分。这一特性是通过一个唯一的、不可更新的主键实现的。要确保完整性和一致性,您还必须确保没有重复的记录。为此,建议您对每个成员表执行 “检查” 约束。分区列不能为空也不能为计算列。 分区视图是包含分布式 “选择” 语句的普通视图,这些语句适用于结构相同的表,并通过 UNION ALL 子句将数据放在一起。
CREATE VIEW MyView AS SELECT * FROM Server1.Database.Owner.MyTable UNION ALL SELECT * FROM Server2.Database.Owner.MyTable UNION ALL SELECT * FROM Server3.Database.Owner.MyTable UNION ALL SELECT * FROM Server4.Database.Owner.MyTable
这种分布式视图必须在相关的所有服务器上创建,并且每个服务器都必须对于其他服务器显示为链接服务器。最好应将它们的 lazy schema validation 选项设置为 true 。该属性会确定是否检查链接的远程表的架构。如果将其设置为 True,SQL Server 则会跳过检查,从而使得性能提高。但这种特定的情况下,设置为 lazy 不会有丝毫的副作用。 分区视图最初是随 SQL Server 7.0 引入的。不过,随着 SQL Server 2000 的推出和一些重要性能改善的出现,它发展成为了向外扩展系统的重要工具。 在 SQL Server 2000 中,可以更新分区视图并且可以通过查询优化程序进行特殊优化,查询优化程序的目标是,最大限度地减少对跨服务器处理的需要。联合表的主要优点在于平衡可用服务器之间的工作负荷。只要所有的服务器都能在本地完成分配的任务,这无疑就是一个优势。 在以下情况下,分区视图可自动更新:
-
它是由使用 UNION ALL 子句将各个 “选择” 语句合并起来的结果而形成的。
-
每个 SELECT 语句对单个表工作(即不允许使用 JOIN )。
-
该表是本地表或链接表。
-
该表不包含时间戳列。
链接表必须使用以下任意一个可能条件进行引用:完全限定名(服务器、数据库、所有者、表名)、OPENROWSET 或 OPENDATASOURCE 函数。
针对可更新分区视图运行的 “插入” 、“更新” 和 “删除” 语句必须符合一些约束才能生效。例如,如果表包含一个标识列,则不能插入新行。您必须指定所有列,其中包括那些带有 “默认” 约束的列。如果该视图是自联接或与任何其他成员表联接的,则不允许进行更新或删除。
向外扩展的实践
SQL Server 2000 提供的群集模型并非适用于所有人。它是为高端 OLTP 企业系统,尤其是一些消耗资源较高的 Web 应用程序而专门设计的。 为了获得更高效率,它需要进行数据分区,而且分区必须遵循逻辑架构。所有相关数据都必须位于同一服务器上,并且必须能够进行逻辑拆分。 对数据的深入理解是绝对必要的。另外,随着时间的推移,数据的形式不应有太多变化。如果您知道它将发生变化,则应该预先了解它将来的形式,然后在规划分区时考虑到这一点。 在同一个节点上存放相关数据是可行的,否则您将很快在网络滞后时间中丢失使用精心设计的负载平衡策略所得到的内容。 完成数据分区后,即使您已经做得非常成功并且聪明过人,也只是完成了一半。实际上,将数据真正移动到选择的群集、安排备份以及监视解决方案还要靠您来解决。 与向上扩展相比,向外扩展技术确实难以实现并且是一种麻烦得多的方式。设计问题造成了一些实际的障碍,例如,缺乏将向外扩展群集作为单个实体进行管理的特殊工具。其中一些工具预计将在下一版的 SQL Server 中提供,代码名称为 Yukon。 向外扩展可伸缩性看起来前景很光明也很诱人,但是,在单个服务器上进行向上扩展在多数情况下仍然是最保险的方式。
向上扩展还是向外扩展?
事实上,第三代 Web 服务在硬件方面可能存在严格的要求。您原则上需要解决的问题是:向上扩展还是向外扩展?
向上扩展随着时间的推移会增强单个硬件系统的功能。而向外扩展则会使您的系统成为一个不断扩展的服务器场,该服务器场中包含的系统相互连接,但规模更小。
向上扩展的系统更有可能出现故障,内在可靠性较差,并且在超过某个阈值后不能进行升级。从耗电量、空间和价格方面来看,它也比较昂贵。另一方面,对系统进行向上扩展就像备份和恢复一样简单而无缝。
尽管处理单个机器总是比处理几十或成百个机器更好一些,但向外扩展的系统具有更高的内在可靠性和可扩展性,整体成本也更低。
然而,这两种方式的利与弊在某种意义上都是相对的,并且完全特定于项目。
向上扩展还是向外扩展取决于系统的性质。如果通过单个 SQL Server(可能在一个单独的多处理器计算机上运行)实例可以满足您的数据访问需要,向外扩展当然是首选方案。顺便提一句,这是 Web 场所使用的可伸缩性模型。
但是,Web 场向外扩展模型只是考虑水平可伸缩性的一种方式。如果您需要处理大量并发数据(例如,OLTP 系统),则可能需要多个服务器来协同工作,这就体现了“化整为零”这句古老的格言。在这种情况下,必须适当地重新组织数据。这个工作量非常巨大,不能随随便便就开始。在着手开始这样的项目之前,请确保您的系统已准备就绪,能够胜任如此海量的工作。也就是说,请确保可以将其当作 OLTP 系统使用。
做为一个一般的规则,尽管向外扩展看起来更有发展前景,但始终还是应该首先考虑向上扩展,只有在理由充分时才放弃向上扩展。
可伸缩性是发展的趋势
不管向上扩展和向外扩展技术的理论是怎样阐述的,有几点总是需要注意:
-
可伸缩性与计算复杂性有关,并且间接地与性能有关。
-
只有已经在任务的最佳计算复杂性和实现精力之间作出最佳协调之后,才能考虑是通过硬件进行向上扩展还是使用特殊的数据库服务进行向外扩展。
然而,据我所知,与改进算法、优化查询执行计划以及找到并消除瓶颈相比,采用速度更快的硬件总是要来得快些。这样还有助于按时完成任务。
对话栏:围绕 ADO 的争论
我的老板曾经问我:“ADO 和 ADO.NET 之间有什么区别?”我当时是这样回答的,ADO.NET 是我们最终要使用的另外一个数据访问层,还不了解其利与弊。我知道 ADO 代码在 .NET 中可以正常运行,但您有关 ADO 的各种文章搞得我头昏脑涨,不知到底是怎样的了。
我承认,乍看上去,很容易把 ADO.NET 想成“另外一个数据访问层”。但是再仔细看看,就不是那么回事了。对于在 .NET 下运行的数据处理应用程序,ADO.NET 是并且一直会是唯一建议使用的方法。
最近几年,我发现人们争先恐后地盲目使用 ADO,而放弃了经过优化和精细调整的 RDO 代码。可他们获得的却只有异常的结果。而只有可怜的 ADO 倍受责难。
同样,我敢说可怜的 ADO.NET 也将成为糟糕的迁移项目的替罪羊。虽说没有完美的代码,但系统代码几乎总是比你我的代码好。就是说,RDO 到 ADO 的升级可能有问题。为什么仅仅为了从 ODBC 升级到 OLE DB 以及更加丰富的对象模型,就要去更改那些运行良好的代码呢?
有了 ADO.NET 以后,情况就完全不同了。一旦您选择了 .NET 作为服务器平台,ADO.NET 就是您理所当然的选择。ADO.NET 是您能用于处理数据的唯一的类集合。
从技术上讲,您可以坚持使用 ADO,但您最终将在 .NET 到 COM 的转换上付出高昂的价格。ADO.NET 的关键在于,在开始真正的编码之前,您要学习这种技术并在一个受控制的环境中使用该技术。在迁移至 ADO 之前,有多少人这样做过?
对于今天这个由 Web 驱动的世界来说,ADO.NET 相对 ADO 而言是一个更合适的模型。同时,ADO.NET 对象模型已经在适当的、合理的情况下尽可能多地与 ADO 的概念保持了一致。要迁移到 ADO.NET,那么就从现在开始吧,您会发现学习过程原来如此简单快捷,简直令人难以置信。开发人员不必为了使用 ADO.NET 而学习太多的新概念。
但是,用户必须重置他们 ADO 式的思维框架,开始按照另一个模型进行思考。ADO.NET 绝不是“另外一个数据访问层”。您不必在 ADO 和 ADO.NET 之间进行选择。更大的决定是,您是否选择使用 .NET 平台。
原文:http://hi.baidu.com/mr_indigo/blog/item/466b38037ac14f074afb5177.html
发表评论
-
Qi4j和NoSql运动
2010-11-16 23:00 162524日一篇Qi4j and the NoSQL ... -
Threaded vs Evented Servers
2010-11-16 22:48 955Threaded vs Evented Servers ... -
BASE: An Acid Alternative
2010-11-16 21:13 983In partitioned databases, tra ... -
eBay 的Scalability最佳实践
2010-11-16 20:52 930用什么来衡量一天没 ... -
Scalability Best Practices: Lessons from eBay
2010-11-16 20:45 874At eBay, one of the primary a ... -
SmugMug 的架构介绍
2010-11-16 20:36 899本文介绍的 SmugMug 是一家提供付费图片 ... -
来自淘宝的架构经验
2010-11-16 18:07 1248日前参加了一场淘宝网 架构师黄裳带来的技术分享,在最后他 ... -
可伸缩性最佳实战
2010-11-16 17:50 607异步 同步调用使得组件和组件之间紧密耦合起来,这样就使得 ... -
伸缩性和可用性反模式
2010-11-16 17:48 740这篇文章讲了伸缩性 和可用性方面的反模式,也按照自己的理 ... -
使用qi4j实现DCI架构
2010-11-16 17:24 2933我曾经DCI架构是什么? 在一文中提到Qi4j框架实现DCI ... -
DCI架构是什么?
2010-11-16 17:07 2050DCI是数据Data 场景Context 交互Interact ... -
纵向扩容 vs. 横向扩容
2010-11-02 09:58 5440该文原版著作权属于Malc ... -
云计算在电信应用中的思考
2010-11-01 17:59 971云计算是在网格(Grid)、效用(Utility)和 ... -
真正的线性可伸缩性需要新的模式和中间件架构吗?
2010-11-01 17:27 978在构建线性可收缩应用 ... -
性能与可伸缩性的概念及其关键影响因素
2010-11-01 17:22 1157性能与可伸缩性常常决定企业应用的成败,尤其在 ... -
构建的可伸缩性和达到的性能
2010-11-01 17:19 1007实现伸缩性和性能调优的经验所保有的价值容易被低估。两者都是“晚 ... -
可伸缩性的最差实践
2010-11-01 17:02 796引言 在扩展大量大型 ... -
大型门户网站架构设计的可伸缩性
2010-11-01 16:34 910我们知道,对于一个大型门户网站来说,可伸缩性是非常重要的,怎么 ... -
可伸缩性设计
2010-11-01 16:27 1012好的设计是实现高度可 ... -
为性能和可伸缩性做架构和设计上的Review
2010-11-01 16:05 948部署和体系结构 ...
相关推荐
在现代信息技术的快速发展中,分布式系统作为构建大规模应用和服务的关键技术,其可伸缩性研究显得尤为重要。可伸缩性作为衡量系统在增长的工作负载或资源变化下能否保持性能和功能稳定的关键指标,它直接关系到系统...
VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB.NET可伸缩性技术手册VB...
在IT领域,尤其是在系统管理和架构设计中,"可伸缩性"是一个至关重要的概念。Windows操作系统作为广泛应用的桌面和服务器平台,同样面临着如何提供高效、灵活的可伸缩性解决方案的挑战。本篇将深入探讨"Windows可...
资源名称:数据访问宝典-实现最优性能可伸缩性的数据库应用程序内容简介:在当今的企业数据库应用程序中,性能和可伸缩性比过去任何时候更为关键,传统的数据库调整对于解决可能在这些应用程序中遇到的性能问题有些...
本代码实现了对MPEG2 SNR可伸缩性编码,可以作为理解SNR可伸缩性编码的入门。
可伸缩性是衡量分布式系统是否能随着需求和资源的变化而持续满足性能需求的能力。在计算机科学中,特别是在分布式系统领域,可伸缩性的概念至关重要。由于业务需求和技术环境的变化,分布式系统必须能够扩展其处理...
全书共分6章和2个附录,讲述了可伸缩性的规划、数据层、中间层、表示层,以及可伸缩性的测量等内容。 本书内容切合实际,适合希望了解如何开发可伸缩的企业级的应用程序的VB.NET程序员阅读。 本书英文原名为:...
全书共分6章和2个附录,讲述了可伸缩性的规划、数据层、中间层、表示层,以及可伸缩性的测量等内容。 本书内容切合实际,适合希望了解如何开发可伸缩的企业级的应用程序的VB.NET程序员阅读。 本书英文原名为:...
本文将深入探讨MySQL与Oracle在性能、可伸缩性以及最佳实践方面的比较,并通过代码示例来展示它们在实际应用中的表现。 MySQL和Oracle在性能和可伸缩性方面各有优势。Oracle适合大型企业和数据密集型应用,而MySQL...
《利用USL预测MySQL数据库可伸缩性》 在信息技术领域,数据库的可伸缩性是衡量系统性能的关键指标之一,它关乎到系统能否在工作量增加时保持稳定的服务水平。本文将深入探讨如何利用Universal Scalability Law(USL...
在IT行业中,构建一个可伸缩性的容器平台是现代企业数字化转型的关键步骤。这涉及到将应用程序和服务部署在轻量级容器内,通过自动化工具进行管理和扩展,以应对不断变化的业务需求。本文将深入探讨构建这样的平台所...
本代码实现了对MPEG2 空间可伸缩性的基本方法,对于深入理解这一可伸缩性有较大效果
在互联网环境中,可伸缩性是指系统能够随着工作负载的变化动态调整资源的能力,以满足用户需求,同时保持性能的稳定。这种特性对于处理流量波动和应对大规模用户增长至关重要。在博士论文的“第一章”中,可能会详细...
基于给定的信息,我们可以深入探讨基于H.264的精细可伸缩性视频编码(FGS)的研究及其关键技术。 ### 一、引言 随着互联网技术的发展,视频传输的需求日益增长,特别是在有限带宽环境下如何高效传输视频数据成为了...
### 软件工程与软件系统可伸缩性评估 #### 第一章:软件工程概述 **软件工程定义** 软件工程是一种系统化的、规范化的、量化的开发与维护软件系统的方法。这一领域覆盖了从需求分析到维护的整个生命周期,包括但...
### 基于对象的精细可伸缩性编码 #### 摘要解析与核心概念 本文探讨了一种名为“基于对象的精细可伸缩性编码”(FGSIO)的技术,这是一种结合了对象编码与位平面编码的方法,旨在解决在丢包网络环境下高质量医学...
SQL Server 2008是微软推出的一款强大的关系型数据库管理系统,特别在数据仓库领域,其提供了多种增强可伸缩性的特性,旨在帮助企业处理日益增长的数据量和复杂性。本白皮书将深入探讨SQL Server 2008在数据仓库可...