可伸缩性，美妙的可伸缩性

可伸缩性带来的好处

从理论上来说，我认为有两种基本方式可使得系统具有可伸缩性这种至关重要的属性。一种方式是，在设计级别逻辑优化系统。您可以独立于任何软件工具和基础结构元素来考虑系统，然后在物理上建立系统。在实践中，这就意味着最大限度地减少瓶颈和关键资源的影响，同时在尽可能充分利用任务的内在并行性。 另一种方式则截然相反。您主要依靠某种硬件和软件组合的内置特性，而您的解决方案和创造性只发挥次要的作用。基本上，您将可伸缩性和互操作性的责任留给为了完成此任务而选择的工具。 顺便提一句，在前互联网时代，多年来人们一直在使用前一种方法，那时，大家尤其关心性能和强大的功能，似乎忽略了可伸缩性问题。（如果没有大范围的 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