【IT168 专稿】数据库作为企业应用系统的核心，在IT系统中一直扮演着相当重要的角色，尤其是某些核心数据关系着企业的命脉。然而，随着企业业务量的不断增长，系统的访问量和数据流量也快速增长，使得单一设备根本无法承担如此大的处理能力和计算强度。多服务器的群集数据库系统应运而生。
群集数据库解决了在单处理机系统时代CPU对数据库系统造成的瓶颈问题，通过简单的增加数据库服务器即可组建大型数据库系统。群集数据库不仅能够实现数据库的负载均衡，提高数据库的处理速度，而且能够保证系统的高可用性，在系统发生故障时进行自动故障转移，实现系统的持续运转，避免因为系统故障造成的经济损失。另外，对于某些核心数据，群集数据库还能通过数据集群的冗余，保证数据的安全性。
目前，市面上的群集数据库主要有Oracle RAC、IBM UDB、微软MSCS、Sybase ASE、MySQL CS等，其中Oracle RAC是甲骨文公司提供的双机共享磁盘设备的解决方案，很长一段时间，甲骨文都以实时应用集群技术(Real Application Cluster，RAC)统治着群集数据库市场。但是Oracle RAC的应用效果“见仁见智”，有专家列出其缺点主要是扩展能力有限、对应用不透明。为了解决Oracle RAC的这些问题，IBM DB2对自己的产品进行了改进，并于2009年10月推出了pureScale技术。pureScale将高可靠性和应用透明扩展的能力集于一身，利用share disk的方式扩展集群服务器成员。
▲DB2 pureScale
DB2 pureScale：满足新时代需求的群集数据库系统
DB2 pureScale是以IBM DB2 for z/OS技术为基本原则，主要针对分布式系统的在线事务处理(OLTP)提供集群技术。pureScale并不是一个硬件解决方案，它是一个应用在AIX系统上的数据库集群软件。如果该软件在IBM Power Systems上运行，在降低扩展IT系统的风险和成本的同时，可以帮助客户提高数据库交易能力。其目的是让企业在不牺牲性能的前提下扩展DB2集群，能够为所有事务性工作负载提供近乎无限能力，扩展系统变得只是连接一个新的节点和发布两条简单的命令这么简单。
DB2 pureScale在效率上已经远远超过了Oracle的RAC技术。在发布之初的测试中，DB2 pureScale在100余台Power服务器上将整体系统效率提升至80%。在拥有64节点的pureScale集群只浪费了不足10%的网格处理功率，而应用100个节点的集群提高到约20%。IBM信息管理部门总经理Arvind Krishna曾经表示：“在满足现有商业需求的前提下，Power系统上的DB2 pureScale帮助用户的IT基础架构更加可靠，并更加经济。” DB2高级工程师接受IT168记者采访时也曾表示，pureScale是DB2最优秀的特性之一。
▲DB2 pureScale架构
DB2 pureScale具有无限扩展、应用透明性、持续可用性等特点：
无限扩展: DB2 pureScale为各种事务处理工作负载提供了几乎无限的产能。系统扩展非常简单，只需要与一个新节点连接，并发出两个简单的命令即可。DB2 pureScale基于集群、磁盘共享的架构通过有效利用系统资源，降低了成本。
应用透明性: 使用DB2 pureScale，无需改变企业的应用程序代码，就可以有效地运行在多个节点上。久经验证的、可扩展的架构能够随需扩展应用程序，以满足变化的业务需求。企业只需做少量改变或无需做任何改变，就能够运行为其他数据库软件编写的应用程序;DB2 为常用的语法规则和PL/SQL语言提供了全面的支持，使从Oracle数据库迁移到 DB2 变得比以往更轻松了。
持续可用性: DB2 pureScale通过在IBM Power Systems上和冗余架构中使用高可靠的IBM PowerHA pureScale技术，提供了持续的可用性。此系统能够瞬间从节点故障中恢复，立即将工作负载重新分配给其他可用的节点。
DB2 pureScale与Oracle RAC功能对比
DB2 pureScale和Oracle RAC是两个类似的技术，两者在数据库领域均占据十分重要的地位。但是相对于Oracle RAC，DB2 pureScale更具优势，尤其是在高可用性、可伸缩性和应用透明性等方面。
1.高可用性
DB2 pureScale的设计初衷是最大限度地提高在故障恢复处理中的可用性，当数据库成员出现故障时，只有动态(In-Flight)数据仍然保持为锁定，直到成员恢复完成。动态数据在线恢复的目标时间小于20秒。
因此DB2 pureScale 成员故障中所涉及的两个步骤包括故障检测和数据恢复，而Oracle RAC的节点故障则需要涉及四个步骤，即节点故障检测、Remaster数据块、锁定需要恢复的页面、重做和撤销恢复。与 DB2 pureScale不同，Oracle RAC并不会使锁或数据缓存集中化。
▲DB2 pureScale与Oracle RAC高可用性对比
具体来说，在Oracle RAC中，每个数据页都由集群中的一个实例来管控。Oracle采用分布式的锁机制，因此集群中的每个实例都需要负责管理和批准对它所管理页的锁请求。当某个节点出现故障时，故障节点所管理的数据页将立即变为孤立的，直到RAC会通过重新分配流程将这些孤立页面的管控权分配给集群中健康的节点。在Global Resource Directory重新配置的过程中，对页面的任何读取和锁请求都会立即被冻结。应用可以继续在健康的节点上处理，但这时它们不能执行任何I/O操作或请求任何新锁。这会造成许多应用被冻结。
RAC节点恢复流程的第二步是锁定所有需要恢复的数据页面。这项任务必须在GRD冻结被释放之前完成。如果某个实例在获得适当的页解锁之前被允许读取磁盘中的页面，则故障实例的更新操作可能会丢失。恢复实例将一遍读取故障实例的重做日志文件，并锁定任何需要恢复的页面。这可能需要大量随机的I/O操作，因为日志文件乃至需要恢复的页都可能不在任何健康节点的内存中。
仅当恢复实例执行了所有这些I/O操作并锁定适当的页之后，GRD冻结才会被释放，停滞的应用才能继续运行。根据故障节点在出现故障时正在进行的工作量，这一过程可能会花费几十秒到几分钟不等的时间。相比之下，DB2 pureScale环境则不需要在集群中进行全局冻结。CF在任何成员出现故障时始终知道哪些页面需要恢复。如果某个成员出现故障，集群中的所有其他成员可以继续处理事务和执行I/O操作。只有对需要恢复的页面的访问请求会在故障成员的恢复流程完成之前被阻塞。
▲DB2 pureScale与Oracle RAC崩溃恢复比较
2. 透明的应用伸缩性
DB2 pureScale具有透明的应用伸缩性，管理员可以增加产能，而不需要重新调优或重新测试，开发人员甚至不需要知道增加了更多节点。pureScale支持RDMA访问的集中锁定和全局缓冲池可以带来高可伸缩性，而不会让应用集群感知到，而Oracle RAC中的分布式锁定会增加开销并降低可伸缩性。
▲DB2 pureScale集群中的成员测试结果
具体来说，DB2 pureScale通过InfiniBand并利用Remote Direct Memory Access (RDMA)直接对远程服务器的内存执行写操作。虽然Oracle也可以将InfiniBand应用于Oracle RAC集群，但是Oracle没有利用RDMA技术，这意味着Oracle通信将使用速度较慢的套接字协议，并且需要一些开销较大的CPU中断，从而影响集群效率。
支持RDMA访问的集中锁定和全局缓冲池为DB2 pureScale带来高可伸缩性，在读写比例为80:20的12个成员节点的测试中，DB2 pureScale的性能扩展超过90%。Oracle RAC采用分布式锁，这会增加开销并降低可伸缩性。实际上，4个节点以上的RAC应用并不多，因为其无法通过增加节点而达到更好的性能扩展。
总结
DB2 pureScale作为IBM破甲行动的突破点，是群集数据库发展史上的一个里程碑。通过本文对DB2 pureScale的介绍，及其与Oracle RAC的功能对比，相信大家对这项技术的认识更加深刻了。如果想了解更多有关DB2特性的解析，请继续关注《IBM DB2关键特性解析：DB2分区特性》。
