版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://geniusmatt.blogbus.com/logs/75269846.html
前言
最近计划做pureScale高可用性及扩展性测试，收集了一些这方面的资料，09年年末也有过一次和Oracle关于Exadata V2产品的交流。严格意义上，pureScale和Exadata V2没有可比性。pureScale不是Exadata V2那样的软硬件集合的一体化机架解决方案，它更像是在DB2 V9.7之上的性能及功能扩展。然而这两个产品在许多方面都使用了业界的新技术，代表了数据库架构的发展方向。因此我觉得有必要从不同的维度，对两个产品做下比较。
比较项目包括：
比较项目
历史
Exadata
Exadata V1 –September 2008 (Oracle OpenWorld Conference 2008)
使用HP平台服务器，为数据仓库设计。
这个阶段Exadata的设计目标应该是针对Teradata的数据仓库产品而特定的。
Exadata V2 – November 2009
使用Sun X86平台服务器，增加了Flash Cache存储中间层，为OLTP和数据仓库设计。
值得遗憾的Sun的UltraSPARC IV+并没有用到Exadata V2上面，尽管在单核计算能力上比不上IBM的POWER7芯片，但是UltraSPARC IV+芯片的多线程并行计算能力绝对是亮点。
尽管如此，nehalem也算是不差的选择。
pureScale
DB2 pureScale – October 2009
2009年10月9日IBM对外发布了pureScale项目，在此前的很长一段时间，它都处于高保密状态。
在pureScale之前，DB2在不同版本操作系统上支持：SMP、share nothing(DPF)。而pureScale是作为IBM在主机业务外对Share Disk架构的实践。
而pureScale的设计目标，借用IBM自己的话说就是：OLTP业务上实现高扩展性、对应用透明、持续的可用性。
可以很清晰的看出来两个产品的发展思路：
Exadata从V1的专营OLAP，转到OLAP和OLTP通吃。但是用本来是提高OLAP业务性能的技术，给跑OLTP的业务使用的思路，透露出Oracle对于Exadata的想法很邪恶。
pureScale则针对OLTP业务，满足OLTP业务最关心的可用性、业务透明性及扩展性的需求。
仅仅从产品定位方面，pureScale胜出一筹。
架构
Exadata
在Exadata的集成数据库解决方案中主要包括两部分：数据库服务器网格、存储服务器网格。满配机架包括8台Sun X86平台(XEON processor)的数据库服务器，14台Sun X86平台的存储服务器(每台12块2TGB的SAS/SATA盘，并配置Sun Flash Cache)。
数据库服务器网格是基于RAC集群，数据库的存储管理使用ASM，这个层面没有什么新意，不做累述。
存储服务器网格基于Exadata Cell的概念，即每个存储服务器是一个Exadata Cell。由于使用ASM，因此在存储层面上的冗余及条带设计都由ASM负责。因此IBM会说，Exadata存储集群无法使用RAID技术。存储服务器技术的最大亮点是实现了Smart Scan功能（将全表扫描的SQL交给存储服务器预处理），达到的效果是存储与数据库间只传输结果集，不传输数据集，有效的提高了I/O效率。
InfiniBand网络层负责连接数据库服务器网格和存储服务器网格。支持实现Smart Scan功能的iDB协议。
数据库服务器网格之间的通信（RAC集群Global Cache交互）依旧基于TCP/IP协议。
pureScale
作为一种非一体式解决方案，对于pureScale的架构说明集中在数据库集群。
数据库服务器集群是运行DB2 V9.8的IBM中高端P系列服务器（P550以上），被称为DB2 Member。
pureScale数据库集群的亮点是采用了集中管理锁定和缓存的Global Cache管理方式。这个概念是来自于System z Sysplex。充当管理者角色的服务器被称为 DB2 CF(Coupling Facility)，CF primary将共享数据放在自己的内存中，统一协调多个成员对共享数据的访问。
存储部分采用支持InfiniBand网络的SAN架构，其上搭建IBM的共享文件系统GPFS。
InfiniBand网络层负责连接数据库服务器网格和存储服务器网格。支持RDMA功能，因此不但负责传输存储I/O，也负责存储内存I/O。
可以看出，Exadata的优势是在存储I/O的处理环节，而pureScale则将重心放在了内存管理方面。这也是由两个产品最初的设计背景决定的。
技术特点
Exadata
Flash Cache
使用闪存作为存储中间层，存放“热”表。这是V2在V1基础上，针对OLTP应用作出的改进。
Infiniband Connectivity
与其他网络协议(如TCP/IP)相比，InfiniBand具有更高的传输效率。原因在于许多网络协议具有转发损失的数据包的能力，但是由于要不断地确认与重发，基于这些协议的通信也会因此变慢，极大地影响了性能。
Exadata Cell
Exadata Cell可以看作是一台插满12块本地磁盘(SAS/SATA)的PC服务器，数据的保护基于ASM硬盘组的镜像和hot swappable Disk，而不是传统存储的RAID和hotspare。存储与EXADATA之间的通信通过基于InfiniBand的iDB协议进行，传输SmartScan产生的结果集而不是传统数据块，借以减少磁盘子系统的吞吐量。针对share disk架构必然会遇到的DB Server的I/O争用问题，Exadata可以定制IORM，将共享存储的I/O资源按比例分配给不同的数据库使用。
pureScale
RDMA
利用基于InfiniBand的 Remote Direct Memory Access (RDMA) 直接对远程服务器的内存执行写操作。因此可以通过集中式的CF机制来防止那种分布式锁维护的高开销。据说使用DDR InfiniBand进行通讯，pure Scale数据库节点间的内存通讯能像运行并行数据库集群的SMP box的系统板间内存通讯一样快。Global buffer pool存储成员提交的共享数据页。Global lock manager管理成员顺序访问对象。Shared Comunication Area提供DB2控制数据的一致性机制。
InfiniBand
同Exadata部分
SVC（SAN Volume Controller）
"Scalable, high performance InfiniBand-attached SAN Volume Controller"
SVC提供最小两节点配置的集群，提供3GB/s的最大读性能。
成本
Exadata
整体解决方案的成本一般都不会太便宜，值得欣赏的一点是Exadata并没有像pureScale一样刻意限制其只能使用中高端服务器，使用Xeon处理器的PC Server加上Linux的配置，貌似是一种价格便宜量又足的解决方案。然而还是那句话，作为一种整体解决方案，其价格不仅仅限于硬件费用，此外若是应用于OLTP业务，强大的Exadata Cell的磁盘子系统，也有些杀鸡焉用宰牛刀的意味了。
pureScale
目前只能在IBM中高端P服务器运行（P550以上），AIX 6L操作系统DB2 V9.8，IBM宣布将把pureScale支持的服务器向PC server（x系列服务器）方向扩展，支持Linux及windows操作系统，但目前只是将来时。只有绑定技术才能获得最大利益，IBM深谙其道。
扩展性
Exadata
Quarter Rack/Half Rack/Full Rack
通过线缆链接可以扩展到8个机架
pureScale
对应用透明的可扩展性，即不停机实现member的增减。
操作复杂度：pureScale在横向扩展的操作较RAC简单。
横向扩展性：由于RAC会遇到共享数据管理方面的瓶颈，因此一旦应用设计有问题，Exadata集群的表现将会很糟糕。由于使用了Exadata cell存储服务器，因此在磁盘I/O方面的瓶颈并不会十分明显。
pureScale有共享数据管理方面的优势，但由于采用简单的存储方案，因此会存在磁盘争用方面的问题。
由于二者都是shared disk方案，最终都无法避免的出现磁盘争用方面的问题，因此横向扩展能力存在最终瓶颈。
结论
由于两家公司对产品设计理念的不同，因此在有些角度上，两个产品看似没有可比性。此外在相同的技术层面上，性能，可用性以及成本存在相互掣肘的关系，因此不能从单一角度，去评定系统优劣，总之一句话，没有最好的产品架构，最适合自身业务的架构，才是最好的。
联系客服
