Oracle Exadata技术浅析

2 1st, 2010 | Posted by jacky | Filed under 大话技术

自从Oracle和HP推出Exadata之后,我就很关注这个产品,之前也写了一篇Oracle database machine介绍它。去年,Oracle和SUN合并后,推出了Oracle Exadata V2,相比较上一代产品有几个变化:第一,使用SUN的硬件;第二,宣称支持OLTP应用;第三,Oracle 11g R2提供了更多的新特性。

Exadata Smart Flash Cache

Exadata V2整体架构并没有太多改变,换用了SUN的硬件,除了采用intel最新的nehalem CPU以外,每台storage cell更是配置了384GB的flash,这也是为什么V2可以支持OLTP应用的关键。

Flash cache完全是自动管理,Oracle会根据数据的访问情况,决定哪些数据放在flash cache中。所有的数据都是先被写到普通磁盘上,再根据访问情况读入flash cache的,所以如果flash card发生故障,数据不会丢失。当然,Oracle提供了方式,可以让用户手动将表或者索引pin在flash cache中。

在自动管理的方式之外,Oracle还允许用户人工创建flash disks,和普通磁盘一样,这些flash disks通过ASM输出给数据库使用,用户可以把一些访问非常频繁的数据文件放在上面。这些flash disks不仅仅是cache了,所以ASM会在cell和cell之间做镜像。如果某块卡发生故障,那么整个storage cell上的flash disks会offline,保证数据不会丢失。

Smart scan

Smart scan是Exadata最重要的一个功能,它的作用就是把SQL放在每个cell上去运行,然后每个cell只返回符合条件的数据给数据库,这样就极大的降低了数据库服务器的负载和网络流量,并充分利用了cell的计算资源和IO资源。

传统方式:所有的数据都需要返回给数据库服务器,网络带宽要求高,所有的计算在数据库服务器上完成。

Smart scan:只返回符合条件的数据,减少网络带宽,并充分利用了cell上的计算和IO资源。

这里有一点要注意,在使用smart scan时,每个cell返回给DB server的是结果集,而不再是传统的block,DB server完成结果集的处理,并返回给客户端。

Smart scan如何处理join?是我一直想要搞清楚的问题。事实上,smart scan只能处理join filtering,而真正join的工作必须在DB Server上完成,而且smart scan仅适合于处理DSS环境的复杂join,对于OLTP类型的简单join,smart scan并不能发挥其优势。设想下面的查询:

select e.ename,d.dname from emp e, dept d where and e.ename=’Jacky’ and e.deptno=d.deptno;

假设采用nested loops join,smart scan只能完成e.ename=’Jacky’这个条件的过滤,然后将符合条件的emp表的数据返回到DB server,然后由DB Server完成join的工作,逐条查询dept表(e.deptno=d.deptno)的数据。所以smart scan并不适合nested loop join(我认为smart scan只有在适合的条件下才会启用),只有DSS环境的大数据量复杂join才会发挥出优势。而且smart scan只能完成filtering的工作,而不能真正完成join的工作,这个与Greenplum数据库是不同的(有兴趣可以看我的文章,Greenplum技术浅析)。设想下面的查询(emp和dept都是大表):

select e.ename,d.dname from emp e, dept d where e.deptno=d.deptno;

假设采用hash join,由于没有任何过滤条件,smart scan只能把两个表的数据全部返回到DB Server上进行join操作,不过smart scan也不是一点用都没有,至少还可以进行column的过滤,只返回需要的字段就可以了。

Oracle的文档中,曾经提到对于一个大表和小表join时,smart scan会采用bloom filter来快速定位(可以看我以前的文章,有趣的bloom filter)。方法是把小表build成为bloom filter,然后在每个storage cell上对大表做scan,利用bloom filter快速定位符合条件的结果,并返回给DB Server作join。

Storage index

存储索引,顾名思义是在存储级别建立的索引,简单的说就是为表中的每一列数据建立一个索引,每个index entry记录一段数据区间的最大值,最小值以及它们的物理位置,文档上说1MB数据对应一条index entry,见下图:

如果我们查询B<2,或者B>8的数据,根据存储索引,我们就可以跳过这些不在min和max之间的数据块,极大的提高了扫描的速度,这就是存储索引的意义。

Hybrid Columnar Compressed

首先我们要搞清楚,什么是行压缩,什么叫列压缩。我们熟悉的数据库,如Oracle,MySQL等都是基于行的数据库,就是行的不同字段物理上存放在一起,还有一种是基于列的数据库,就是每个字段的不同行物理上存放在一起。他们的优缺点同样突出:

基于行的数据库,访问一行非常方便,但是由于同一列的数据是分开存放的,如果要针对某一列进行查询时,几乎要扫描整个表才能得到结果。基于行数据库的压缩,称为行压缩。

