Oracle去ioe分析

去IOE分析 郭峰 首席技术顾问 甲骨文中国系统事业部

什么是去IOE  什么是去IOE？ – IOE分别代表IBM，Oracle和EMC，从广义上讲，去IOE是去掉这三个公司高端的商业化

产品，目前大多数人谈及主要的意义是去IBM小型机，Oracle数据库和EMC的高端存储， 这三种产品在企业IT投资占很高的份额。

 去IOE和去O？ – 随着服务器X86化的趋势和分布式计算和存储的发展，一些大型的互联网企业开始尝试用

PC服务器代替小型机，这是去IOE的起始，然后逐渐用分布式计算和中低端存储替换掉 EMC的高端存储设备，通过大量研发工作定制适合特定业务场景并和应用高度绑定的 MySQL和Hadoop来替换Oracle数据库。

– 大多数IT人士承认，Oracle数据库由于其在某些应用场景下的很难替代性，往往是其中最

难去的。事实证明，去O的成本极高。相比去IE，去O的目标更难以实现。

 对System的影响 – X86化对SPARC 和集成系统的影响较大，绑定Oracle数据库，提供运行Oracle数据库的

最佳平台。

去IOE炒作

谁在去“IOE”

3 去“IOE”实现

2

2013年5月17日，阿里最后一 台IBM小机在支付宝下线。 7 月10日，淘宝重中之重的广告 系统Oracle数据库下线。

去“IOE”实践

1

去“IOE”提出 2008年，前微软亚洲研究院常 务副院长王坚加盟阿里巴巴成 为集团首席架构师，即现在的 首席技术官。2009年提出“去 IOE”战略。

2010年不再购买小型机， 2012年不购买EMC的设备， 2011年7月份完成商品库的首 个去IOE实践。

外界宣传及媒体介入

4

去“IOE”运动 2013年8月《商业价值》杂志发表王 坚采访文章《阿里巴巴为什么会“去 IOE”》，8月底中国软件开发者大 会上，周宝方分享了《阿里“去IOE” 战略》，引起业界广泛关注。

王坚

阿里巴巴集团首席技术官

信息来源： http://content.businessvalue.com.cn/post/13164.ht

淘宝的技术架构演进过程 * LAMP架构 * 数据库采几台MySQL集中

• •

* 大量采用PC server,采用本地

* 低端存储升级到高端存储

系统

数据量少 业务发展初期、类型单一，功能简单， MySQL能够承担 技术储备较少，采用简单架构 尽量低成本建设以降低运营成本

布式MySQL集群中

* PC server升级到IBM小型机

* 应用系统分为前台，后台两大

• •

* 核心业务从Oracle逐步迁到分

* MySQL迁到Oracle

• • •

业务快速发展，数据库处理能力要求 快速提升并稳定；以使得能够集中精 力发展业务 技术提升仍然较少，但各类技术人才 开始汇集 随着瓶颈开始出现，逐渐尝试拆分、 读写分离，逐步引入MySQL分担

硬盘

•

• • •

业务进一步壮大，扩展性与性能成为 核心业务诉求 有了一定的技术储备与经验，具备全 面迁移MySQL的能力 希望降低技术风险，提升掌控能力随 着不断扩容，商业方案成本压力出现 大量自研产品来提升系统能力， Oceanbase,Hbase,缓存,TDDL等

大量的技术尝试与验证、数据架构变化、数据迁移、应用改造、自研发工具…

业务特点与需求、技术能力是驱动其架构演进的主要因素。

淘宝系统架构示例

X86服务器为主+SSD+Fusion IO+MySQL+1/10Gbps网络  PB级海量数据，海量用户量 实行了大规模的水平+垂直分库 数据库以自定义化的MySQL为主 非结构化海量数据采用Hadoop 存储采用google相同架构的淘宝 OceanBase技术 主存储系统采用服务器内置SSD+FIO

