oracle cloud computing solution...数据、mis财务数 据、网络信令等业务...
TRANSCRIPT
提纲
• 运营商企业数据仓库基础平台面临的挑战
• 传统数据库架构和面临的主要问题
• Exadata数据库云平台的优势和特点
• Exadata相比MPP架构集群的优势
电信EDA面临的挑战：海量数据管理、长尾市场快速多变的业务、多样的数据处理需求
‐网络QoS分析
‐安全入侵分析
‐网络规划
‐信令监测分析
‐ ……
网络优化
‐移动信息搜索
‐个人空间
‐智能业务推荐
‐计算和存储服务
‐ ……
移动互联网应用
‐用户行为分析
‐客户流失预测
‐业务关联分析
‐垃圾短信过滤
‐……
精准营销
互联网领域业务和3G发展对于业务分析需求巨大
中国电信拥有世界上最大的EDA，海量数据存储和处理需求巨大
数据量（单位：T
B
）
中国电信EDA容量/数据规模趋势图
0
2000
4000
6000
8000
10000
2006 2007 2008 2009
系统容量 数据规模•数据源：于中国移动
新业务发展趋势
计算和存储趋势
应用需求不断涌现对EDA要求不断提高
渠道偏好分析
终端捆绑分析
垃圾短信治理
手机报精确营销
新业务关联分析
地市营业业绩跟踪
客户经理告警
营销方案预演
客户群体模式识别
客户信用度分析及欠费控制
对手高端客户分析
不断增加的EDA数据应用需求
大量新业务应用需求不断涌现，需要EDA具备高性能、集成化、快速部署、资源自动适配的能力
中国电信EDA体系
中国电信EDA体系是由多套系统组合而成，主要包括ODS、EDW、DataMart、数据挖掘、多维分析、ETL、元数据管理、历史数据库等多套独立建设的系统。每个系统拥有自己独立的主机、网络、存储等资源。各个系统间资源互相独立、无法有效共享，非常有必要利用“云计算”的技术进行建设，使得在计算效率提高的同时资源得到最大程度共享。
CMCC NGBASS-3.0时代的新业务驱动力
6
•3G业务运营支撑•全业务运营支撑•互联网业务运营支撑•业务基地运营支撑•其它智能部门业务支撑
•一级经分与省级经分之间数据互通
、应用互访
•省级经分之间应用互访、应用共享
•对BOSS/CRM等系统服务能力提供
•对外信息服务提供能力
1 2 3
对外服务提供能力
经分系统自身互通能力
业务支撑能力
• 全面性：需要扩充系统的数据源(全业务数据、互联网数据、业务基地数据、网络部、财务部等部门数据)
• 实时性：满足精细化营销对应用的响应要求
• 准确性：满足财务部等部门对应用需求数据质量的高准确性要求
• 应用互访：要求一点登录，全网访问，实现应用互访
• 应用共享：要求对应用实现标准、组件化，实现经分系统应用的共享、复用
• 开放式平台：要求做到经分系统开放式平台，达到百花齐放、共同提升的目的
• 质量监控：要求通过应用、功能互访，加强对系统数据质量的监控
•外围系统：实现经分系统与外围系统(BOSS/CRM/BOMC等)流程无缝嵌入
•合作伙伴：实现对SP、终端供应商等合作伙伴能力提供
•商业价值：实现google、亚马逊等商业模式引入，提升系统价值
NG3时代对BASS能力的要求
7
系统应用的快速增长，对
系统资源要求的快速膨
胀，需要对资源进行合理
化分配
系统建设的持续投资，需
要对目前、今后的硬件投
入进行合理分配，到达资
源使用价值的最大化
系统建设的大规模投资、
重复投资情况需要对投资
成本进行优化
为了提升系统建设投入产
出比率，需要提升系统的
使用价值，优化投资成本
系统应用服务对象的差
异，需要对系统资源进行
灵活分配；
系统应用的实时响应要求
的差异，需要对系统资源
进行灵活分配
资源的合理分配 资源的灵活分配 投资成本优化
通过对IT相关技术的引用，结合经分系统发展中的资源要求，实现系统资源合理化、灵活
性分配的目的，提升投资收益比率；
NG3.5时代的建设目标
8
夯实数据基础，进一步丰富一类业务平台数据、MIS财务数据、网络信令等业务数据，加强逻辑模型标准化建设，提升数据服务的标准化能力，推劢系统内部解耦及外部应用移植。
构建自劣分析模块，加强数据挖掘应用落地，强化一线支撑能力。
增强核心元模型标准化及元数据管理功能，实现基于规则配置的数据质量监控稽核及分层分级告警管理，建立两级数据质量联劢机制，实现经营分析应用全流程安全管控，进一步强化数据管理及安全管理能力。
以“两个夯实、两个强化”为建设目标，实现“高效低成本”的全业务运营支撑：在NG2-BASS 3.0工程的基础上，进一步丰富经营分析系统数据源，提升数据的标准化服务能力，推劢系统解耦及应用移植；增强数据质量及安全管控；强化一线支撑和重点应用建设，为全业务竞争环境下的企业运营管理提供高效低成本的支撑能力。
1 3 42
夯实应用基础，凸显数据挖掘模型价值，强化垃圾短信治理、渠道运营监控、校园市场等重点应用，提升运营管理及客户营销服务支撑的智能化水平。
进一步增加分析数据来源
9
业务支撑网接入网关
省级业务支撑系统
NG2-BOSS
NG2-BOMC
4A管理平台
NG2-CRM
营销池
短信网关
邮件网关
彩信网关
业务支撑网接口域
业务支撑网接口域
省级经营分析系统
R2
R1
R2'
访问层
获取层
数据封装
一经接口
系统安全管理R1' R7
省级其它数据源系统
网管系统
DSMP平台
OTA平台
网络信令采集子系统
WAP网关
R8"R7'
VGOP
R4
R94R4'
ERP/MIS
R3"
R91
信息推送
R93
R92
R95
R97ESOP
R5'
彩铃平台
R96
一级业务支撑系统
一级经营分析系统
中央业务平台
行业应用终端监控平台
新业务营销体验平台
R6
与VGOP的关系
R4：省级经营分析系统通过省级VGOP获取一类业务数据，包括中央音乐平台/无线音乐俱乐部、手机报平台、飞信平台、DM平台、手机视频平台、手机阅读、手机支付、手机游戏、PushEmail和12580综合信息平台等相关数据。随着VGOP业务支撑范围的扩展，本期经分将新增从VGOP获取MM平台、号簿管家平台、手机导航平台、音乐搜索平台等一类业务数据源。省级经营分析通过省级VGOP获取部分二、三类业务数据：如省公司彩铃平台数据。
R4’：省级经营分析系统通过增值业务数据集市以数据封装的方式为VGOP提供各类增值业务的分析数据、客户画像数据以及营销方案等信息。VGOP的营销功能应复用经营分析系统客户分析及运营模块的营销服务管理功能。
修订与网络信令采集子系统关系 修订ERP/MIS系统的关系 修订与VGOP的关系
与网络信令采集子系统的关系
R96：网络信令采集子系统为省级经营分析系统提供网络信令数据。本期规范对网络语音类信令（A接口）及网络数据类信令（Gb接口）数据的采集及相关应用建设提出了明确要求。与ERP/MIS系统的关系
R97：ERP/MIS为省级经营分析系统提供各类财务成本数据，包括广告成本、宣传成本、通信成本、营销机构成本、移动网业务成本、销售费用和管理费用等。本期规范对新增的收入、成本等财务数据的采集及相关应用建设提出了明确要求。
数据仓库作用正在逐渐发生转变：从后到前、从内到外
数据仓库正在不断加强实时性、个性化、服务化支撑
数据仓库低成本、资源共享的需求
经分发展趋势
企业跨域数据整合
专业化、差异化
面向生产一体化
集中化
理想的支撑平台
海量数据、高并行支持
混合型应用、资源共享
应用高并发、实时交易数据处理
虚拟化、高扩展、低能耗云平台
理想的数据仓库平台需要具备的能力
统
分
符合云计算特征的理想化支撑平台
Shared Disk和Shared Nothing 并重
虚拟化、资源池
资源动态调配
海量数据处理、高并行
高实时性、高并发
在线高扩展、高可靠
提纲
• 运营商企业数据仓库基础平台面临的挑战
• 传统数据库架构和面临的主要问题
• Exadata数据库云平台的优势和特点
• Exadata相比MPP架构集群的优势
问题1：随着系统规模增加，传统数据库架构瓶颈凸显
• 存储层：1）数据量不断增加，带来的IO瓶颈；2）随着数据长时间运行带来
的数据分布不均匀，存在IO热点 3）存储内部的DA通道瓶颈
•网络层：传输带宽不足，无法快速传输大量数据到服务器
•服务器层：接收过多数据进行处理，内存优势无法发挥
FC盘阵内部的共享后端FC DA通道
大部分情况下30块以上的硬盘共享一个后端FC（8Gb/4Gb）通道
极端情况下存在多达240块盘共享一条4G bFC通道
传统数据库平台架构问题2：传统存储阵列架构本身存在严重IO瓶颈
某高端存储的存储瓶颈单块硬盘吞吐<50MB/Sec 服务器级别硬盘顺序读取最低速度：120MB/Sec
7200RPM硬盘的吞吐量
问题2：传统存储阵列架构本身存在严重IO瓶颈
另一知名厂家存储的瓶颈
单块硬盘吞吐<15MB/Sec 单块硬盘吞吐<15MB/Sec
问题2：传统存储阵列架构本身存在严重IO瓶颈
某知名厂家最高端存储的瓶颈：8对4Gb loop连接240块盘
Virtual MatrixInterconnect
Engine
Director
每个FC通道能提供的IOPS数量
每个后端DA通道10万IOPS
传统存储在使用SSD/FLASH上存在瓶颈
•任何部件配置不合理都会导致可靠性问题
•端到端的数据库高可用性出整体方案还必须考虑以下所有方面:
• 服务器OS版本号补丁号
• FC多路径驱动版本号
• FC交换机微码版本
• 以太网交换机微码版本
• HBA卡微码版本
• 以太网拓扑实现
• SAN网络拓扑实现
• 存储微码版本
• 存储虚拟化硬件微码版本
• 存储内部连接方式等等
复杂的数据库系统设计优化(可靠性)
FC-Switch1 FC-Switch2
Disk
Array 1
Disk
Array 2
Disk
Array 3
Disk
Array 4
Disk
Array 5
Disk
Array 6
Disk
Array 7
Disk
Array 8
HB
A1
HB
A2
HB
A1
HB
A2
HB
A1
HB
A2
HB
A1
HB
A2 HBA卡的多路径驱动软件POWERPATH必须
是XX.XX以上，HBA卡的微码最好为A.B或者A.C…
FC交换机的微码必须为XX.XX或者以上，必须实现多路径冗余…
磁盘阵列的微码版本
服务器应该采用的OS版本为AIX 6.1TL3，必须安装SP3，必须安装IFXXX等补丁。
复杂的数据库系统设计优化(性能)
•任何部件配置不均衡会导致系统瓶颈
•数据库配置需要考虑下面所有部件配置:
• CPU: 数量和速度
• HBA (Host Bus Adapter):数量和速度
• Switch speed
• Controller:数量和速度
• Disk:数量和速度
FC-Switch1 FC-Switch2
Disk
Array 1
Disk
Array 2
Disk
Array 3
Disk
Array 4
Disk
Array 5
Disk
Array 6
Disk
Array 7
Disk
Array 8
HB
A1
HB
A2
HB
A1
HB
A2
HB
A1
HB
A2
HB
A1
HB
A2 每台机器有2 个8 Gb HBA卡
所有 8个 HBA卡能处理数据：
8 * 800MB/s*2 = 12.8GB/s
每个交换机口能够支持8Gbps 的吞吐能力，每个交换机能够支持总共6.4GB/s的数据处理能力，两台一共支持12.8GB/s
每个磁盘组DA有一个8Gbps的控制器。所有16个磁盘控制器能处理数据：16* 800MB/s = 12.8GB/s
每台机器有16 个CPU。
所有4个服务器一共能同时处理数据：64 * 200MB/s = 12.8GB/s
每块磁盘的数据处理能力为120MB/s，所以一个磁盘组至少需要8块磁盘来达到960MB/s的数据处理能力
问题4：系统的维护和扩容过程复杂
均衡化配置方法论 分区和HA规划
网络互联配置规划 数据库存储规划
问题5：多系统资源互相独立，无法共享有些资源过度，有些资源不足，由于生产环境动态变化，无法动态满足
Database Servers
Storage Arrays
静态的应用运行基础设施
100%
0%50
%
15% Utilized Servers
100%
0%50
%
10% Utilized Servers
100%
0%50
%
20% Utilized Servers
Cluster 1 Cluster 2 Cluster 3
55% Utilized Servers75% Utilized Servers100% Utilized Servers
数据仓库 地市数据集市 数据挖掘
静态的应用运行基础设施
100%
0%50
%
15% Utilized Servers
100%
0%50
%
10% Utilized Servers
Cluster 1 Cluster 2 Cluster 3
100% Utilized Servers
数据仓库 地市数据集市 数据挖掘
问题6：有限的压缩在海量数据面前无能为力
现有的压缩方式
Row 1
Symbol Table
Row 2
Row 3
Database Block
•2x - 5x 压缩•大部分情况只有3倍左右压缩比
500TB…1000TB
=
海量数据由于压缩比低，需要大量的存储
大量的存储需要大量的机房、供电、制冷、维护
极大的投资和运维成本
问题6：不同数据库操作类型间的冲突（OLTP与DW）高并发和高并行
提纲
• 运营商企业数据仓库基础平台面临的挑战
• 传统数据库架构和面临的主要问题
• Exadata数据库云平台的优势和特点
• Exadata相比MPP架构集群的优势
解决思路：减轻负载、加宽通道、提高并行、混合架构
数据库架构解决思路：
1. 混合架构适用于混合型数据处理
2. 加宽通道、增加通道数量
3. 减少需要传送到服务器处理的数据量
4. 端到端工程化设计实现最佳性能和可靠性
集群式数据库架构：Shared Nothing 和Shared Disk最佳OLTP和最佳OLAP应用
Shared Disk和Shared Nothing是两种主要的数据库集群技术，各自都有自身特点
Shared Disk把数据传输到应用代码端 Shared Nothing把应用代码移到数据端运行
当应用代码量很大（高并发）、相关数据量比
较小时，Shared Disk更加适合这种典型的OLTP
应用；
主要特点：高并发、高可用性（由于数据共享
，当节点故障可以透明切换到其他数据库节点
运行作业）
当相关数据量很大（高并行）、而应用代码并
发量很小时，Shared Nothing更加适合这种典型
的OLAP应用；
主要特点：大数据量处理高并行、低并发、低可用性（由于数据非共享，当节点故障，其他节点要接管故障节点数据）
Exadata特点1：混合架构兼备Shared Nothing 、Shared Disk、分片式数据库、读写分离数据库架构
Exadata Cell
InfiniBand 交换网络
数据库服务池A 数据库服务池B
Exadata Cell Exadata Cell
智能存储层(Shared Nothing)
存储资源池
数据库处理层(Shared Disk)
数据库资源池
超高速并发网络层880Gb/s/机架
…….
Exadata提供一种混合式的数据库架构,能够有效解决两者的冲突,吸取两种架构长处; 既可以满足OLTP的高并发、高可用特点；又可以满足OLAP的大数据量处理要求；
具备良好的普适性架构:Shared
Nothing and Shared Disk
34
SunFire SunFire SunFire
高扩展高可靠OLTP海量数据处理SLA资源虚拟化架构优势
Exadata设计原则1：存储层智能化、数据预处理能力
…
Exadata Cell
Disk…
Disk
Exadata CellExadata
software
Exadata
software
Oracle Database Servers
Exadata高性能特点：存储智能化预处理提供分布式、并行化存储预处理能力
高扩展高可靠OLTPSLA资源虚拟化架构优势 海量数据处理
Client
Storage
DB
SELECT count(revenue)
FROM sales WHERE discount = 6%;
找到表的Extents
发起IO
I/Os 被执行:
1 terabyte 的数据返回主机
数据库主机吧TB的数据缩减成2MB的满足查询条件的数据返回客户端
获得对应的行
• 传统存储的所有逻辑处理都是在数据库层完成，存储只做简单的IO
• 大量从存储返回到数据库主机的数据实际上是被丢弃了
• 这些被丢弃的数据消耗的宝贵的资源，而且影响了性能和工作负载
传统数据库的处理过程
Exadata Smart Scan 的
Client
Storage
DB
只返回2MB数据给服务器
返回结果集
主机构建Smart Scan Constructed 消息并且传递给cell
Smart Scan 在TB级别的数据中知道需要的行和列
DB服务器聚合所有cell返回的结果
SELECT
count(revenue)
FROM sales WHERE discount = 6%;
• 只返回有效的列revenue和需要的行(where discount = 6%)
• CPU的消耗被大部分下压到存储
• 让数据库主机从表扫描的压力中释放出来，并且避免了大量的无用信息
• 返回需要的针，而不是整堆稻草
Exadata 智能存储的能力
- 行过滤:
- 只将需要的部分行返回给数据库节点，而不是扫描的所有整行.
- 列过滤:
- 只返回查询需要的行给数据库节点.
- Join 处理:
- 简单连接在智能存储内部处理处理.
- 扫描加密数据
- SQL函数
- 数据挖掘评分:
- All data mining scoring functions are offloaded.
- Up to 10x performance gains.
- 备份:
- 加快增量备份扫描.
- 创建/扩展表空间
Exadata 存储索引示例表 SALES –
• 存储索引将无关data chunk忽略掉
• 提供类似分区修剪的功能
WHERE ship_date between ’01-SEP-2009’ and ’31-SEP-2009’
排除 data chunk #2
03-NOV-200901-OCT-2009Ship_date
07-OCT-200905-SEP-2009Ship_date
Data Chunk #1
03-SEP-200903-SEP-2009Order_date
8030010000Cust_ID
300002030Prod_ID
40,00010,000Amount
20,00010,000Amount
Data Chunk #2
MIN MAX
Order_date 03-SEP-2009 03-SEP-2009
Cust_ID 10075 20098
Prod_ID 20010 32932
03-NOV-2009
19-OCT-2009
01-OCT-2009
07-OCT-2009
05-SEP-2009
19-SEP-2009
Ship_dateOrder_date Cust_ID Prod_ID Amount
03-SEP-2009 10075 32932 10,000.00
03-SEP-2009 20098 20098 20,000.00
03-SEP-2009 10089 20010 15,000.00
03-SEP-2009 20100 10000 35,000.00
03-SEP-2009 80300 30000 10,000.00
03-SEP-2009 10000 2030 40,000.00
x
高扩展高可靠OLTP资源虚拟化架构优势 海量数据处理
Exadata设计原则2：资源共享和资源控制
I/O Resource Management
Oracle Database Servers
Smart
storage
operations
Storage
consolidation(Transparent to
databases)
High performance
storage network
Data compression
动态的数据库运行平台实现资源共享
Cluster 1 Cluster 2 Cluster 3
ODS VAS数据集市
100%
0%50
%
55%* Utilized Servers
One Resource Pool
EDW 地市数据集市省数据集市
Exadata数据库云特点2 ：服务器资源池“大分小”和“小合大”，支持数据库云平台对应用的多样性需求
Data Warehouse Data Mart/VGOP ESOP/Data Mining Free
Data Warehouse
Data Mart/VGOP
ESOP/Data Mining
Free
RAC One Node D
cpu_count=1
RAC One Node C
cpu_count=1
RAC One Node Bcpu_count=2
RAC One Node Acpu_count=4
8 core server
高扩展高可靠OLTP海量数据处理SLA架构优势 资源虚拟化
OLTP
More resources
DSS
user
OLTP
user
Database resource manager
DSS Less resources Oracle
Database
Exadata数据库云特点4：多租户资源管理适合云平台对多租户的资源（CPU、内存、存储、IO等）调配和管理
- 管理混合事务的资源负载
- 控制系统性能
高扩展高可靠OLTP海量数据处理架构优势 资源虚拟化 SLA
Exadata数据库云特点4：多租户资源管理适合云平台对多租户的资源（CPU、内存、存储、IO等）调配和管理
• 确保共享的不同数据库被分配正确的I/O
资源
• Database A: 33% I/O资源
• Database B: 67% I/O资源
• 确保库间、库内的不同用户和任务被分配正确的I/O资源
• Database A:
• 报表: 60% of I/O资源
• ETL: 40% of I/O资源
• Database B:
• 交互作业: 30% of I/O资源
• 批处理: 70% of I/O资源
Exadata Cell
InfiniBand Switch/Network
Database A Database B
Exadata Cell Exadata Cell
高扩展高可靠OLTP海量数据处理架构优势 资源虚拟化 SLA
Exadata设计原则：没有任何瓶颈的IO
• 12块磁盘共享的上端通道为PCIE
2.0 4X=2GB/s全双工
• 单块磁盘能获得160MB/S全双工带宽
• 存储节点到主机节点带宽为40Gb/s(4GB/s)
• IB卡采用PCIE 2.0 8X接口，提供4GB/S全双工带宽
• 采用4块PCIE接口FLASH卡，不和磁盘争用磁盘控制器
47
2.5
6
911 *
25
75
IBM XIV NetApp 6080
IBM DS8700
Hitachi USP V
EMC VMAX
Exadata Disk
Exadata Flash
查询IO吞吐量
GB/S
* Undisclosed by vendor
Exadata惊人的IO吞吐量
Exadata 获得:
75 GB/S 查询吞吐量
150万IOPS
实际测试结果:
通过数据库8K 的非压缩IO
Exadata的基本性能指标
项目 Exadata¼配置Exadata½配置
Exadata
Full Rack
处理器核数 24 DB+36存储 Intel 48 DB+ 84存储 Intel 96DB+168存储Intel
存储节点 3 (36 disks) 7 (84 disks) 14 (168 disks)
总计算能力(specint_rate2006) 1540 3500 7000
I/O 吞吐量 (disks) 5.4GB/sec 12.5GB/sec 25GB/sec
I/O 吞吐量 (flash) 16GB/sec 37.5 GB/sec 75GB/sec
实际DW有效吞吐量经验值（disk + flash*0.3)
10.2GB/sec 23.5GB/sec 47.5GB/sec
机架位置需求 1(实际占用1/4) 1(实际占用1/2) 1
典型功耗(KW) 2.7 5.1 9.8
最大功耗(KW) 3.6 7.2 14
½配置实际的吞吐量
DISK和FLASH提供的总吞吐量超过30GB/s
Exadata高性能特点：DB节点互联技术创新
• 与GE相比
• 带宽的提升：40Gb/s VS 1Gb/s
• 延迟的降低：1us VS 100-200 us
• 通信协议的提升： RDS(mtu 64K) VS UDP(mtu <1000)
Hardware
Kernel
User
HCANIC
RAC
Database
IPCLibrary
UDP
IPoIB
IP
Hardware
Kernel
User
HCANIC
IB/RDS
IPC Library
RAC
Database
FC随机IO时的CPU消耗@8 CPU rx6600
FC连续IO时的CPU消耗@8 CPU rx6600
FC测试参考
存储IO技术对比
• Exadata解决方案- Exadata Infiniband方式(远比传统FC技术高效、CPU开销小)
- 有效IO速率：
- 在Exadata方式下，单路可以看到3.6GB/s以上的IO能力，是FC的10倍到20倍
- CPU消耗
- 鉴于40Gb/s的传输速率是FC的10倍，故软件设计上没有采用传统的驱动方式，而采用了RDMA/RDS/iDB（远程DMA操作之上的数据库块传送），40Gb/s IO只会占用2-3%左右的CPU资源
• 传统HP/IBM方案 - 小机传统FC光通道方式
- 有效IO速率：在典型场景下，4Gb FC的有效传输效率通常在 200-300MB/s左右，而不是 400MB/s，因为：
- 阵列控制卡资源配置通常没达到理想值
- Cache资源配置通常没达到理想值
- 后端FC环路配置通常没达到理想值
- 磁盘组的划分方式受限
- 阵列内部其它资源限制
- CPU消耗
- 从HP的FC测试来看，FC对CPU的消耗非常大(单路甚至高达19.4%)
对传统系统，考虑FC对CPU的大量消耗，需要增加更过的CPU来处理业务。
Page 51
FC与IB传输效率对比
类型 FC Exadata IB
链路典型带宽 4Gb-8Gb/s 40Gb/s
MTU 2112 byte 64K byte
主机开销 中 低
处理方式 用户空间到内核空间的数据拷贝，较高CPU开销
RDMA远程直接内存访问，低CPU消耗
Exadata数据库云服务质量管理Quality of Service Management
Recommendation: NA Performance Class has CPU Bottleneck.
Action: Move Server from Server Pool Back Office to Sales.
Sales Pool
Sales ClientsBack Office
Clients
Resource (CPU)
EMEANA
APAC
Response Time Objectives
Most Critical Least Critical
Back Office Pool
Recommendation: EMEA Performance Class has CPU Bottleneck.
Action: Promote EMEA Performance Class from Level 2 to Level 0.Recommendation: All Performance Objects being met.
Action: No action required.
高扩展高可靠OLTP海量数据处理架构优势 资源虚拟化 SLA
通过QoS监控和保护系统资源- Health Monitor 保护系统服务资源
Sales Pool
Sales ClientsBack Office
Clients
Most Critical Least Critical
Back Office Pool
!
Alert: Memory Pressure detected – Server at Risk.
Action: No new sessions accepted.
Memory
Physical
高扩展高可靠OLTP海量数据处理架构优势 资源虚拟化 SLA
压缩的行 混合列
Row 1
Symbol Table
Row 2
Row 3
Database Block
•很好的随机行访问特性•OK 表访问•2x - 5x 压缩
Colum
n 1
Colum
n 2
Colum
n 3
列数据库
•很差的随机行访问特性•非常好的 Table Scan
•5x - 40x 压缩
Compression Unit 1
Colum
n 1
Colum
n 2
Colum
n 3
Compression Unit 2
C1
C2
C3
•很好的随机行访问特性•非常好的 Table Scan
•5x - 40x 压缩
Exadata数据库平台特点：混合列压缩
11gR2
Exadata提供的惊人容量获得10倍的压缩非常常见
Exadata10x compression
Teradata 26501.4x compression
Netezza TwinFin2-4x compression
EMC VMAX3x (Oracle) compression
我们的对手要用多个机架来存储一个Exadata机架就
能存储的数据*
* 均采用了各个数据库最佳的压缩技术
Exadata设计原则4：自动优化存储资源池Exadata 内部数据的分布，实现存储SAME特性
数据的分布在系统变更时自动改变，而且对应用透明– 当新Storage Cell添加时均衡仍然得以保持
– 当硬件出故障时均衡仍然得以保持
– 单块磁盘损坏/单个storage cell损坏都能忍受
– 缺省分配单元AU_SIZE=4M
Node 2
Node 3
Node 1
Storage cell 2Storage cell1
Storage cell 3
57
Exadata特点4：存储资源池数据动态重分布，消除I/O分布热点块，使得集中化平台可不断线性扩展
Storage cell 4
Storage cell2
Storage cell 3
Storage cell1
Add new storage cell
数据后台自动分布，提供最高性能–当新硬件添加时均衡仍然得以保持
–非表一级操作，无需锁定表，在线进行
–当旧硬件移除时均衡仍然得以保持
–当硬件出故障时均衡仍然得以保持
58
高扩展高可靠OLTP海量数据处理SLA架构优势 资源虚拟化
Exadata特点5：Flash闪存解决磁盘随机I/O瓶颈
• 磁盘可存储大量数据
• 但每秒的随机I/O <200- 300 I/Os (8K块)
• Flash闪存技术可存储少量数据（但远大于DRAM）
• 但却能提供每秒几万级的I/O
• 数据库一体机提供总计 5.4 TB 的闪存• 每智能存储服务器配置4块高速闪存卡
• 采用flash cards，而非闪存Disk避免控制器瓶颈
• Smart Flash Cache缓存热数据，但• 不是采用简单的LRU算法,库逻辑感知
• 基于数据库数据使用逻辑，知道那些数据应该缓存,那些不应该缓存
• 允许基于应用表进行指定优化，如提示高优先级驻留于缓存
Oracle is the First Flash Optimized
Database
随机I/Os速度比1000块盘的企业级阵列(200K IOPS)快7倍
59
Exadata特点6：内置高扩展能力在线无需停机的扩展
Exadata特点8：端到端全双工冗余避免数据库、网络、磁盘、Cell和电源的单点故障
ASM镜像用于保护磁盘故障，可支持热插拔，支持三重镜像解决双存储节点失效情况
ASM failure groups 用于保护存储节点故障
双路网络交换
双路电源模块
Exadata Cell Exadata Cell
Hot Hot Hot Hot Hot Hot
Cold Cold Cold Cold Cold Cold
ASM
Disk Group
ASM
Failure Group
ASM
Failure Group
全双工系统架构,完全消除硬件单点故障
InfiniBand 交换网络（双路）
RAC TAF
63
• 当发生磁盘故障或者storage cell故障时自动重分布
- 当磁盘故障后通过重分布保持均衡性和冗余性
- 当storage cell故障后通过重分布保持均衡性/冗余性
cell 2
Cell 3 Cell 4
Cell 1
[ 硬件故障 ]ASM的重分布保证了磁盘能均衡地为工作负载服务.
带来巨大的管理简便性和性能的提升.
大大减少了硬件故障后恢复到保护状态的时间
Exadata具备跨存储节点的保护能力
极限性能和高可用：大多数客户表示Exadata性能和高可用性超过了支持其任务关键应用程序所需的水平。
混合需求：与 Teradata、Netezza等其他数据库软件设备不同，Exadata可在单一软件设备中同时支持数据仓储应用程序和联机事务处理 (OLTP) 应用程序。
最佳商用软件平台：Exadata可以运行打包应用程序，例如 E-Business Suite (EBS)、SAP、PeopleSoft
和 Siebel 应用程序，而无需任何修改。
云计算平台：Oracle 数据库云服务器还可以整合多个数据库，以降低成本、提高可管理性。
成熟产品：目前有超过 1000位客户在生产环境中使用 Oracle Exadata数据库云服务器，并且这一数值可能会在未来 12 到 18 个月内增至三倍。
Forrester对Exadata的评价
Oracle 数据库云服务器推高数据库软件设备的标准
提纲
• 运营商企业数据仓库基础平台面临的挑战
• 传统数据库架构和面临的主要问题
• Exadata数据库云平台的优势和特点
• Exadata相比MPP架构集群的优势
新一代数据仓库平台重点考察能力点
数据压缩能力
高可用性和高扩展能力数据加载和OLAP能力
多租户资源控制和系统管理 类OLTP能力
Oracle Exadata压缩比实测达到7-14倍TD按经验大约2-3倍Netezza按经验大约3-4倍DB2按经验大约3-4倍
Oracle Exadata全双工架构，高可用特点；
Oracle Exadata对数据加载达到26分钟加载133亿记录，原始压缩文件达到0.9TB(TW_GMCC_USR_VEST_DAY表)
Oracle Exadata完成所有测试要求场景Netezza和DB2都在清单表关联中放弃测试，对于非分区键的关联查询无法满足
Oracle Exadata具备完善的CPU、IO
等资源控制能力，适合进行多租户数据库管理Oracle Exadata具备完善的系统统一管理能力，能够从硬件、软件、网络、存储等全方位进行系统统一管理
Oracle Exadata的OLTP能力表现极佳，在有大作业负载情况下，也能达到每个进行1-2
万TPS。Netezza放弃OLTP作业测试MPP即Shared Nothing架构数据库，OLTP能力普遍较差
MPP数据库的数据Hash分布只适合于Hash键值关联、带来数据IO分布不完全均匀等问题
Partition 0 Partition 1 Partition 2
customer
sales
Smith F
Smith 1
Smith 2
Smith 3
Woe M
Woe 1
Woe 2
Bill M
Bill 1
Bill 2
Mary F
Mary 1
Mary 2
Zool F
Zool 2
Zool 1
Zool 3
CREATE TABLE customer (
cust_id VARCHAR(80)
,gender CHAR(5))
PARTITIONING KEY(cust_id);
CREATE TABLE sales (
cust_id VARCHAR(80)
,qty INTEGER)
PARTITIONING KEY(cust_id);
Customer
cust_id Gender
Smith F
Bill M
Woe M
Zool M
Mary F
Sales
cust_id Qty
Smith 1
Smith 2
Smith 3
Zool 1
Zool 2
… …
Hash(cust_id)
0210210210
4096…87654321
0210210210
4096…87654321
MPP架构的噩梦场景：不在分区键上的JOIN
SELECT COUNT(USR_MOB_NBR),SUM(CNT),SUM(SUM_CALL_DUR),SUM(SUM_TOLL_DUR)
FROM (
SELECT
A.USR_MOB_NBR,
B.B_NBR,
COUNT(1) AS CNT,
SUM(A.CALL_DUR) AS SUM_CALL_DUR,
SUM(A.TOLL_DUR) AS SUM_TOLL_DUR
FROM ODS.TO_CDR_201103 A
INNER JOIN ODS.TO_CDR_201103 B ON A.B_NBR=B.USR_MOB_NBR AND B.Debet_Dt=20110315
WHERE A.Debet_Dt=20110315
GROUP BY A.USR_MOB_NBR, B.B_NBR
HAVING COUNT(*)>15
)
结论：MPP架构针对大数据量的非分区键关联效果很差，本测试案例关联有一个表是分区键、一个表是非分区键，数据量大约170亿记录，数据需要重分布，执行效果非常不理想，说明MPP架构对查询要求非常严格，灵活查询效果不佳
CREATE TABLE "ODS"."TO_CDR_201103" (
"USR_MOB_NBR" VARCHAR(20) NOT NULL ,
"A_SWITCH_CD" CHAR(2) NOT NULL ,
"CMCC_BRANCH_CD" CHAR(4) NOT NULL ,
…….
"FILE_ID" VARCHAR(12) NOT NULL WITH DEFAULT '' )
COMPRESS YES
DISTRIBUTE BY HASH(“USR_MOB_NBR”)
Social Insurance Number Name Location
123-456-789 Joe Boston Toronto
Partition Key value Hashed to: "8"
Vector
Position0 1 2 3 4 5 6 7 8 9 10 11 12 ...
Node 1 2 3 1 2 3 1 2 3 1 2 3 1 ...
DB2 DB2 DB2
分区映射表
•确定记录所在分区•可以通过REDISTRIBUTE工具重新分布数据的位置
MPP Hash分区在扩容时复杂的数据重分布过程
DB2
Node 1 2 3 4 1 2 3 4 1 2 3 4 1 ...
整体存储架构区别- Exadata vs. MPP
AM
P 1
AM
P 2
AM
P 3
AM
P 4
1 2 3 4
Wo
rke
r 1
Wo
rke
r 2
Wo
rke
r 3
Wo
rker
4
Exadata Exadata Exadata
1
2
3
4
MPP架构的高可用性困难
分组相互接管
负荷平均分配
冷备节点
损失50% 性能
配置极其复杂，几乎不具备可实施性
冷节点平时处于浪费状态
问题
共有问题，接管时间长！
Shared Nothing架构问题
0 1 9….
SMP001-9
10 11 19….
SMP001-10
20 21 29….
SMP001-11
30 31 39….
SMP001-12
DAC-A DAC-B DAC-A DAC-B DAC-A DAC-B
1、大量磁盘带来的DA卡吞吐瓶颈
2、扩展存储和DA数量，低端存储单点故障、LUN数目过多问题
3、跨存储的保护带来了存储冗余和加载、处理速度的降低
4、数据Hash分区带来的加载、数据重分布、数据依赖度高，仅适合于Hash Key的
关联查询
5、扩展服务器带来的配置不均衡
MPP架构的一体机均存储架构：存在可靠性风险
•Server:
•POWER7 740 4U server
•Dual socket 16 CPU cores @ 3.55 GHz
• NO optional # cores
•Storage:
•4 of DS3500 controllers
•96 disks per data module
•8 Gbps FC
•Disks options:
• 300GB 10k RPM
•Software:
•AIX 6.1 TL06
•DB2 9.7 FP2
•GPFS 3.3
•DB2 logical design / module
•8 LDPs, each with:
• 2 3.55 GHz p7 core
• 12 disks
• 16 GB memory
•20.8 TB disk capacity / module
•HA Group: 4 active servers with Standby
IBM Power 740
16 CPUs
128 GB memory
IBM Power 740
16 CPUs
128 GB memory
IBM Power 740
16 CPUs
128 GB memory
IBM Power 740
16 CPUs
128 GB memory
Admin
Module
Data
Module
Data
Module
Data
Module
DS3500
24 disks
DS3500
24 disks
Redundant 10 Gbit Ethernet switches
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
DS3500
24 disks
Redundant SAN switches
IBM Power 740
16 CPUs
128 GB memory
Failover
Module
DS3500是一个单点故障点!
平时处于浪费的资源
MPP架构对存储的容错开销
A Fallback table is fully available in the event of an unavailable AMP.
A Fallback row is a copy of a “Primary row” which is stored on a different AMP.
Benefits of Fallback
• Permits access to table data during AMP off-line period.
• Adds a level of data protection beyond disk array RAID.
• Automatic restore of data changed during AMP off-line.
• Critical for high availability applications.
Cost of Fallback
• Twice the disk space for table storage.
• Twice the I/O for Inserts, Updates and Deletes.
Loss of any two AMPs in
a cluster causes RDBMS
to halt!
Note:
Primary
rows
Fallback
rows
AMP
2 611
3 5 128
17
3 85 2 1 11 6 127
AMP AMP AMP
Fallback Double Hash Map
Hash Bucket Number Remaining bits
Row Hash (32 bits)
Notes:
14 AMP System with 2 AMP
clusters; hash maps with
1,048,576 buckets.
Assume row hash of
0023 1AB2
Primary AMP – 05
Fallback AMP – 12
PRIMARY HASH MAP – 14 AMP System
13 12 13 12 13 11 12 10 13 10 11 12 11 12 13 09
13 07 08 10 08 08 11 11 09 09 10 12 09 09 10 13
10 10 13 05 11 11 12 12 11 11 06 12 13 04 12 12
07 06 13 03 06 08 13 02 13 13 01 00 07 08 05 07
04 04 05 07 09 06 09 07 03 02 03 08 01 00 02 06
01 00 05 04 08 10 10 05 08 08 06 09 07 06 05 11
0 1 2 3 4 5 6 7 8 9 A B C D E F
000
001
002
003
004
005
FALLBACK HASH MAP – 14 AMP System
06 05 06 05 06 04 05 03 06 03 04 05 04 05 06 02
06 00 01 03 01 01 04 04 02 02 03 05 02 02 03 06
03 03 06 12 04 04 05 05 04 04 13 05 06 11 05 05
00 13 06 10 13 01 06 09 06 06 08 07 00 01 12 00
11 11 12 00 02 13 02 00 10 09 10 01 08 07 09 13
08 07 12 11 01 03 03 12 01 01 13 02 00 13 12 04
0 1 2 3 4 5 6 7 8 9 A B C D E F
000
001
002
003
004
005
Exadata与Shared Nothing架构对比
Exadata Share Nothing架构
架构特点 混合架构 单纯的Shared Nothing，无法支持类OLTP型应用
压缩能力 10-20倍 2-4倍左右
热数据识别 SGA、Flash、外道盘、内道盘、ILM控制热点数据
没有对热数据进行重复利用，没有ILM，完全是拼磁盘数量和IO性能
数据依赖 没有PI、Hash等严格数据依赖
•依靠PI的选择来均匀分布数据•数据倾斜导致数据库空间无法使用•应用需要适应PI的Hash分布方式，被查询数据分布在不同的分区或AMP上，且相互需要join时引发数据重分布，严重影响查询速度
在线扩容数据重分布
扩容时，Exadata只是对数据条带级做在线迁移，速度快、不中断业务
•Shared Nothing数据库都对数据的PI做Hash重分布，会对每行数据做重新Hash的操作，导致CPU和IO都非常繁忙，
而且是基于行的操作；正在被重分布的表无法访问；已经重分布和尚未重分布的表即使在相同的分布键做joinn也等于不在其上做，性能极低
数据条带化和镜像保护
Exadata是对数据跨盘、跨存储单元的条带化和镜像保护
•Shared Nothing都是在一个盘阵内部实现镜像和条带化，如果盘阵、DA卡等故障，都会导致系统不可用，如果要实现跨盘阵保护，需要更大的数据镜像空间（4倍），并且对数据加载和操作带来性能影响
78