衡量易操作数据存储（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。
 

   在这里，我们提出了十大准则供客户在考虑SO应用和检测非传统的通用行存储系统（non-GPTRS system）时使用。它们是一个数据库管理系统的需求和在设计这类应用（SO application）的指导方针的综合。尽管多数情况也适用于把软件作为一个服务环境，但我们以客户在它们自己的环境中运行软件的角度来陈述这十大准则。

   我们分别列出这十大准则，并且阐述为什么它们是必须的：

   准则1，寻找无共享所带来的可扩展性。一个数据库管理系统可以运行在三种硬件体系结构上：最老的一种，共享内存多进程模式（SMP）,这种模式的数据库管理系统在一个包含多个实例（core）的单节点上运行，这些实例之间共享内存和磁盘。由于内存带宽的限制，实例只能达到很少的数量。显而易见，实例的数量会由于未来系统的升级而增加，但是还要看主存带宽是否能以相同的级别增长。因此，这种多实例的数据库管理系统会面临着性能上的约束。选择这种共享内存多进程模式（SMP）的数据库管理系统的客户在多个节点上不得不自己进行划分来获得可扩展性，并且也面临着前边提到的痛苦的问题。以共享内存多进程模式（SMP）工作的流行系统有MySQL, Post-greSQL和Microsoft SQL Server。

   第二种选项是选择一个运行在磁盘集群上的数据库管理系统，其上的CPU都带有自己的私有主存，它们只共享磁盘系统。二十世纪八十年代到九十年代，在DEC,HP和SUN公司里这种模式非常流行，但是在数据库管理系统的上下文中它涉及严重的可扩展性问题。因为有每一个节点主存里的私有缓冲池的存在，相同磁盘块可能同时出现在不同的缓冲池中。因此，对不同缓冲池中磁盘块进行仔细的同步是必须的。类似地，一个私有锁表（a private lock table）也同样存在于每一个节点的主存里。这又一次需要仔细地同步，但是这样将把磁盘的可扩展性限制在一个很小的数量上，通常小于十。

   Oracle RAC是一个非常流行的只共享磁盘的数据库管理系统，你几乎不可能找到一个有着两位数数量节点的RAC配置环境。Oracle最近宣布Exadata和Exadata 2 运行于一个两层结构上，上层共享磁盘，而底层不共享任何东西。

   最后一种结构是无共享模式，这种模式中每一个节点既不共享主存也不共享磁盘。这些自包含（self-contained）节点之间是通过网络连接的。准确地说，自1995年期所有的面向数据仓库的数据库管理系统都是无共享模式的，这类系统有Greenplum, Vertica, Asterdata, Parac-cel, Netezza和Teradata。并且像其它非SQL引擎一样，BD2也是运行于无共享模式下的。无共享模式引擎通常自动执行数据的划分以获得并行性。只有通过使系统节点间负载平衡的方式进行数据对象的划分时，无共享模式系统才能进行扩展。如果数据分布不均或者有热点（hot spots）存在，无共享模式系统的性能就会退化到那个负载最大节点的速度。这时，应用就必须对那些压倒性的事务进行单一划分（single-sharded），这一点将会在准则6中讲述。

   除非被应用的数据和操作所限制，否则良好的设计，无共享模式系统能持续的进行扩展直到网络带宽耗尽或者满足了应用的需要。据报道，许多非SQL系统可以在100个或更多的节点上运行，而大表（BigTable）则可以在成千上万个节点上运行。

Web应用的数据库管理系统的需求可以极速的使其扩展；例如，Facebook最近在应用逻辑层上把它的数据库划分为4000个MySQL实例。如果它选择一个数据库管理系统，它必须至少需要这个规模的节点数量。一个共享内存多进程模式（SMP）或者是共享磁盘模式的数据库管理系统是不可能达到这种级别的扩展性的。只有无共享模式才能达到这种规模。

   准则2，高级语言并不损害性能。SQL事务的操作可能包括以下部分：

1. 由优化器选择较好的执行计划所产生的开销；
2. 与数据库管理系统通信所产生的开销；
3. 使用高级语言所固有的开销；
4. 像并发控制，系统恢复和数据完整性这种服务的开销；
5. 真正执行时的开销，不管它是什么。

   在准则2里，我们先讨论前三个，在准则3里我们再讨论后两个。在二十世纪六十年代到七十年代，层次化模型和网络模型是主流的数据库管理系统解决方案，这些数据库管理系统只提供了一个低级的过程式的数据接口。RDBMS的高级语言在替换这些数据库管理系统时非常有用主要有三个原因：