淘宝系统架构特点及启示： 海量数据需求，超大并发访问； 软件解决核心的并行存储及访问问题； 存储即为服务器，具备大量的计算能力； 广泛采用sharding技术 大量采用Flash技术，降低延迟。 2011年Taobao MySQL服务器数量达到1000台

淘宝MySQL

www.alidata.org  淘宝数据产品选择MySQL的MyISAM引擎作为底层 的数据存储引擎。在此基础上，为了应对海量数据， 我们设计了分布式MySQL集群的查询代理层MyFOX ，使得分区对前端应用透明。  存储在MyFOX中的统计结果数据已经达到10TB，占 据着数据魔方总数据量的95%以上，并且正在以每天 超过6亿的增量增长着。这些数据被我们近似均匀地 分布到20个MySQL节点上，在查询时，经由MyFOX 透明地对外服务。  “热节点”存放最新的、被访问频率较高的数据。对 于这部分数据，给用户提供尽可能快的查询速度，所 以在硬盘方面，选择了每分钟15000转 的SAS硬盘， 按照一个节点两台机器来计算，单位数据的存储成本 约为4.5W/TB。相对应地，“冷数据”选择了每分钟 7500转的SATA硬盘，单碟上能够存放更多的数据， 存储成本约为1.6W/TB。

淘宝海量数据产品技术架构 www.alidata.org 关系型数据库仍然是王道

关系型数据库（RDBMS）自20世纪70年代提 出以来，在工业生产中得到了广泛的使用。经 过三十多年的长足发展，诞生了一批优秀的数 据库软件，例如Oracle、MySQL、DB2、 Sybase和SQL Server等。 尽管相对于非关系型数据库而言，关系型数 据库在分区容忍性方面存在劣势，但由于它强 大的语义表达能力以及数据之间的关系表达能 力，在数据产品中仍然占据着不可替代的作用。

淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群 我们称之为“云梯”，是计算层的主要组成部分。它的定位只是做离线计算的，无法支持较高的性能和并发需求。 存储层基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom。

阿里巴巴为什么去“IOE” 对外声称原因不可信

1. 专有设备技术封闭，高风险，难创新 技术路径上依赖于专用的硬件设备比较危险，随 处可以买到的Commodity PC的架构长远来讲对 于阿里和大多数企业则是最安全的; --王坚 技术面临失控，创新潜力受限； --周宝方 2. 满足不了业务增长 在互联网时代，不只是互联网企业，绝大部分企 业对计算需求难以通过IOE提供的技术来满足了; -王坚 集中式强大单点远远满足不了阿里特别是当时淘 宝爆炸式业务增长应用的模式; --周宝方 3. 降低成本 对于成本，我想说今天所有讲的开源技术只解决 了软件使用成本的问题，而忽略了开源软件的升 级和维护成本。 --王坚 这应该是整体最次的因素；--周宝方

1. 什么是真正的封闭？如何对待风险和创新？ 对于大多数企业而言，所谓专用设备也并非只有一 家之选，而且这些专用设备同样是遵循国际标准的， 实为开放标准。相反类似阿里的定制化策略才真正 意义上从开放走向了封闭，对于核心人员的依赖也 变得越来越重，失控风险巨大。 创新仅存在于企业本身的业务模式下，而且依靠少 量的技术人员只能勉强于业务支撑，创新乏力。 2. 满足不了业务增长？ 面向互联网企业IOE每个厂家都有其适用的产品和 解决方案，而超大型互联网企业如Yahoo、 Google采用自已的专有技术与自身实力和技术水 平相关，Amazon和eBay同样是Oracle的客户， PayPal目前是全球最大的Oracle OLTP应用，单库 规模接近100T。 3. 研发成本+风险成本>IOE成本? 去IOE只是降低了企业初期的采购成本（CAPEX）， 而后续运维成本（ OPEX）和机会成本 （OPPCOST）会大大增加。

核心：企业的业务需求决定

阿里去“IOE”商业层面解读 明修栈道，暗渡陈仓 

