Oracle Exadata技术浅析

原文来自于DBA同事的邮件

Oracle Exadata ，号称是这个星球上最power的数据库软硬件一体机（在Oracle 

open world上，larry更是放出豪言：如果谁能证明Exadata不比IBM集群快两倍以上，就奖励1000万美金）。

写了一篇文章，很多思路值得我们借鉴：flash技术的引入，ASM对于存储的廉价扩容，infiniband高速互联，利用普通PC server搭建高性能计算机群（实际上Exadata就是由廉价PC搭建起来的），这些技术和方案我们都正在尝试，并已经看到了成果。

正文：

自从 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说的那么强劲，还有待于验证。

 

 

原文链接发表在我的blog：http://www.hellodba.net/2010/02/oracle_exadata.html#comments

其他相关文章：

Greenplum 技术浅析：http://www.hellodba.net/2009/07/greenplum.html

有趣的bloom filter：http://www.hellodba.net/2009/04/bloom_filter.html