Exadata是什么？

在我们看来，它是一个把硬件和软件根据合理的配置整合在一起的 Oracle数据库(在本文编写时是11gR2版本)平台。Exadata数据库机器包含了存储子系统，在存储层上运行着研发的新软件，这使得研发人员可以做一些在其他平台上无法完成的事情。

实际上， Exadata 一开始是以一个存储系统形式诞生的，如果你跟参与研发此产品的人交谈，你经常会听到他们称存储组件为 Exadata 或者是 SAGE  ( Storage Appliance for Grid Environments ，网格环境存储设备)，这是该产品研发项目的代码名称。 Exadata 原本设计用来解决超大型数据库所存在的普遍性能瓶颈，也就是无法(在可接受时间内)从磁盘存储系统向数据库服务器传输足够大量的数据。 Oracle 一直以来都提供了非常快速的数据访问方式，主要是通过非常聪明的缓存技术，但是当数据库容量开始扩大到无法高效使用缓存技术的时候， Oracle 开始寻找一种解决方案，可以有效解决存在于存储层和数据库层之间的瓶颈。他们想出的解决方案是融合了硬件和软件的组合拳。如果你仔细想一下，也可以知道有两种方法可以减小这个瓶颈，第一种是让传输管道更大，虽然有很多组件参与其中，不过你可以简单地认为 Infiniband 就是这个更大的管道；第二种方法是减少需要传输的数据量，这是通过智能扫描( Smart Scan )来完成的。这套组合非常成功地解决了问题，但是不要误会，通过智能扫描实现的后者(第二种方法)才是真正的制胜秘诀。 Kevin说：如果前提是尽可能地减少对于 Oracle 数据库核心功能的修改的话，作者们对于减轻数据仓库 / 商业智能系统的存储和服务器之间瓶颈的方法论描述是正确的，不过实际上，从一个纯粹的计算机科学角度看，存储和服务器之间数据流问题的解决方案中还应该包括划分多个数据库实例读取数据的方法，也就是“shared-nothing”这种 MPP 方法。虽然这也值得一提，不过还是不把时间浪费在讨论 Oracle并未采用的方案上了。 Kevin说：在我看来，数据仓库 / 商业智能从业者，在 Oracle 环境中，如果对 Exadata 感兴趣，那么在了解 Exadata 其他方面之前，最应该先了解的是存储节点卸载(Offload)处理，而所有的其他技术都只是为了支持存储节点的卸载处理。比如，过早过多地关注 Exadata Infiniband 组件，就并非是深刻理解整个技术的最好方式，换句话说，我们在观察细节之前最好先欣赏全局。当我做Exadata 主题培训的时候，我都是从存储节点卸载处理开始，讲解下面四个概念。 存储节点卸载处理( Cell Offload Processing )：该工作由存储服务器完成，否则就必须在数据库服务器上执行。它包括的功能有智能扫描、数据文件初始化、RMAN offload和混合列式压缩解压(在没有内存并行查询的场景中)。 智能扫描( Smart Scan )：这是存储节点卸载处理中与提高数据仓库/ 商业智能查询性能的最有关系的操作，智能扫描是将数据文件初始化、字段投影、存储索引消减以及 HCC 解压等操作卸载到存储节点的方法。 全表扫描或者全索引快速扫描( Full Scan or Index Fast Full Scan )：为了触发智能扫描，查询优化器选择的必要的访问方法。 直接路径读取( Direct Path Read )：智能扫描需要的缓存模型，智能扫描的数据流是无法缓存在 SGA 缓冲池中的。直接路径读取可以串行也可以并行，缓冲在进程的 PGA ( heap )中。 Exadata概览 一图胜千言。图 1-1 展示了组成 Exadata 数据库机器的各部分的轮廓。

  当考虑 Exadata 的时候，如果在思想上将整个系统划分为两个部分会更好理解，即存储层和数据库层。两层之间用 Infiniband 网络来连接， Infiniband 提供了低延迟、高带宽的光纤通信链路，也提供了链路上的冗余和联结( bonding )。数据库层由多个 Sun 服务器组成，运行着 Oracle 11gR2 软件，虽然 RAC 实际上并不是必须的，但是这些服务器通常还是配置成一个或多个RAC 集群。 数据库服务器使用 ASM 来管理存储，即使数据库并不是配置成 RAC ， ASM 也是必须的。存储层同样由多个 Sun 服务器构成，每个存储服务器都包含 12 块磁盘，并且运行着 Oracle 存储服务器软件(称之为 cellsrv )。两层之间的通信通过 iDB 协议完成，这是一种使用 Infiniband 来实现的网络协议， iDB 用来将请求和请求的元数据(比如说查询谓词)传输到 cellsrv 中，在某些情况下， cellsrv 可以利用请求元数据来访问需要的数据，而后再将结果传输回数据库层。当 cellsrv 如此运作的时候，就被称为智能扫描，通常因此将会极大减少需要传输回数据库层的数据量。当无法使用智能扫描的时候， cellsrv 就会返回整个 Oracle 数据块。 iDB 使用的是 RDS 协议，这是一种低延迟的协议，跳过了内核调用，在 Infiniband 网络中通过远程直接内存访问( RDMA )来完成进程间通信。 Exadata的历史 自 2008 年首次发布以来， Exadata 已经经历了好几次重大变革。以下简要回顾产品的沿袭和与时俱进的变迁。 Kevin说：我想分享一些历史。在 Exadata 之前，我们有一个 SAGE——网格环境存储设备，这大概可以称为 V0 。实际上直到为了在 2008 年的 Open World 时大张旗鼓地跟惠普一起缔造一个超强联合品牌，拉里埃里森将之命名为 Exadata 之前的一星期，它还一直被称为 SAGE 。虽然 SAGE 的第一个实现版本完全采用了 HP 的硬件，不过 Oracle 始终没有认为这个平台一定要运行于 HP 硬件之上，在 Oracle 收购 Sun 后， Exadata 平台更是完全地采用了 Sun 的硬件。另一方面， Oracle 也没有认为数据库主机一定要运行于 Linux 操作系统之上，事实上就在收购 Sun 成为事实之前，把 iDB 移植到 HP-UX 安腾平台的开发工作已经接近尾声了。要说SAGE 的诞生，其实可以追溯到更早的时候。 V1：2008 年末发布的第一款 Exadata，被称为 V1 ，融合了 HP 的硬件和 Oracle 的软件。整体架构跟现在的 X2-2 版本相似，除了 Flash Cache 部分(这是在 V2 版本中新加入的)。Exadata V1 市场定位在纯粹的数据仓库平台。该产品广受关注但是并没有大面积部署，由于硬件过热带来的麻烦也让人头疼，总是听到“在机柜上都可以煎鸡蛋了”这样的说法。很多原先 V1 的客户后来都替换成了 V2 。 V2：2009 年的Open World上发布了Exadata 第2版本。这个版本是 Sun 和 Oracle 合作的产品。当发布该产品时， Oracle 已经在尝试收购 Sun 微系统公司。很多组件都升级到更大更快的版本，不过最大的区别是 V2 采用了大容量的固态存储。存储节点升级为使用了 384G 的 Exadata 智能闪存，而软件也同样升级，以充分发挥这些新缓存的效能。这让 Oracle 可以将产品定位于不仅仅是数据仓库的平台，由此打开了一个更大的市场。 X2：2010 年的Open World上发布了Exadata 第3版本，被称为 X2 。实际上 X2 有两个独立的版本。 X2-2 依循的是 V2 的基本架构，但是数据库服务器升级到了 8 台双 CPU 服务器， CPU 也升级到了 6 核，之前的V2 是 4 核。另外一个 X2 版本是 X2-8 ，它没有使用小型的 1U 数据库服务器，而是引入了更大的拥有 8´8 核 CPU 核、 1T 内存的更大的数据库服务器，由于具有更多的 CPU 和更大的内存， X2-8 的市场定位是为大型 OLTP 系统或者混合负载系统提供更强劲、更稳定的平台。 本文节选自《深入理解Oracle Exadata》一书，Kerry Osborne(凯里•奥斯本)、Randy Johnson(兰迪•约翰逊)、Tanel Põder(托内耳•卜戴德)著，黄凯耀，张乐奕，张瑞译，电子工业出版社出版。