1. 用高级语言编写的系统代码量更加的少，也比较易于理解；
2. 使用者只用陈述他们想要的，而不是去写一个面向磁盘的怎么样去访问他们所需的数据的算法；程序员不需要去理解复杂的存储优化知识；
3. 高级语言系统比低级语言系统更能适应模式的改变，可能几乎不需要维护和重写代码，而低级语言就需要做更多的维护。

   二十世纪七十年代到八十年代,在RDBMS中的一个令人不满意的地方是它们可能没有低级语言系统更高效。这是因为自动查询优化器所做的可能没有一个优秀的程序员写出的更好。虽然早期的优化器是很原始的，但是他们除了比不上最优秀的程序员所写的之外，比其它所有的都要好。并且，大多数组织并不具备这种级别的才能。因此，高级语言所带来的额外开销正在消失，今天，仅在这种SO应用中非常复杂的查询环境下，它才是一个需要考虑的因素。

   第二种开销的来源是与数据库管理系统的通信。处于安全方面的考虑，RDBMSs要求应用在隔离的地址空间内运行，使用ODBC或者是JDBC进行交互。这种方式的通信开销非常高；执行一个SQL事务需要在TCP/IP上进行几个来来回回的消息。因此，对性能要求比较高的程序员会使用存储过程，而不是通过ODBC/JDBC执行SQL命令。如果使用存储过程，则一个事务只有一个来回的通信，而不是多个。数据库管理系统可以把多个事务在一次调用中进行批处理，从而进一步减少通信开销。通信方面的开销是接口选择的功能，可以使之减少，跟是否使用高级语言进行交互没有什么关系。

   第三种开销的来源是使用了SQL而不是使用底层的过程式语言。自从大多数SQL引擎把它编译成机器代码或者至少编译成像Java风格的中间表示（intermediate representation）一样，这种开销并不算大。也就是说，标准语言编辑把高级语言转化成非常高效底层运行时的可执行体。

因此，在过去二十五年里数据库管理系统领域的一个重要经验是高级语言并不损害性能。一些新系统提供SQL或者一个更加局限的高级语言支持；另一些则只提供“数据库汇编语言“，或者是单项指标（individual index）和对象操作（object operations）。这些低级语言也许在面对非常简单的应用时是足够用的，但是，在其它情况下，高级语言提供了令人信服（compelling）的优势。

   准则3，仔细规划主存的能力（leverage）。设想一个有16个节点的集群，每个节点都有64GB的主存，这样任何一个无共享模式的数据库管理系统都可以访问大约1TB的主存。这样的硬件配置在几年前还不敢想象，但是今天却很普通了。并且，未来每个节点的主存容量会继续上升，集群中节点的数量也很有可能增多。因此，未来典型集群的主存会有TB量级的增长。

   结果是，假如数据库有几个TB或者少一点（一个非常大的SO数据库），客户应当考虑主存的部署问题。假如数据库更大的话，客户应该在实际应用中考虑主存的部署问题。另外，随着闪存价格的降低，它已成为未来有希望的存储介质。

