各种传统商业分布式数据库产品的比较

      Netezza, GreenPlum, TeraData, ExaData等产品基本上代表了主流关系数据库近年来主要的进展，它们最明显的共同特征有以下几点：

      1. 水平扩展性。这一点克服了传统关系数据库最主要的问题，以上产品基本上都有很好的水平扩展能力；

      2. 软硬件一体化。上面介绍的产品绝大多数采用了数据库一体机的技术策略，将软件与硬件进行预安装、预调优后，统一销售给客户；

      3. 并行计算与分布存储。虽然具体的实现方法可能不同，但以上产品基本上都采用了并行计算与数据分布存储的策略。

      那么，对各产品进行比较的话，各自有什么特点与适用场景呢？这些产品目前在市场上都是处于竞争对手的状态，应该是各有优缺点，这里我们尽量对它们做一个公正的分析与评判。其实，对这些产品的比较，可以概括为MPP架构的代表TeraData与Oracle的数据库一体机ExaData之间的比较。

      首先，从所支持的数据操作类型来讲，很明显，以上绝大多数产品都是面向海量数据批量处理与分析而设计的，其应对海量的主要技术策略就是“小变大”：即采用一大堆的低端设备集群组合完成复杂的任务。目前看来，“小变大”策略的主要适合场景是OLAP，如Netezza，TeraData，GreenPlum，Vertica等，都是如此，它们对以高并发、随机读写为主要特征的交易类OLTP场景并不适合（保持交易事务的ACID特性，以及维护强大的数据库日志，本身就不是MPP架构的强项与重点）。但这里面有一个特例，就是声称同时支持OLTP/OLAP的Oracle ExaData。那么，ExaData是如何以“小变大”的架构实现普遍需要采用强大的单点能力（如主机平台+高端IO吞吐的存储设备）才能适应的OLTP场景呢？其实也并不神秘，除了Oracle软件的SQL体系本身就很适合于交易类的OLTP操作以外，ExaData在其存储层之上所增加的高达数个TB的高速缓存Flash Cache正是其实现该项特性的最大功臣---大部分热点数据并不需要从“小变大”架构的普通磁盘中直接读取，而是可以完全在高速缓存中完成，这样，对交易操作性能的提高是显而易见的。

      但如果仔细分析就可以发现，关于ExaData的OLTP性能，还是有很多地方值得商榷的：众所周知，Flash Cashe的读性能远远高于其写性能（其随机写性能其实并不比磁盘高很多），这样就可以推断出ExaData由于Flash Cache而增强的OLTP性能，也只是针对那些以读为主的高并发操作有效，对写入操作，则不尽然。当然，采用Flash Cache，倒是可以平衡由于大量交易写操作都在磁盘进行而带来的性能不稳定性，也就是说：虽然总体性能不见得提高了，但交易的稳定性却提高了很多。很多POC测试的结果都证明了以上的分析结论。

      读者可能已经注意到，作为Oracle ExaData的劲敌TeraData，在其推出的6系列产品中加入了SSD卡的设计，它起到了与Flash Cache同样的作用。也就是说，TeraData 6系列的产品，从架构上讲也是可以支持以读为主的高并发操作的。

      有人可能会问：对读写并重的真正的OLTP交易来讲，ExaData的RAC难道不能因为其分布并行策略提高交易性能吗（一般用TPS衡量，指一秒内能完成的交易总数）？其实，用过RAC的人就知道，很多情况下，RAC并不能提高TPS的数量，特别是当交易的资源竞争情况比较严重时，分布式锁机制的实现与多台机器之间频繁的数据复制与移动会严重影响效率：很多情况下，RAC并不能线性地提高交易能力，除非您对应用进行了重新设计，有效减少这种情况的发生。

      通过以上分析便可以看出，对以读为主的高并发操作（如Ad Hoc查询）来讲，ExaData针对MPP架构的优势客观看来并不明显；然而，对读写兼重的纯OLTP交易操作来讲，虽然采用“小变大”架构的ExaData不一定能够替代原有的主机加高端磁盘阵列的方案，但相对于MPP架构，却还是有着很大优势的。

      现在再来看看那些需要OLAP的批量操作与以读为主的高并发操作一起运行的场景（例如我们需要一个数据仓库平台在承担数据模型生成任务的同时，还要求它能承载大量的BI服务）。对这种需求来讲，是否能够很好的分配与管理各种资源（可称为资源的精细化管理），则是该平台能否适用关键---可能某项任务会耗尽了所有的资源！就ExaData与TeraData这两个产品对比来讲，在计算资源方面，两者的管理能力是很难说谁好谁坏的，但对IO资源的精细化管理上，目前看来，应该是ExaData的强项。

      上面是从OLTP/OLAP的操作类型角度分析了各产品，接着让我们再从扩展性的角度来分析。以上所有产品都谈到了其产品是支持水平扩展的，但如果从架构来分析的话，这里认为，真正采用了MPP架构的Netezza，TeraData，GreenPlum等，应该比ExaData扩展性能更优。因为ExaData毕竟采用了RAC作为计算节点的，RAC只是单纯的计算网格，却并不会对数据进行像MPP那样的Sharding分割处理，它虽然采用Infiniband加宽了IO通道，但毕竟是一个Shared Disk的架构。随着其节点不断扩展，数据量的不断增加，RAC的性能很难再继续出现线性的增长：一个庞大的网格计算池面对了一个海量的数据源！而这些问题对生来就是MPP架构的Netezza，TeraData，GreenPlum等是不存在的。

      最后我们再来专门分析一下纯OLAP操作的情况。与传统的OLTP数据库相比（如Oracle），纯OLAP操作一直是MPP架构的强项，因为它生来就是专门为这种场景设计的。特别是对在主键（如TeraData的PKey）上的大表多表Join来说，过去的Oracle，DB2等软件是很难与TeraData，GreenPlum等产品相比拟的：很显然，这时，以Oracle为代表的交易类数据库在索引方面的巨大优势已经不起作用了，因为这种多表大表Join是以批量的操作为主。而MPP架构的工作原理其实也不复杂：MPP架构在数据加载时，就根据某个键对数据进行的分布存储，相当于是提前为多表Join操作做了很多工作，那么，自然在真正开始Join操作时，就会节省很多时间。其实相应的策略在传统的Oracle软件中也有设计，如复合表聚簇的设计，就会把需要Join的数据按聚簇键值Hash存储在一起，从而大大减少了Join操作时的IO量，提高了效率。但由于非MPP架构的产品，其计算资源与存储资源并不是按比例线性分配的，因此，这种分区存储的效果还是在MPP架构中表现的最为明显。另外，一般情况下，对多表Join，除了架构上的优势，MPP软件同样会采用其优秀的SQL优化器，通过执行路径优化，达到多表Join极佳的性能。

      那么，同样还是采用Oracle软件的数据库一体机ExaData针对这种多表大表Join的问题，与MPP架构相比，哪个更有优势呢？我们知道，以Oracle为代表的交易类数据库主要采用Hash Join来处理大表多表Join的问题，在ExaData上，情况仍然如此。这时，ExaData的优势则主要体现在IO通道“几乎无限”，以及其智能扫描的功能可以过滤掉相当一部分不需要的数据到RAC端（对Join来讲，也只有要求部分列返回，以及大表与小表的Join，这种过滤才会有用）这两个方面。但如果某个Join操作使ExaData的这两项设计发挥不了作用，会怎么样呢？比如要在主键（如果它也是TeraData的PKey）上的进行两个大表Join，并且要求返回所有列。通过上面的分析可以判断，对这个问题，应该是MPP架构（如TeraData）更有优势一些。但如果不是在主键上进行Join呢？这种情况下，对大表与小表的Join，ExaData的智能扫描也会起到很大的作用，因此很难说这两者谁更有优势；而对大表与大表的join，MPP架构则会先重新按此键临时分布数据（这可能需要用户自已定义并实现这样的过程），然后再分布并行进行Join计算；而ExaData则需要把两张表的数据全部读到RAC中进行Hash Join计算：很明显，两者需要进行移动的数据量（可以看成是IO量）几乎是一样的，则我们需要比较的是RAC的Hash Join与MPP的并行分布Join，结果如何呢？这个问题并不好回答，但我想读者自己心里应该有数了，这里我们就不做评判了。

分享：