2009年9月，阿里巴巴集团在十周年庆典上宣布成立子公司“阿里 云”，该公司将专注于云计算领域的研究和研发。“阿里云”也成为 继阿里巴巴、淘宝、支付宝、阿里软件、中国雅虎之后的阿里巴巴集 团第八家子公司。阿里云的目标是要打造互联网数据分享的第一平台， 成为以数据为中心的先进的云计算服务公司。



2008年，王坚加盟阿里巴巴成为集团首席架构师，现任阿里云的首席 技术官。2012年10月，阿里云开发者大会上，王坚曾宣称：“阿里云 能在24个月内实现收支平衡。”

 阿里云提供的云服务（2013-09）

阿里云不仅提供公有云服务，在某些场合也会以方案提 供商出现，可以为客户提供云计算环境的搭建，因此在 云计算领域成为Oracle的竞争对手，阿里不再是客户。 本次去IOE的大肆高调，不排除为阿里云和阿里云解决 方案造势，服务于阿里巴巴集团整体上市的策略。

关系型数据库服务（Relational Database Service，简称RDS）是一种稳 定可靠、可弹性伸缩的在线数据库服务。RDS采用即开即用方式，兼容 MySQL、SQL Server两种关系型数据库，并提供数据库在线扩容、备份回 滚、性能监测及分析功能。RDS与云服务器搭配使用I/O性能倍增，内网互 通避免网络瓶颈。 开放存储服务（OpenStorageService，简称OSS），是阿里云对外提供的 海量，安全，低成本，高可靠的云存储服务。用户可以通过简单的API （REST方式的接口），在任何时间、任何地点、任何互联网设备上进行数 据上传和下载。

 2013年夏末，阿里集团正在酝酿上市，整体估价据分析超过千亿美金

企业该如何看待去“IOE” • 从了解自身的业务模式与应用特点出发  电商？WEB 2.0？传统行业？运营商？  数据量？访问量？应用量？  结构化 vs 半结构化 vs 非结构化？  交易型 vs 分析型？  ……

• 分析去IOE能够为自身企业带来什么？  开放性技术？二次被封闭？  满足业务支撑需求？扩展问题？  购买成本？维护成本？二次开发成本？  弹性？灵活性？  模仿秀？政绩工程？

从企业特点出发，关注业务需求

节省成本：80%有着去IOE想法的企业诉求 •

 采购成本

设备&软件 采购

（CAPEX）

供货/安装/调 测

 安装建设与集成成本  运行&维护成本

集成&服务

 环境成本

机房

 机会成本

空调 维护管理 升级

是TCO而不是采购成本

电源

故障损失 整合优化

（OPEX）

•

是性价比而不是价格

“有些业务去IOE不一定能够节省成本，因为MySQL单机性能低下， 一台ORACLE数据库往往需要拆分成多台MySQL数据库。这样硬件、 机房、电力加上为此投力的大量开发、测试项目团队，总体成本不一 定能够节省。”

突发事件

（OPPCOST）

服务器宕机1分钟，平均来说会使运输业损失15万美元，银行业损失 27万美元，通信业损失35万美元，制造业损失42万美元，而证券业损 失更高达45万美元。——Qualix Group

去IOE架构分析

阿里关系数据去IOE实现

传统IOE 集中式数据库

MySQL+ Sharding+x86

MPP+x86

NoSQL+x86

HDFS+ Mapreduce+x86

结构化为主，模式 固定

结构化为主， 模式固定

结构化为主，模式 固定

半/非结构化，模 式灵活

半/非结构化， 任意模式

通常在TB

通过分片扩展至PB

通常在TB

PB级支持

PB级支持

扩展方式

垂直+横向扩展

分片、读写分离、 Cluster等

横向扩展

横向扩展

横向扩展

扩展能力

较为受限，随着扩 展复杂度加大

较好，但对数据特 点（易拆分、弱关 系）有要求

较好

很好，理论上无限 扩展

很好，理论上无限扩 展

技术支持

好。商业产品的技 术支持

开源为主，一般无 技术支持。

好。商业产品的技 术支持

开源为主，一般无 技术支持。

