Tag Archives: Exadata

Oracle Exadata 技术浅析

自从 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 Compress

首先我们要搞清楚,什么是行压缩,什么叫列压缩。我们熟悉的数据库,如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-

稿件来源

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Oracle Exadata 的混合列压缩功能

Oracle 发布了关于 Exadata 的混合列压缩(Hybrid Columnar Compression)功能的白皮书(refer)。到现在这方面中文资料还比较少,所以分享一下我读这篇白皮书的笔记。Oracle 在这个文档中也提出了 数据仓库压缩(Warehouse Compression)与归档压缩(Archive Compression)两个概念上的”新”功能。

Oracle Block via http://www.dbasupport.com/img/gupta1.gif我们知道 Oracle 数据库引擎默认是以数据块(block)为存储单位,以数据行(row)作为存储与组织方式,当然理想情况是在一个数据块内存储更多的数据行,而实际上这样的方式对于一些列数较多的表不可避免的会带来存储空间的浪费。相反,以列(columnar)的方式组织、存储数据在空间上会带来很好的收益,但是对于依赖于行的查询,也是我们最常用的查询方式,则性能会差很多,而对于数据分析方面常见的汇总之类的查询,因为只需要扫描较少的数据块,就会达到很好的性能。可实际环境中,人们往往要熊掌与鱼兼得,为了达到空间和性能上的折衷,Oracle 引入了新的方式:用行与列混合的方式来存储数据。

Logical Compression Unit.jpg

如上面的示意图,从高一层抽象上看,引入了一个新的叫做压缩单元(compression unit,cu)的结构用于存储混合列压缩的行的集合。新的数据载入后,列值追加到旧有的行集合的后面,然后进行排序与分组等操作后进行压缩。这一系列动作完成后,组成一个压缩单元。直接一点说,也就是对列存储做分段处理,而压缩单元用来维系不同分段之间的关系。有个特别之处是,要使用批量装载(Bulk Loading)的方式,对于已经存储的数据依然可以应用 DML 操作。而 Exadata 引擎对待已经存入的数据的策略是按需进行解压缩。

这是与传统的 Oracle 数据库引擎所说的压缩截然不同的方式。至于数据仓库压缩与归档压缩的功能,看起来只是针对不同的场景而设置了不同的压缩密度而已。而 Oracle 之所以强调 Exadata 的压缩能力,我想更多是因为 Exadata 目前对于存储能力和价格上的限制吧。

EOF

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

OLTP Database Machine with Sun FlashFire Technology

Oracle 的这个 “the World’s First OLTP Database Machine with Sun FlashFire Technology” 有些唬人。FlashFire 是个什么东西? 看名字有些像 SSD 产品。可能是 Sun 原来的 F5100 系列的产品,号称 1U 闪存阵列能达到 100 万 IOPS ,10 GB/秒吞吐,听起来足够强悍。(refer)

至于之前和 HP 合作的 Exadata 产品线看来要没戏了(因为芯片用得是 Intel 的),个人不太看好Exadata ,总觉得会在公司角力中牺牲掉这个东西,何况技术上没有什么大的优势,尤其是 SSD 存储要起来的时候。

做个记号,等 Larry 大爷把谜底揭开后再补充…

EOF

更新:神秘兮兮的遮掩了好一段时间,原来还叫作 Exadata ,只不过是 Exadata 第二版。新的 Exadata 可以跑 OLTP,芯片就是 Intel Xeon (Nehalem) –我之前的猜测都不靠谱。至于软件方面,主要是 Oracle 11gR2 的新特性 Hybrid columnar 压缩有点意思,当然,这东西还不是彻底的列存储。

Jametong 同学推荐关于 Exadata 最权威的信息可以翻墙订阅:Kevin Closson’s Oracle Blog

更新:FlashFire 是 SLC(单层式储存) 的 SSD 。可以与 ZFS 友好集成。(refer)

探析 Oracle 的 Exadata Storage Server

数据库巨头 Oracle 一向不怎么涉足硬件领域,但这并不等于没有硬件方面的野心(过去折腾过几次都失败了)。这次在 Oracle Open World 上一下子宣布了两款 Exadata 系列的存储产品。一个是 Oracle Exadata Storage Server ,另外一个叫做 HP Oracle Database Machine 。

Exadata Storage Server 架构分析

该产品基本上可以看成是山寨版的存储集群。只是山寨主人财大气粗,所以比较唬人。

Exadata_Storage_Cell_Based_Configuration.png

如上图,是基于所谓的 Cell 的,每个 Cell 就是一个存储模块,乍看上去好像 HP 的 MSA 系列的东西 ,考虑到这东西能扩展能大柜子,又很像 HP 的 EVA 产品的变形(早就听说 EVA 准备推出 Cluster 的形式),不过接下来又看到每个 Cell 有自己的 CPU、内存、NIC,莫非就是个 PC ? 等我下载了一份 Data Sheet 看了一下,居然就是个 PC 服务器 ……

Exadata_Software_Architecture.png

从上图大致能看出来,Oracle 主要的还是想卖软件,企业管理器、念念不忘的 Automatic Storage Management(ASM),还有山寨版 RHEL –OEL 也在这个框架内。

名词解释:iDB

iDB – the Intelligent Database protocol. 这是这套系统中的一个亮点。iDB 在数据库核心层实现,直接映射操作到存储,减小不必要的开销。如果 iDB 真的能有效提升 IO 能力,那这个产品还是值得一用的。每个 Cell 是有计算能力的,实际上相当于 DB 把 SQL 扔给 Cell, Cell 返回结果给 DB 。iDB 能够运行在 InfiniBand 之上。

InfiniBand

Oracle 的 RAC 集群是 “Share Storage” 的,DB 节点间的高速通信其实是很容易撞上天花板。如果要提升集群能力,只靠 DB 本身的能力其实不大现实。这个 Exadata 的设计思路就是希翼通过硬件集群的能力来扩大 Oracle 本身的 I/O 能力,而 InfiniBand 交换机成了核心的组件。

实际上,InfiniBand 交换机的数量会是问题,只用一个,可靠性不高,用两个,成本又上去了。这个无疑会让用户左右摇摆。

HP Oracle Database Machine

相当于一个打包好了的产品,预装了 Oracle 企业版 Linux 与 Oracle DB 11g 软件,面向数据仓库环境。假想敌是 Teradata ?

结论

流水帐写了这么多,最后我个人认为该产品是否能被市场接受还要看定价,如果足够便宜,那么会有用户拿来做中低端的应用,如果 Oracle 必须要把内置的软件卖出价钱来,那恐怕竞争力并不是很强。

这并非一个会让人多么激动的产品。

EOF

附加:价格列表