衡量易操作数据存储（SOD）可扩展性能的十大准则（下）

   这篇文章来自作者对Michael Stonebraker和Rick Cattell两位作者所著《10 Rules for scalable Performance in ‘simple operation’ Datastores 》 Communications of The ACM    |   June 2011   |  VOL. 54   |   No. 6 的翻译和理解，以飨读者，分为上、中、下三篇。此篇为下篇。 原文出自http://blog.csdn.net/hongchangfirst/article/details/7008836。

 

准则6，避免节点间的操作。为了获得集群服务器的可扩展性，有两个特点是必需的：

其一是平滑的分离。数据库负载和应用负载必须在服务器之间平滑的分离。通过复制数据可以获得读扩展性（Read-scalability），但是通常的读写扩展性（read/write scalability）需要在节点之间通过主键进行划分。

另一个是扩展性优势。应用很少跨越到多台服务器上执行操作。假如很多台服务器都涉及到处理一个操作，那么这种扩展性带来的优势就会消失，因为有冗余的工作，服务器间的通信，和操作之间需要的同步的存在。

假设客户与一个员工表并按照员工年龄对其进行划分。如果他想知道某一个员工的薪水，他必须把这条查询发送给所有的节点，这需要极多的通信。结果却是只有一个节点找到了需要的数据；其他节点也运行了查找操作却什么也没找到。进一步讲，如果应用在划分间执行更新操作，比如说对鞋部门所有的员工加薪，那么系统必须承担所有的同步开销，用于确保在每一个节点上执行事务。

因此，数据库管理员应该慎重的选择用于划分的键值，以使尽可能多的操作在划分内解决问题。幸运的是，如果数据被合理的划分，大多数应用都只涉及在一个划分内。例如，假如购买订单（POs）和其详情共用同一个购买订单号（PO number），那么大部分事务（比如新的购买订单，更新一个特定的购买订单）都只需一个节点便可完成。

通过对只读数据的复制，单节点事务的比例可以进一步增加；例如，客户和他们的地址可以被复制到所有的节点上。在很多商业对商业（B2B）环境中，增加客户，删除客户或者改变客户的地址不是经常发生的。因此，完全冗余可以在单一节点上完成对一个新购买订单上插入客户地址的操作。这样，有选择性的对读密集性的数据进行冗余是有益的。

总的来说，程序员应该最大限度的避免多节点间的操作，包括必须涉及多个划分的查询，满足ACID性质的更新。为了达到这一目标，客户应该认真思考他们的应用和数据库。如果现在的应用设计不能达到这一目标，他们就应该考虑重新设计现有方案以达到非常高的“单一划分能力”（single-shardedness）。

准则7，不要自己实现ACID性质。通常，我们先前提到的键值存储类型，文档存储类型和可扩展记录存储类型放弃了事务的ACID语义，替而代之的是原子性，隔离性，一致性这种比较弱的形式，并提供了一种或更多下述可选择的机制：

Ø  当有许多的同步写时，对会导致并行版本的每一个写操作的对象创建新版本；这要求应用逻辑去解决结果冲突；

Ø  提供“最新时才更新“（update-if-current）操作，这种操作只有当对象满足一个特定的值时才对它进行更新；这样，应用就能够读取一个最近被更新的对象，然后只有当其值仍然是最新时才能够做更新；

Ø  提供ACID语义，但这只针对一个或单一划分内的对象与属性进行读写操作时；

Ø  提供“法定“（quorum）读取和写入操作，用来保证在众多的“最终一致性”副本中有最新版本。

只要编写足够的额外代码，对任何上述系统建立自己的ACID语义是可能的。然而，这项任务非常困难，我们不希望它成为我们最大的敌人。如果你需要ACID语义，你应该期望数据库管理系统去提供它们；因为在数据库管理系统层面处理ACID语义要比应用层面简单的多。

任何需要在两个对象上进行协调更新的操作都很有可能需要ACID保证。考虑这样一个事务，它在两个用户帐户上转账10美元，在保证ACID的系统上，程序员可以简单的这样写：

Begin transaction 

Decrement account A 

Increment account B 

Commit transaction