开源为主，一般无技 术支持。

运维工具

完备

不完备，很多需要 自行开发

取决于不同产品的 提供

不完备，且功能较 弱

不完备，且功能较弱

数据特点

代表应用：

企业 CRM

电商前 端交易

企业数 据仓库

搜索、 社交

Web日 志分析

Oracle技术：帮助企业全面掌控各种架构 SQL

. . .

. . .

传统集中式IOE架构

MPP

MySQL+Sharding

分布式Hadoop/NoSQL

• Exadata

• Exadata

• Oracle Database

• Big Data Appliance

• • •

• •

• •

•

SuperCluster SPARC T5/Storage Oracle Database

更优秀的实现架构

Oracle Database In-Database Analytics Option

Oracle Dataguard Oracle GoldenGate

成熟的商业开放技术

•

Oracle NoSQL Database Oracle Big Data Connector

更低的总体拥有成本

Exadata：阿里去IOE核心技术的企业级实现

Infiniband 交换机 Exadata Cell

Exadata Cell

Exadata Cell

共同特点：并行处理、自动化容量扩展无需分库、大量采用Flash技术作为缓存，自动负载均衡。 Exadata优势：更大的互联带宽、并行写入，智能的数据扫描加速，混合列压缩节省空间提升扫 描速率，无数据丢失风险，结合了SD和SN两者优势，几千家企业采用的成熟架构。

Oracle高性能、高扩展数据库技术架构 数据仓库、事务处理、数据库整合

Scale-up （垂直扩展）和Scale-Out（水平扩展） 数据库网格 – 并行高可用集群RAC，同时具有很好的水平和 垂直扩占能力； – 高并发处理能力。  智能存储网格 – ASM：存储间数据冗余，存储空间支持在线扩 展，Share Nothing，MPP架构实现； – “Smart Scan”： 计算负载部分卸载至并行智 能存储层，并只传输经筛选的有效数据。 – 存储索引：消除不必要的I/O。  InfiniBand 网络 – 提供高带宽和低延时，消除存储和主机节点的 I/O瓶颈。  智能 PCI Flash 缓存 – Smart flash log 可以降低提交延时； – Smart flash cache可以降低读延时； – 缓存热数据；  综合列压缩(EHCC) – 10x－50x 超高压缩比，并提高磁盘I/O效率。  

参考案例：PayPal

"Most of that time was due to restarting the application tier," Das said. "PayPal is very happy with Exadata.

It is meeting all our SLAs.“ —Amit Das Engineering architect at PayPal

http://searchoracle.techtarget.com/feature/PayPal-completes-a-60-day-migration-to-Oracle-Exadata?asrc=EM_ERU_19021149

从Oracle到MySQL，余额宝云实践分享

http://www.csdn.net/article/2013-11-07/2817426-interview-financial-case-yuerbao-aliyun 余额宝是有一期和二期工程的,一期的时候是采用传统IOE的架构，总投资400 多万。二期时，如果还采用IOE的模式，初步估算至少需要投入5000万（主系 统+同城灾备+异地灾备等） 鲜为人知的技术实战。从传统封闭的IOE格局迁移到更加动态扩展、成本更经 济的云平台中，要跨越的障碍实在不少。

国际上，金融行业还也没有采用公有云平台的先例。这不仅是单纯的技术障碍， 还是意识、理解、勇气和监管要求等复杂交织的结果。 去IOE，硬件相对容易些，最难的是与应用密切相关的数据库。 Oracle数据库 向MySQL转换的时候，连最简单的批量插入，由于对于底层理解的不同，都 有很多问题。在Oracle中，开发者是不需要关心底层问题的，但在MySQL则 不同，要关注很多。批量提交，事务开启还是关闭，都需要人为干预。 业内认为MySQL无法支撑大数据清算，这是有根据的。总归是可以化整为零， 用水平化、分库分表等方式，并行化思路来解决，用小单位来解决问题的。虽 然在迁移中，对中间层的要求更高，但是可行的。 采用了50个MySQL实例的方式。但需要天弘将业务逻辑、应用层所用的数据 库通过一个维度来进行水平拆分，然后将这些业务平均分配在这50个MySQL 实例上，以保证每一个MySQL的性能负载比较平均，从而实现用50个MySQL 来支撑的大业务量。