数据库管理系统如果使用内存而非磁盘进行随机访问，其速度将会提升成千上万倍。当然，数据库管理系统必须被合适的架构以使主存达到有效的利用。如果只是简单通过在一个拥有更多的主存的机器上运行数据库管理系统，那么得到的只有很少的性能提升。

   要明白为什么，考虑一个数据库管理系统的CPU开销。在2008年，Harizopoulos6等人使用主流的SO基准，TPC-C系统，对在线的开源数据库管理系统进行了性能测试。为什么使用这种数据库管理系统？因为这种数据库管理系统在仪器化方面源代码是可用的，而且这些数据库管理系统是典型的传统通用行存储系统（GPTRSs）的实现，对在线的开源数据库管理系统的测试结果可以代表这一类系统。

   Harizopoulos6等人使用了可以使所有的数据适合主存大小的数据库尺寸，因为它可以和大多数SO应用保持一致。因为像其他传统的通用行存储系统一样，在线的开源数据库管理系统是基于磁盘的，这意味着所有的数据都要存储在主存缓冲区中。他们的目标是使用TPC-C系统划分数据库管理系统开销的种类；他们在与应用驱动器相同的地址空间内运行数据库管理系统以避免TCP/IP的开销。然后他们查看了CPU使用部分，这些开销有的用来执行有用的工作，有的用来传送数据库管理系统服务。

   以下是在TPC-C系统的新规则事务下运行不同的任务时CPU周期的使用情况。由于Harizopoulos6等人注意到一些存在于大多数商业化的传统的通用行存储系统（GPTRSs）的一些缺点，把这些缺点所带来的开销去除掉后，这些结果已经被重新按比例缩放：

   有用的工作（13%）。这是CPU真正执行查找相关记录，执行检索操作，更新相关属性等所产生的花费；

   加锁（20%）。这是CPU在加锁，释放锁，死锁检测和管理加锁表（lock table）时的花费；

   日志（23%）。当记录被更新时，内核（images）变化之前与之后的内容要写入日志中。然后，数据库管理系统（Shore）使用组提交（group commit）把事务聚集成  组，使相关部分被写入磁盘日志中；

   缓冲区开销（33%）。由于所有的数据都储存在缓冲区中，任何检索和更新操作都需要找到缓冲区中的相关块。满足条件的记录必须被定位，相关属性必须被找到。有一种开放数据库游标（open database cursor）必须指向（pinned）主存中的相关块。并且，使用到了最近最少使用算法或其它替换算法，这些算法又需要记录的额外信息；

   多线程开销（11%）。自从大多数数据库管理系统使用多线程后，许多操作都并行的执行。不幸的是，加锁表（lock table）是一个共享的数据结构，它必须被各种各样的并行线程所占有（latched）以串行化访问（serialize access）。另外，B树索引和资源管理信息也必须被同样地保护。当共享数据结构被访问时互斥量（mutexes）必须被获取和释放。更详尽的讨论可参考Harizopoulos6等人的文献，它们讨论了为什么获取互斥量的开销可以被忽略不计（understated）。

   传统的基于磁盘的数据库管理系统把它周期的大部分都花费在了上述的开销活动中。为了获得更快的速度，数据库管理系统必须避免上述讨论的所有开销部分；例如，一个多线程，锁机制和系统恢复的主存数据库管理系统只比磁盘类型的数据库管理系统快一点。一个非SQL或其它的数据库引擎不会显著的胜过传统的通用行存储系统（GPTRSs），除非上述所有的开销部分被处理或者那些传统的通用行存储系统（GPTRSs）没有被合适的架构（比如说，使用对话式的SQL而不是编译好的存储过程接口）。

   我们是对单机系统的性能进行分析，但是通过准则1和其它准则，我们知道这种性能对于多机系统来讲有直接的影响。

   准则4，高可用性和自动恢复是至关重要的SO可扩展性。1990年，一个典型的数据库管理系统应用要运行在我们现在也认为很昂贵的硬件上。如果硬件失效，客户必须先修复机器，重新安装操作系统和数据库管理系统，然后利用数据库管理系统的日志对未完成的事务进行undo操作，完成的事务进行redo操作，从而使数据库恢复到最近的一致性状态。这个过程会持续一段时间（几分钟到一小时也许更多），在这段时间内应用是不可用的。

   现在，很少有客户能情愿的接受他们的SO应用由于故障任意停机，大多数愿意运行冗余硬件和使用数据复制来维持所有对象的第二份拷贝。一旦一台硬件失效，系统会马上切换到备份机并继续运行。实际上，就像二十世纪八十年代由串行计算机（Tandem Computers）所倡导的那样，客户想要他们的系统永不宕机的运行。

   进一步讲，许多大型的Web内容运行在很多的无共享模式的节点集群上，随着“可移动部分“（moving parts）数量的增加，故障的发生率也会上升。太高的故障发生率使恢复过程中的人为干涉变得不切实际。因此，无共享模式的数据库管理系统软件必须能够自动检测和修复失效节点。

任何满足SO应用的数据库管理系统都应该有内置的高可用性并支持永不停机的运行。三种高可用性告诫（caveats）应该得到解决。第一种是众多的各种各样的失效，包括：

1. 应用本身毁坏数据库；
2. 数据库管理系统中可再现的错误（称之为Bohr bugs）；
3. 数据库管理系统中不可再现的错误（称之为 Heisenbugs）；
4. 各种各样的硬件错误；
5. 网络包丢失；
6. 服务攻击的拒绝；
7. 网络划分。

   一些数据库管理系统在遇到某些并不是所有的上述失效时可以继续运行。从所有可能的失效情况下进行恢复的开销非常的大。因此，高可用性是统计方面的努力，或者说针对特定的失效种类，怎么样的高可用性是期望的。

   第二种称作为CAP理论,它包括一致性，可用性和分区容忍（partition-tolerance）。在某些错误发生时，这个理论声称分布式系统最多只能达到一致性，可用性和划分容忍这三条中的两条。因此，在可能的高可用性领域里有着理论上的限制。

   并且许多站长（site administrators）想防范灾难（比如地震或洪水）。尽管这些事件发生的概率很小，但是灾难恢复很重要并且应该被视作高可用性的扩展，灾难恢复可以通过在广域网上备份来获得。

   准则5，使所有东西在线。一个SO数据库管理系统应该只有一个状态：“启动中“。从用户的角度讲，它应该从不失效并且不应该被离线处理。另外在失效恢复中，许多当前的实现都需要数据库被离线操作：

模式改变。在不影响服务的情况下，已存在的数据库应该能够增加属性；

索引改变。在不影响服务的情况下，索引应该能够被增加或删除；

再补给（reprovisioning）。在不影响服务的情况下，应该能够增加用来处理事务节点的数量；例如一个有着10个节点的配置要增加到15个节点，以使满足日益增长的负载；

软件升级。在不影响服务的情况下，数据库管理系统应该能够从版本N升级到版本N+1。

尽管对这些操作进行支持是一种挑战，100%（uptime）应该成为目标。由于一个SO系统扩展到几十个节点或者其互联网用户达到了百万级别的规模，停机和人为干预是不实际的。

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