基于列的数据库,因为同一列的数据物理上放在一起,所以访问一列非常方便,也就是说如果针对某一列进行查询时,不需要扫描整个表,只需要扫描这一列的数据就可以了,但是访问一行的全部字段非常不方便(又是废话)。基于列数据库的压缩,称为列压缩。

Oracle通常说的compress功能(包括11g R2的Advanced compress),都是行压缩,因为Oracle是个基于行的数据库。大概的方法就是在block头部存放一个symbol table,然后将相同的值放在那里,每行上相同的数据指向symbol table,以此来达到压缩的目的。行压缩的效果通常不好,因为我们知道行与行之间,其实相同的数据并不多。但是列压缩则不同,因为相同列的数据类型相同,很容易达到很好的压缩效果。

行压缩和列压缩都有其优缺点,而Oracle的混合列压缩技术,实际上是融合了列压缩的高压缩比和行数据库的访问特性,将两者的优点结合起来。Oracle提出了CU的概念(compress unit),在一个CU内,是一个基于列的存储方式,采用列压缩,但是一个CU内保存了行的所有字段信息,所以在CU与CU之间,Oracle还是一个基于行的数据库,访问某一行,总是只在一个CU内。每个CU由一些连续的block组成,CU header中记录了每一行的各个列在CU中的分布情况,在混合列压缩模式下,一行通常是跨多个block的。

所以说混合列压缩,结合了列压缩和行访问的特点,即可以提供非常高的压缩率,又很好的保证了基于行类型的访问。

Exadata的另一个重要功能是IO resource management,如果我们在一个Exadata上部署了很多个数据库,可以用它来管理IO资源,这里就不作阐述了。

目前,我还没有了解到在国内有Exadata的应用,而且资料也是比较少的。希望有机会可以真实的测试一下它的性能,我不怀疑他在DSS环境下的表现,但是对于OLTP类型的应用,是否真的象Oracle说的那么强劲,还有待于验证。

–EOF–

标签: ,
  1. wanghai
    2 1st, 201022:31

    一个CU总是在一个block内?
    从图上看一个cu更像是一组连续分配的block,在第一个cu block里面存有cu header,cu header应该记载着每个列分别在cu的哪些block中。是否应该是这样?

  2. wanghai
    2 1st, 201023:41

    顺便google了一下,Arup Nanda写过一篇资料,http://www.oracle.com/technology/oramag/oracle/10-jan/o10compression.html

    大致能看清楚CU的构造,CU应该是一组的blocks构成。

    对于Hybrid Columnar Compressed,和纯列存储的压缩相比到底谁优谁劣永远也不会有个定论,因为完全是根据使用场景而变化的。但是至少可以说oracle在数据仓库领域又增加了那么一点点竞争力。

  3. alaiyeshi
    2 1st, 201023:50

    哇!很有价值的文章!

    我这边还有一点可以share的:今年Open World上Larry的那段演讲,只听他反复说Falsh Card is not Flash Disk。下来自己查了一下,原来Flash Card是PCIe的,不用HBA控制器,所以避免了传统Flash Disk HBA这个瓶颈。

  4. jacky
    2 2nd, 201010:18

    原来对于CU的理解有误,感谢七公的更正。

  5. Obuntu
    2 2nd, 201011:01

    挺好的~支持

    这方面资料确实少

  6. Kaya
    2 3rd, 201001:02

    –smart scan并不适合nested loop join(我认为smart scan只有在适合的条件下才会启用)

    目前而言“适合的条件”包括:
    1. 只用于direct read的场合(serial direct read或者parallel direct write),
    2. 只读入PGA而不读入SGA
    仔细想想就能明白为什么这样子了:)

  7. jacky
    2 3rd, 201009:12

    楼上的老兄来自Oracle,应该是正解了。事实上,我也订阅了你的blog:)

  8. Kaya
    2 3rd, 201011:52

    Thanks Jacky,

    btw, 有点笔误, parallel direct write -> parallel direct read

    http://www.os2ora.com/11g-new-feature-adaptive-direct-read/
    提到在oltp场合如何自动利用起smart scan的特性。当然,oltp会更加得益于flash cache

  9. 八神
    2 6th, 201022:31

    nest loop也应该可以使用smart scan,只不过上面的索引访问可能会有问题,索引不可能以结果集的方式打包出来,走的计划可能会是两个结果集的嵌套循环
    由于smart scan返回的只是结果集,而SGA的DATA BUFFER是以data block的形式存在的,在加上一致读,LRU等一系列的功能,这些基本很难在结果集这个格式上实现,所以smart scan只适用于direct read

  10. jacky
    2 6th, 201023:39

    目前看来,只有direct read时,才会使用smart scan。smart scan更多是针对DSS环境,不适合OLTP环境。
    就算nested loop可以使用smart scan,并没有带来更多的好处。

  11. wormwang
    2 25th, 201013:41

    我这管的项目买进了国内第一台Oracle DB Machine v2 OLTP。这周末到货。有兴趣请联系
    wormwang@yahoo.com