慎重考虑“重新发明轮子” 选择成熟的产品，避免不必要的试错 “加班严重，精神压力大。老有问题解决不了啊,压在身上...去O不是关键，节省成本才是问题的核 心。EMC AIX 是成本的关键；适合的场景选择适合的软硬件结构；能不动，就不动，避免瞎折 腾。” ——淘宝高级技术专家王晶昱 “去IOE需要很高的技术门槛、较大技术风险、水很深。开源只是在入手时零成本，而后（对传统 企业）会是极高的维持和发展成本，这并不为很多人所意识到” ——阿里技术保障部DBA负责人周宝方 “考虑一个架构的成本，不能单从一个角度考虑，一个单机的情况，MySQL以及NoSQL一定比 Oracle便宜，但是，由于MySQL、NoSQL的特性，有些功能无法支持，规模上去之后，相应的机 架、电力、运维成本也会上升，采用Scale Out的架构其实很多时候只是因为Scale Up的代价已经 承受不了了” ——支付宝资深数据库架构师@jametong(童家旺) “成本是梦魇，MySQL方案将是现在所需服务器的5-7倍，Postgresql也差不多，很多NoSQL产 品的性能只是传说” ——淘宝数据部高级技术专家张茂森

“选择技术要考虑：场景，成本和控制力，互联网的玩法并不一定适合企业级应用。IBM、 Oracle、EMC主要面向企业级领域，单论技术含量在各自领域都是No1。其实，玩开源的大部分 也就是搭积木作方案而已，谁也别嘲笑谁人傻钱多，别人玩得转未必适合自己。” ——致力于推广去IOE经验的阿里巴巴集团数据库架构师张瑞

Datacenter of the Future BACKUP

 Datacenter Core  Intel 2-socket X86 servers  Virtualized Linux  Ethernet Interconnect  Plus Purpose Built Specialized Machines  Best Cost/Performance  More Reliable & Secure  Much Easier to Use

ANALYTICS

CORE DATABASE

Solaris 数据库优化特性 Solaris 11 重要特性与 S11.1 新增特性

性能

可靠性和可用性

安全性

大分页支持 完全多线程热内核，扩展到数百个内核、数万个硬件线程 高分辨率计时器性能提升 5 倍 NUMA I/O 框架 uDAPL、RDSv1、RDSv3、SDP：支持低延迟 Infiniband 协议 Oracle RAC 内核锁加速 Exafusion 可感知延迟的内核内存分配器（x86、SPARC） 重建虚拟内存子系统 用户环境快速内存注册和共享保护域 面向 Oracle 数据库的多处理和多线程支持 增强段错误的可观察性 由 Oracle 读取 dtrace IO 通过面向数据库的动态重新配置通知实现资源再平衡 针对硬件停机的 FMA 回调 通过优化的共享内存 (OSM) 实现动态 SGA 调整 针对 IB HCA 的动态重新配置

透明加密分流 针对 RDSv3 的专属 IP 区域支持，可在 SuperCluster 上支持 DBaaS Solaris 审计功能与 Oracle Audit Vault 相集成

Solaris针对Java的优化特性 Solaris 11 重要特性与 S11.1 新增特性

CPU

Memory I/O

Security

User-level high resolution timer support WLS scalability, Single-thread mode smt pause() to optimize busy waits in the JVM Java-optimized Solaris scheduling class Fused compare-and-branch with no delay slot New block initializing store (BIS instruction) Large Page support by JVM SPARC T 2GB pages for Java performance SDP: Support for low-latency Infiniband protocol HA for SDP

Integration with Solaris crypto offload engines (Java 7u4) Zones support for SDP Zones: Secure isolation, lowest latency virtualization

Observability DTrace plugin in Java Mission Control