前面分析的主要是Exadata如何高效地进行计算。通过在存贮结点加入数据处理能力，Exdata不仅大大地提升了处理性能，而且解决了以前的Oracle架构上可能存在的CPU和网络的瓶颈问题。

一个Database Machine有8个DB节点，14个Cell (存贮)结点。在V1版本中，一个Cell可以提供1GB/s的带宽，14个Cell节点总共能提供的带宽为14GB/s。对于8个DB节点，每个节点都是两个CPU，每个CPU 4 个Cores。所以一个Database Machine中DB节点总共有64个Cores。

8 DB Nodes + 14 Cell Nodes = Balanced System

这是一个经过实践证明过的平衡的一个配置。对于一个典型的DW并行查询，类似我们在第一篇文章里提到的，也就是下面的这个查询:

SELECT a.no,
       sum(case
             when a.KEY IN ('A') then
              a.score * 2
             else
              a.score * 5
           end) score1,
       sum(....
           ...
              ) scoreN
  FROM fact_table a
 GROUP BY a.no
;

在运行的大部分时间，DB节点的64个Cores保持100%的利用率，14个Cell节点的总IO吞吐量保持在14GB/s上。

记得今年9月底和阿里巴巴的DBA的一个关于Exadata的交流活动上，新成立的阿里云的同事也到场了。Exadata的架构引起了大家的共鸣，会后一个反应是，有人觉得Exadata与云计算有些异曲同工之妙。其实这也难怪，Exadata本来就是一个关注大规模并行计算的集群系统。特别是智能的存贮节点的引入，更使得每个存贮节点能够分担一个大计算里的一小部分，并且这些智能的存贮节点还有线性的可扩展性，当需要更好的性能时，只要简单地相应增加存贮节点和/或DB节点就可以实现了。这难道不是一个“云计算”的例子吗？

下一个问题，Exadata如何解决CPU方面的瓶颈呢？

在Exadata之前，我想无非两种思路，第一在原来节点上用更多更强的CPU，第二采用更多的RAC节点。

不过在Exadata的架构中，CPU的瓶颈已经从基本上得到很大的缓解，这就是存贮节点上CPU处理能力的介入。

还是以一个实际SQL为例:

SELECT t0.id
   FROM
  (SELECT id
 FROM t0
    WHERE id LIKE '%54234245%'
  ) t0,
  (SELECT id
     FROM t1
    WHERE id LIKE '%54234245%'
  ) t1,
  (SELECT id
     FROM t2
    WHERE id LIKE '%54234245%'
  ) t2,
  (SELECT id
     FROM t3
    WHERE id LIKE '%54234245%'
  ) t3,
  (SELECT id
     FROM t4
    WHERE id LIKE '%54234245%'
  ) t4,
  (SELECT id
     FROM t5
    WHERE id LIKE '%54234245%'
  ) t5,
  (SELECT id
     FROM t6
    WHERE id LIKE '%54234245%'
  ) t6
  WHERE
    t0.id=t1.id
AND t0.id=t2.id
AND t0.id=t3.id
AND t0.id=t4.id
AND t0.id=t5.id
AND t0.id=t6.id
;

下面是一个可能的结果，第一行的数据是没有启用Smart Scan技术的结果，第二行是启用了Smart Scan的结果。

第一行比较容易理解，存贮阵列/结点的数据以400 MB/s的速度通过Storage network传输到DB结点进行，DB CPU的利用率达到了99%。

显而易见，这时瓶颈出现在DB结点的CPU上，如果启用了Smart Scan，则Exadata会在存贮结点上首先对数据进行处理(存贮结点的CPU利用率为50%)，然后把其中有效的数据以8 MB/s的速度传输到DB结点进行处理，这时DB结点的CPU利用率下降为80%。SQL的完成时间却变为原来的一半。

Exadata在这里做了哪些事情呢？

1. 只进行有效数据的传输，这里，只传输满足条件id like ‘%54234245%’的7个表的指定列 id 的数据。

2. 解决了原来pre-Exadata可能碰到的网络瓶颈问题

3. 分担了DB 节点的工作负载

Exadata应该说代表着Oracle Database未来的发展方向。这句话可不是一句广告词，依我看来，Exadata完全有这个资格享受这种待遇。

一个计算系统，最主要的是追求CPU，IO，Network之间的平衡。使这些计算资源能充分地发挥潜能。比如说，如果IO的扫描能力能达到10GB/s，如果存贮阵列到计算结点的带宽不能达到10GB/s，那么IO的扫描能力就不能得到充分发挥。又比如，如果CPU每秒钟只能处理6GB/s的数据量，10GB/s的IO扫描能力也不能能到充分发挥。

对一个计算系统另一个重要的衡量指标是如何有效地利用计算资源，这同样地包括CPU，IO，Network。比如说，虽然Network可以达到每秒10GB/s的带宽，但如果这些数据都是无效的(与本次操作无关的其它业务数据)，那么这只是对网络带宽的浪费。这就涉及到一个重要的课题：如何高效地利用最少的计算资源在最适当的时候对数据进行操作。

在原来Oracle Database的基础上，为满足上面提到的两个基本点，Exadata进行了富有创新的对基本设施的改进。举一个例子，当数据刚从存贮结点扫描出来时，马上进行初步的加工，把无效的数据丢弃。同时，Exadata推出了一个实现了CPU，IO，Network之间平衡的典型的机器配置。这可以说是Oracle为业界推出了自己在Oracle Database的最佳实践的一个最佳解决方案。

那么，Exadata如何解决Network方面的瓶颈呢？

首先是Infiniband的运用。一个Infiniband的端口一般可以提供2GB/s的流量，这是千兆网的16倍以上，4Gb的光纤网络的5倍以上。

同时，Exadata只进行有效数据的传输，最具体讲，则是Smart Scan 技术的运用。举个例子，对于下面这个查询

SELECT a.no,
       sum(case
             when a.KEY IN ('A') then
              a.score * 2
             else
              a.score * 5
           end) score
  FROM fact_table a
 GROUP BY a.no

下面是一个可能的结果，第一行的数据是没有启用Smart Scan技术的结果，第二行是启用了Smart Scan的结果。

第一行比较容易理解，存贮阵列/结点的数据以7GB/s的速度通过Storage network传输到DB结点进行，DB CPU的利用率达到了57%。

显而易见，这时瓶颈出现在存贮网络上，如果启用了Smart Scan，则Exadata会在存贮结点上首先对数据进行处理(存贮结点的CPU利用率为30%)，然后把其中有效的数据以4GB/s的速度传输到DB结点进行处理，由于DB结点接收到更多的有效数据(90*7/45=14GB/s)，CPU也变得更加繁忙起来(81%)。

Exadata在这里做了哪些事情呢？

1. 只进行有效数据的传输，这里，只传输表fact_table里三列的数据(no, key和score)

2. 解决了原来pre-Exadata可能碰到的网络瓶颈问题

3. 让DB结点的CPU更加高效的利用起来