在没有保证ACID的系统上，执行这样协作的动作并不简单。其它需要ACID语义的情况还有：只有当客户的订单到位并且他们双边友好的引用同步之后，才能向客户的账户上收费。标准的ACID语义会给程序员要么全执行要么全不执行（all-or-nothing）的保证，用来维护数据的完整性。尽管一些应用不需要这样的协作，对非ACID系统的承诺会阻碍未来这种应用的扩展，比如需要协作。数据库管理系统应用通常存活很长一段时间并且受制于未来的未知需求。

我们理解了为什么要放弃事务这一非SQL运动发展的动机，它们相信在传统的通用行存储系统（GPTRSs）中事务型的更新是非常昂贵的。然而，新的SQL引擎通过如准则3里所讲的对所有开销进行仔细的消除，它们可以同时提供ACID和高性能，至少对遵从准则6（避免多节点操作）的应用来说。假如你需要ACID事务但是你又不能遵从准则6，那么你将可能引来大量的开销，不论你是否自己编写代码来实现ACID还是让数据库管理系统实现。让数据库管理系统实现ACID的是没有脑子的举动（no-brainer）。

根据CAP理论3，我们已经知道要放弃ACID事务的论据，声称你只能获得三种特性的两条：C代表一致性，A代表可用性，P代表划分容忍（partition-tolerance）。这种论据说如果划分发生时，你必须放弃一致性去获得高可用性。我们从三个原因讲（We take issue for three reasons）：其一，一些应用真的需要一致性并且不能放弃它。其二，CAP理论只处理了可能失效问题的一个子集，正如准则4所说，当你处理了两个问题就会有一个问题遗留下来（one is left with how to cope with the rest）。其三，我们不确定在局域网内对数据的分区是重要的问题，局域网经常是备份的并且应用在同一个站点上；在这种情况下，分区很少出现，如果一致性和可用性冲突的话，这种情况非常少见，我们最好还是一直选择一致性比较好。

尽管广域网划分要比局域网划分更加普遍，但是用于只读数据拷贝和灾难恢复（例如当所有数据中心都下线时）的广域网备份是很普遍的；广域网延迟在同步副本或者划分方面非常高。很少有用户期望从主要的灾难中恢复，而牺牲短期可用的停顿（hiccups），所以CAP理论在这种情况下也许有很少的关联性。

我们建议需要ACID的客户使用数据库管理系统提供的ACID而不要自己编写代码实现它，这样通过好的数据库和应用设计我们可以尽可能减少分布式事务的开销。

准则8，寻找易管理性。关于关系型数据库管理系统的一个常见的抱怨是它们贫乏的过时的行为。大多数产品包括许多对数据库管理系统行为进行调整的转换把手（tuning knobs）；并且，我们的经验是一个在某一个特定制造商的产品上熟练的数据库管理员比无技能的数据库管理员可以使系统跑的快上一两点甚至更多。

同样地，引进新的数据库管理系统是令人怯步的，尤其是在多节点上的分布式系统，模式创建，应用设计，数据分布，调整和监控。即使是使用运行在一个新引擎的高性能TPC-C版本上也会有缺点。尽管其源代码和模式是容易使用的。并且，一旦应用产品化后，它仍然需要大量的数据库管理员去维护。

当考虑一个新的数据库管理系统时，我们应当仔细考虑那些开箱即可用的东西。不要让制造商给你做概念验证（proof-of-concept）的实验，自己做概念性验证，因此你可以更加准确的看到那些开箱即可用的东西。并且在你的决策里还要认真考虑应用的监视工具。

最后，要特别注意准则5。一些大多数系统里最困难的管理性问题（例如模式改变和再补充）需要人员的参与。

准则9，注意节点的性能。近来，一个较为普遍的说法是，“使用线性扩展吧，这样你就可以总是通过扩展来满足你应用的需求，节点的性能并不是特别的重要”。虽然线性扩展重要这是事实，但是忽略节点的性能是错误的。我们应当始终记得，线性扩展意味着总体性能是节点数和节点性能的倍数。所以，节点的性能越高，所需节点的数量就越少。

解决方案之间在节点性能上相差一个甚至更多的数量级是很常见的现象。例如，在数据库管理系统风格（DBMS-style）的查询下，并行数据库管理系统比Hadoop优越不止一个数量级1。而且，与其它主流厂商的产品8相比，H-store在TPC-C上已经被显示出有更高的吞吐量。例如，考虑一个在两个数据库解决方案之间做出选择的客户，这两种解决方案都提供线性扩展。假如A解决方案提供的节点是B解决方案提供节点性能的20倍，如果这个客户使用A解决方案要用50个节点，那么他用B解决方案就需要1000个节点了。

在硬件花费，机架空间（rack space），冷却系统和电力消耗上存在这么大的差异，对于这两个解决方案来讲并不是不重要的。更为重要的是，如果节点平均每三年失效一次，那么B解决方案每天都会有一个节点失效，而A解决方案却是不到一个月一次。这种显著的差异会严重影响到需要多少冗余备件和多少处理可靠性所需的管理时间。总之，节点的性能，会使一切更容易。

准则10，开源可以更好的控制你的未来。这最后一条准则不是技术要点，但同样重要，并且，因此，也许它应该称作是建议而不是准则。现实充满着各种各样的情况：一家公司获得了一家厂商的产品，却面临着要在接下来几年内支付高昂的升级费用；对拙劣的技术支持大型维修费，并且不能避免这些费用，因为换成其它产品需要重新编写代码所带来的开销。避免“供应商的不当行为”（vendor malpractice）的最好办法是使用开源产品。开源产品没有昂贵的许可证和升级费用，并且经常多种选择和新功能的支持，并包括对他们的内部进行错误修复的选项。

由于这些原因，许多新的面向Web的机构大都坚决仅使用开源系统。一些厂商也已经证明了开源模式是一个可行的商业模式。我们期望随着时间的推移开源系统会更加流行，并且建议客户们考虑它的优点。

结论

我们提出的10个准则，指定了任何SO数据存储的理想特性。正在寻找分布式存储系统解决方案的客户们可以通过考虑这些准则和他们自己独特的应用需求来审查他们的系统。现在提供的大量系统在能力和局限性上有着相当大的范围。

致谢

我们要感谢Andy Pavlo, Rick Hillegas, Rune Humborstad, Stavros Harizopoulos, Dan DeMaggio, Dan Weinreb, Daniel Abadi, Evan Jones, Greg Luck 和 Bobbi Heath 他们对本文提出的宝贵意见。

参考文献

1.Abadi, D. et al. a comparison of approaches to large-scale data analysis. In Proceedings of the 2009 SIGMOD Conference on Management of Data (Providence, rI, June 29). aCM Press, new york, 2009, 165–178.

2.astrahan, M.M. et al. system r: a relational approach to data management. ACM Transactions on Database Systems 1, 2 (June 1976), 97–137.

3.brewer, e. towards robust Distributed systems. Keynote at Conference on Principles of Distribute Computing (Portland, or, July 2000); http://www.cs.berkeley.edu/~brewer/cs262b-2004/PoDC-keynote.pdf

4.Cattell, r. scalable sQl and nosQl datastores. ACM SIGMOD Record 40, 2 (June 2011).

5.Codd, e.F. a relational model of data for large shared databanks. Commun. ACM 13, 6 (June 1970), 377–387.

6.harizopoulos, s. et al. oltP: through the looking glass and what we found there. In Proceedings of the 2008 SIGMOD Conference on Management of Data (vancouver, b.C., June 10). aCM Press, new york, 2008, 981–992.

7.selinger, P. access path selection in a relational data management system. In Proceedings of the 1979 ACM SIGMOD Conference on Management of Data (boston, May 30). aCM Press, new york, 1979, 23–24.

8.stonebraker, M. et al. the end of an architectural era (It’s time for a complete rewrite). In Proceedings of the 2007 very Large Databases Conference (vienna, austria, sept. 23). aCM Press, new york, 2007, 399–410.

9.stonebraker, M. et al. the design and implementation of Ingres. ACM Transactions on Database Systems 1, 3 (sept. 1976), 189–222.

b我们使用术语“客户“用来指那些评估或使用这类系统的任何组织，即使这类系统是没有制造商，开源的。

这里分别列出上中下三篇地址，方便读者进行阅读。
上篇：http://blog.csdn.net/hongchangfirst/article/details/7008836
中篇：http://blog.csdn.net/hongchangfirst/article/details/7008955
下篇：http://blog.csdn.net/hongchangfirst/article/details/7022162