Oracle Exadata特性简介及应用指南

2012年 8月
一Exadata 概述 (4)
1Exadata简介 (4)
2Exadata的配置及性能参数 (4)
二Exadata特性 (5)
1Smart Scan（智能扫描） (5)
2Storage Index（存储索引） (14)
3Flash Cache（智能闪存） (24)
4Compression（压缩） & EHCC（Exadata Hybrid Columnar Compression）28 5IORM（IO资源管理） (34)
三Exadata监控 (37)
1Exadata特性监控常用指标 (37)
2如何查看指标 (38)
四如何应用Exadata (38)
1Exadata参数调整 (38)
2在Exadata上开发注意事项 (38)
4Exadata总体总结 (42)
1前言
1.1本文背景
前期东软-甲骨文公司组织了一次针对社保系统的Exadata联合应用测试，本文内容是本次Exadata测试的经验总结，其中包含了与Oracle技术人员交流经验应用、Oracle相关技术文档应用及个人测试经验总结。

1.2本文简介
本文是关于ORACLE Exadata的一些特性介绍和应用Exadata的一些指南；本文不会涉及太多传统ORACLE DataBase已经具有的而非Exadata专有的一些特性介绍。

通过本文，读者可以了解ORACLE推出 Exadata的目的和初衷，简单了解Exadata 架构体系，了解Exdata的一些设计思路，了解其特性及其原理；了解Exadata的适合应用场景，不适合应用场景，以及在Exadata下开发的一些注意事项（尤其是做Exadata项目主要设计、开发人员一定要了解Exadata，不要把它完全当作传统ORACLE 数据库）。

1.3读者范围
已经熟悉ORACLE数据库
有Exadata相关项目
想了解一些Exadata 的特性原理和其实现细节
一Exadata 概述
1Exadata简介
1.1ORACLE Exadata Database Machine
1.ORACLE Exadata数据库云服务器，把服务器、存储、数据库合理的整合在一起。

2.为满足大型数据库存在的性能瓶颈而推出的，最初为DW系统应用，后来也同
时支持 OLTP系统，成为一个支持混合应用的系统。

3.包含Database Server、Exadata Storage Server
2Exadata的配置及性能参数
2.1性能优势
1.是Share Nothing（Storage Server）与Share Disk（DataBase Server）结
合的系统，有优点也有缺点。

2.是软硬件结合的系统，也是一个Balance系统，通过多CPU、大内存、多磁盘、
Flash card、Infiniband等合理搭配，再结合强大的软件系统，减少单一性能瓶
颈；其主要是软件提升系统性能，而不是主要靠硬件。

其性能好最主要原因是通过
Offload（存储节点卸载）减少存储层与数据库层之间的传输数据量。

3.对于要求吞吐量批处理业务操作来说，通过Offload（如cell Smart file
creation、Smart Scan 、Storage Index等技术）方式减少无用数据的交互，通
过Compression使数据存储空间更小，通过Direct Path Read数据直接放到PGA
中，而不占用SGA。

4.对于要求响应速度的单笔并发查询业务来说，通过Flash Cache提供更大的
IOPS。

Flash Cache同时也为大查询提供更高的带宽。

5.通过Infiniband使数据传输带宽更高，也降低RAC间争用。

6.通过ASM打散数据，避免热点IO。

7.再通过Resource Manager协调管理各个业务系统可使用的资源。

8.再加上Database 11gR2的分区、并行、并发、Result Cache等增加系统处理
性能和能力。

二Exadata特性
1Smart Scan（智能扫描）
1.1Smart Scan 带来什么
1.感性认识
1.2Smart Scan 介绍
1.Smart Scan 是什么
1)其设计思路区别以往系统，将处理能力从DB层下移到Storage层
2)Smart Scan在Storage层由软件实现
2.Smart Scan 作用
1)过滤无用数据，减少提交到数据库服务器的数据量
2)即减少对网络及DB服务器压力减小，利用了存储的CPU资源
3.Smart Scan 原理
1)字段过滤：select column
2)谓词过滤：where column\ join column
4.SQL启用Smart Scan必要条件（非充分条件）
1)必须是全扫描
(1)Full Table Scan
(2)Index Fast Full Scan
(3)Bitmap Scan
2)必须直接路径读取（Direct Path Read到PGA，普通方式读取到SGA不可以）
3)对象必须存储在Exadata Storage上（其他普通存储不可以）
5.ORACLE提供参数禁用或启用Smart Scan（默认启用）
1.3Smart Scan 特点
1.自动和透明，随时可以使用，不需要特殊处理
1)SQL第一次执行就可以使用
2)不像Storage Index那样需要ORACLE先建立才能使用
3)不像Flash Cache那样需要ORACLE先缓存
4)Where子句也不是必须的
2.使用特点
1)只适用于Query，不适用于DML
2)按普通索引查询则无法使用Smart Scan
3)没有类似Buffer Cache共享的目的，非常适合每次查询都是不重复的数据。

4)只返回符合条件的row和column，多余数据不返回
5)数据按照集合（非ORACLE块）返回到PGA中，不放入SGA
6)如果所有字段都查，并且没有where子句，那么Smart Scan就无作用了
1.4Smart Scan 应用
1.5Smart Scan 总结
1.Smart Scan 性能
1)性能很快，一般在秒级/10、秒级、分钟级
2)比普通全表扫描快很多
3)没有中等性能的传统Index快，没有中等性能的Storage Index快，和不好的
Index/Storage Index差不多
4)结合Storage Index使用，性能更好
2.根据其机制和测试结果，个人感觉：
1)为DW而设计，更适用于类似DW系统等大数据量应用。

2)不太适用于要求响应时间和并发量的OLTP单笔业务系统中。

3.Smart Scan 适用场景
1)适用于后台手工大数据查询
(1)如现场后台手工分析、统计一些数据
2)报表统计
(1)各类大报表的统计
3)前台各类大查询
(1)大数据量的查询
4)前台大业务模块的待处理数据的查询
(1)批量核定业务的未核定单位（个人）数据查询
(2)批量征集业务的待征集数据查询
(3)批量实收业务的到帐未实收数据查询
5)Where条件选择性非常不好的各种查询
(1)（日期、类别、状态、人数、金额。

）
6)非常不常用、不重要的OLTP单笔业务
4.Smart Scan 不适用场景
1)后台批量业务的循环大SQL单次查询
(1)不能在for loop中的SQL使用Smart Scan
2)前台并发大的小业务
(1)对于前台并发操作多，但很小的业务，如停续保、基本信息修改等5.Smart Scan 给系统设计开发带来的好处
1)对OLTP小业务无影响（不必考虑此特性，按原先方式设计开发）
2)减少大SQL过度优化
3)对于复杂大SQL直接用Smart Scan，不用非要走各种索引
4)减少选择性非常不好的传统索引的建立
2Storage Index（存储索引）
2.1Storage Index 带来什么
1.感性认识
2.2Storage Index 介绍
1.Storage Index 是什么
1)不同于传统Index，非find需要的数据，而是filter不要的数据
2)在Storage层实现，非Server层
3)Storage Index保存在cell节点内存中
4)Storage Index为每个存储单元（1m）数据块建立最大值和最小值
2.Storage Index 作用
1)消除不必要的磁盘I/O
3.Storage Index 原理
1)比较where条件与cell内存中的Storage Index，不符合匹配条件的存储区间
直接被跳过，由于被跳过部分数据不产生IO，因此大大减少磁盘I/O
2)类似Partition，不过是更小范围的分区
4.Storage Index 如何管理
1)Storage Index由ORACLE内部来自动维护（包括建立、更新、清除等）
(1)第一次智能扫描
(2)Ctas
(3)Insert Append
(4)Update
2)不需要也不能人工干预（内部机制不是特别清楚）
3)经常使用的列会有建立Storage Index
5.SQL启用Storage Index 启用必要条件（非充分条件）
1)必须是Smart Scan方式
2)必须有where子句
3)并行查询
6.ORACLE提供参数禁用或启用Storage Index（默认启用）
2.3Storage Index 特点
1.特点
1)在内存中，速度快，也意味着重启即丢失
2)不同于传统Index，非find数据，而是filter不要的数据
3)自动和透明，返回的数据是完全一致的和事务级的
4)与普通索引机制不一样，不针对表建立，针对数据块建立, 每1m数据块建立最
大最小值，空间小
5)最多8列
6)根据其过滤方式，表字段数据越有序，则存储索引效果越好
2.原则
1)只适合Query，不适合DML
2)按普通索引查询则无法使用Storage Index
3)一般第二次查询可用上Storage Index（首次查询用不上，因为Storage Index
还没有建立），查询后会重建Storage Index
4)数据修改，ORACLE会维护存储索引（机制不清），有时可能会失效（不会导致错
误）
5)字段值（非字段类型）为数字的可以使用存储索引，字段值存在字符型不使用2.4Storage Index 应用
2.5Storage Index 总结
1.Storage Index 性能
1)Storage Index对大SQL性能提升很大（使用得当，至少提高10倍以上）
2)Storage Index返回速度根据基表数据量、返回数据量、所查询字段分布，一般
在1/100秒级-分钟级，达不到0.000n秒，一般也不会达到小时级
2.根据其机制和测试结果，个人感觉：
1)主要为DW而设计，更适用于类似DW系统等大数据量应用。

2)不太适用于要求响应时间、大并发量的OLTP单笔业务系统中（还需项目验证）。

3)好的Storage Index比不好的普通索引性能好，Storage Index比Smart Scan性
能要好
(1)在大表小数据量查询时（比如100条以下），Storage Index没有普通索引快
（即选择性好的索引，比Storage Index好）
(2)在大表大数据量查询时（比如10万条以上），Storage Index比普通索引快
很多（即选择性不好的索引，没有Storage Index好）
3.Storage Index 适用场景
1)适用于后台手工大数据查询
2)报表统计
3)前台各类大查询
4)前台大业务模块的待处理数据的查询
(1)同Smart Scan场景
5)Where条件选择性非常不好（批次、年月、日期、状态、空值等。

）的各种查
询
(1)这类查询，不用建立对应的索引，直接采用Storage Index
6)非常不常用、不重要的OLTP单笔业务
4.Storage Index 不适用场景
1)后台批量业务的大SQL单次查询（不能在for loop中的SQL使用Smart Scan。

）
2)前台并发大的小业务（有待正式系统验证）
5.Storage Index 给系统设计开发带来的影响
1)对OLTP小业务无影响（不必考虑此特性，按原先方式设计开发）
2)减少大SQL过度优化
3)对于各类查询，可以结合实际，应用Storage Index
(1)尽量保证字段值为数值型、日期型
(2)不要对字段做函数处理，如trunc，to_char…
(3)尽量按顺序存储数据（包括数据转换）
(4)保证使用Storage Index的列值有规律，比如顺序增长，不要无规律或者
由多个序列生成（这样每1M的最大最小值都接近一样，Storage Index失去
意义）
(5)减少普通索引的建立，一些不常用字段、非选择性字段的索引可以不建立
(6)对于日期字段不要建立普通索引，直接利用存储索引
(7)减少过度优化，一些大SQL不必非要调整为走索引（当然不是不需要优化）3Flash Cache（智能闪存）
3.1Flash Cache 带来什么
1.感性认识
3.2Flash Cache 介绍
1.Flash Cache 是什么
1)硬件，Flash card
2)Storage Server Disk的缓存（类似内存的DB Buffer Cache）
2.Flash Cache 作用
1)提升Exadata在OLTP业务下的性能
2)对DW业务性能也有很大好处
3.Flash Cache 原理
1)缓存热数据，通过增加IOPs解决随机的I/O 瓶颈
(1)读：先看Cache，没有再看Disk（也可能同时读），之后再把Disk的数据
放入Cache（小数据才放，大数据不放）
(2)写：先写Disk，后续再同步Cache
4.Flash Cache 管理
1)当作缓存用时，类似DB Buffer Cache，算法由ORACLE控制
2)对象（表、索引）缓存在Flash Cache中的方式有三种（Keep ，Default，Recycle）
3)ORACLE提供方法清除Flash Cache
5.Flash Cache 使用必要条件
1)对象已缓存到Flash Cache 中，ORACLE自动读取Flash Cache
2)其中缓存方式为Keep的对象更容易使用Flash Cache
3.3Flash Cache 特点
1.在DB Server MEM 与Storage Server Disk之间一层缓存，主要目的是为OLTP
系统加快读取，对DW/DSS系统也有很大好处
2.性能、容量介于内存和存储之间，可提供更快的响应时间，更高的随机I/O，
更大的带宽
3.可以指定表及索引的Cache方式
4.也可作为存储使用，可把表直接存储到上面
5.智能缓存，ORACLE自动管理，有类似LRU的算法
6.更适合读，大量读小量并发读都有好处，不适合写
3.4Flash Cache 总结
1.Flash Cache 性能
1)Flash Cache对系统整体性能有一定的提升
2)单笔带来的性能提升没有Storage Index和Smart Scan那样令人惊讶，单笔非
并发，提升不到1倍
2.Flash Cache 适用场景
1)适用于各类OLTP和DW业务，都可以带来好处
3.Flash Cache 不适用场景
1)只写不读的系统（同步了不用，浪费资源）
2)频繁修改的系统（对于数据频繁同步到Flash Cache，会有一定的性能影响）4.Flash Cache 给系统设计开发带来的影响
1)当作Cache使用
(1)对开发透明，具体编码不必考虑Flash Cache是否存在
(2)可把常用基础表以Keep方式缓存到Flash Cache中；
(3)非常用表、大表由ORACLE自动管理default；
(4)频繁修改的表不要keep（具体效果还需要在项目中真正验证）
2)当作Disk使用
(1)常用表放入Flash Cache（需要实际项目验证）
(2)Redo Log放入Flash Cache（实际可能不适用，需要实际项目验证）
4Compression（压缩） & EHCC（Exadata Hybrid Columnar Compression）
4.1EHCC 带来什么
1.感性认识
4.2EHCC 介绍
1.EHCC 是什么
1)多块（32k/64k）数据组成一个压缩单元（Compression Unit）
2)每个压缩单元内按列来组织
3)非行压缩、非列压缩，介于行存贮和列存贮之间
2.EHCC 作用
1)为减少非活动数据占用空间，为能提供更大的压缩比、压缩效率
2)可以避免行压缩的压缩率不好，列式压缩的访问性能不好的缺点
3.EHCC 原理
1)数据在压缩单元内按列来组织和压缩，非行压缩、非列压缩，介于行存贮和列
存贮之间
2)四种类型（四种算法）
4.3EHCC 特点
1.EHCC 特点
1)提供了极大的压缩比，非常有效的减少存储空间
2)数据的解压缩被卸载到Exadata节点有效的减少了数据,库服务器节点的CPU开
销
3)混合列压缩的索引机制和普通表的机制不一样，混合列压缩QUERY、ARCHIVE不
太适用于OLTP系统，小数据走索引的查询没有优势，OLTP系统可用普通压缩OLTP
4)block是以压缩单元进行存储的；一个CU由多个block组成；而且数据再block
中是以列进行的存储；这能够提高查询速度，但是其缺点如果查询一个行的所有列则会访问所有的block；所以要注意系统的单行读情况
2.压缩解压时机
1)所有的压缩是在DB层完成的；
2)但是当访问数据时：
(1)如果是进行的Smart Scan，那么在进扫描时会在Storage cell中解压缩，
并且解压缩的是需要访问的列，返回的数据全部是需要的数据，而不再需要过滤；(如果Storage cell较忙，会在DB层完成)
(2)如果进行的是非Smart Scan，那么数据的解压缩就是在DB层完成的；
3.EHCC压缩发生DML后处理方式
4.4EHCC 应用
4.5EHCC 总结
1.根据其机制和测试结果，个人感觉，
1)有效降低存储空间
2)适用与DW系统，尤其适用于系统历史查询数据、历史归档数据的管理
3)不适用于频繁处理的OLTP系统，对DML操作性能不好（DML操作后会转为OLTP
方式压缩）
4)对Query，按索引单行访问不好，批量访问性能也许会更好（降低IO）
2.EHCC 适用场景
1)尤其适用于系统历史数据不访问，不处理（或极少处理）的压缩
2)列重复值比较多，有规律的表适合压缩（压缩率非常大）
3.EHCC 不适用场景
1)历史数据有DML操作的不适合压缩（DML操作后要转为OLTP压缩，多次处理以
后，反而存储和性能都不好）
2)历史数据经常按索引做单条数据访问的不适合压缩（因为其多个块为一个单元，
查询一条也要访问多块数据，性能不好）
3)很多列为空值的不适合（原先就不占空间，所以压缩效果不好）
4)列很多，并且值都很唯一的表压缩不适合（这样压缩率低）
4.EHCC 给系统设计开发带来的影响
1)对海量大表不需要修改的历史数据需要考虑结合分区利用好压缩，大大降低存
储空间的同时对性能影响不大
5IORM（IO资源管理）
1.IORM属于Resource Manager的一部分；
2.Resource Manage包含 DBRM、IORM；
3.普通ORACLE数据库也有DBRM功能；
5.1Resource Manager介绍
1.ORACLE资源管理器（ORACLE Database Resource Manager，简称DBRM）
1)管理数据库资源，为不同的会话分配不同的数据库资源。

2)DBRM管理的资源主要包括CPU时间。

3)实现服务器资源（如CPU和I/O）在不同数据库/资源组/会话间的分配。

4)控制系统资源（CPU、IO、parallel…）使用的优先级
5)可按需分配平衡多负载下的资源占用
2.DBRM在DB Server层控制CPU、parallel等资源
3.IORM是在cell层控制IO资源
5.2Resource Manager特点
1.资源管理器部件组成：
1)资源用户组（Resource consumer group ）: 根据数据库资源处理需求，将用
户会话的资源请求将它们分为一组。

DBRM按组管理会话的资源分配，而不是按
单个的会话。

2)资源规划（Resource plan ）: 指定哪些资源分配给资源用户的命令；
3)资源分配方法（Resource allocation method）: 数据库资源管理器分配特殊
资源时采用的方法，由资源用户组和资源规划来使用。

4)资源规划命令(Resource plan directives): 管理员使用这些命令将资源用户
组与特殊规划连接起来，并在资源用户组之间分配资源。

资源计划指令指定了资源计划和组之间的映射关系。

5)一个资源规划对应多个资源用户组，而一个资源用户组对应多个指令。

2.Resource Manager控制方式
1)可按照用户、服务、终端、模块等各个类别控制
2)可以扩展自定义配置，可在应用层统一配置（类似ORACLE VPD配置），实现不
同业务的不同资源级别
3.使用方式，两种方式
1)单级别的资源管理策略
(1)当G_A只使用20%，剩余40%（60%-20%）按照比例3:1(30%:10%)分配给G_B
与OTHERS
(2)当G_B没有使用，同上。

2)多级别的资源管理策略
(1)当G_A只使用20%，剩余50%（70%-20%）流向level2，50%分配给G_B，G_B
多得到：50%（70%-20%）*50%=25%，剩余给level3：50%-25%=25%，level3
中G_C多得到其中的50%：25%*50%=12.5%，剩余的给OTHERS，其多得到
25%-12.5%=12.5%
5.3Resource Manager总结
1.资源不足时使用，保证主要业务系统的资源（牺牲不重要业务）
1)比如社保系统与劳动系统之间资源分配
2)比如社保内部并发小业务与批量大业务之间资源分配
3)比如重点业务与非重点业务之间的资源分配
2.当资源充足时，不要使用资源管理
三Exadata监控
1Exadata特性监控常用指标
（如下为比较重要的指标。

个人理解，翻译的不一定准确）
1.1指标
1.2事件
2如何查看指标
2.1在AWR报告中查看
2.2Session级查看v$sesstat 、 v$statname
四如何应用Exadata
1Exadata参数调整
2在Exadata上开发注意事项
2.1根据业务场景尽可能应用Exadata的Offload等特性，应用其超强的I/O处理能力。

1.对批量操作处理场景下，不需要针对Exadata进行过度的优化，尽量应用Smart
Scan、Storage Index。

这样可以减少很多选择性不好的普通索引的建立，同时也为DML操作减轻了负担。

2.对于大SQL语句用不上合适的索引（个人编号、单位编号、流水号。

），就不
要再特别增加不必要的索引（如标志、性别等明显选择性很差的字段做索引），直接应用Offload特性，比如在上面介绍的Smart Scan、Storage Index中的SQL语句。

3.对于建立/扩展表空间，数据加载卸载，大表重建，索引重建等手工操作采用
并行可充分利用其IO优势、Offload特性
2.2在适用的场景下，结合ORACLE分区技术合理使用EHCC压缩或OLTP压缩技术。

1.可不影响系统性能的前提下，可有效的减少了存储空间。

2.比如缴费明细按时间分区，当前数据不压缩，历史分区采用OLTP压缩，历史
不欠费分区采用For Query压缩
3.对于医疗、养老大表，按时间分区，当前数据不压缩，历史分区采用For Query
压缩
4.对于各类日志信息，按时间分区，当前数据不压缩，历史分区采用For Query
压缩
5.对于不查询只是备份的数据，采用For Archive方式压缩，可能会极大的减少
存储空间
2.3在大规模并发情况下，通过Flash Cache可提供较高的随机读性能，可根据业务需
要，将常用的不变化表、索引keep到Flash Cache。

1.比如单位信息、大的参数表等
2.把Redo log放在上面（未验证、需要验证，log串行写可能会有问题）
2.4对于大数据处理，尽量采取并行的方式来处理（保证资源可用的前提下）
2.5在OLTP小并发大批量业务处理方面
1.可由原先的for loop循环方式处理的业务改为Batch处理模式（基于SQL），
更好的应用Exadata特性。

对于For loop方式，Exadata没有优势，可以把比如批量征集、批量报盘业务可有For loop方式改为Batch处理模式，这样充分利用其IO行等优势
2.同时结合压缩、分区、并行，SQL语句优化等方式，提升系统处理速度。

3.对于无法改为批量处理方式的业务，可采用多线程方式处理，充分利用其资源
优势，提高系统吞吐量，提升业务整体处理时间。

对于灵活就业批量核定、批量征集等如果不能改为一次处理，可以采用多线程方式，充分利用其多个CPU。

2.6对于OLTP大并发小业务系统处理方面
1.对业务逻辑、SQL、Index、序列进行优化处理，保证每个业务没有明显瓶颈
2.采取表分区、索引分区（索引HASH分区、反转索引）等减少系统热块争用2.7对于OLAP系统处理方面
1.可充分利用Exadata的优势，Smart Scan/Storage Index/分区/压缩/并行
/Flash Cache/Infiniband。

2.不要建立很多不必要的索引
2.8对于多个OLTP/OLAP混合系统同时运行在Exadata上
1.可应用Resource Manager（DBRM/IORM）进行协调管理各个业务系统/模块可使
用的资源，在不同时刻，根据需要，牺牲非重点业务，保证重点核心业务在业务运行高峰期也可获得较多的资源。

2.对于资源管理，可先采用其简单方式，分配系统资源。

3.比如系统不能承受多个混合系统的同时高负载处理，那么白天可以把大部分资
源分配给前台OLTP业务，一小部分资源给后台批处理业务；晚上相反，把大部分资源分给批处理业务，这样，达到以较少的资源尽量支撑较大的业务量。

4.如果各个系统运行的都非常好，那么不要使用资源管理
2.9结合系统应用合理使用分区、压缩、并行、并发，更好的利用Exadata。

3应用总结
3.1Exadata本质还是ORACLE数据库，应用开发与普通ORACLE数据库开发大多数场景
差别还是不大，通常以往的ORACLE优化原则也适用于Exadata，比如索引优化、SQL语句优化、序列优化、逻辑优化、并行Query/DML等；
3.2但是Exadata和以往的ORACLE也有些不同，尤其是Storage Server、Offload的
设计，要用全新的视角去对待它，其IO极快，其CPU一般，总体来说，就是没必要建很多个选择性不好的索引了；也不要在它上面跑大量For loop业务，更不要在它上面跑大量的只insert没有Query的小业务。

3.3如果系统没有IO/CPU/网络上的瓶颈，系统设计也非常好，业务量也没有超过系统
极限，那么Exadata就无法体现其优势了，对于一个很小的系统用一个Exadata有些浪费。

3.4关于Exadata要不要传统索引的问题，根据原理分析及测试经验感觉对于典型OLTP
小查询系统还是需要的；对于只是简单类大查询的系统，可能不要索引更好些。

3.5最后最重要的一点，Exadata再强，应用逻辑不好，也体现不出其IO的能力和整
体性能的优越性。

4Exadata总体总结
4.1总体Exadata很不错，尤其IO能力很强，更适合Query，适合读多写少的系统。

4.2基于DW的特性更多，基于OLTP特性较少，适于IO密集型系统。

4.3对于OLTP系统，如果只是写密集型的大量小Insert类业务，Exadata几乎没有好
处
4.4对于OLTP系统，如果只是小Query类业务，Exadata有一些好处。

4.5目前更适用于DW系统大数据量应用，不过由于其架构设计不是纯粹的专为DW或
OLTP而设计，有二者缺点，也有二者优点，定位应该是混合系统（目前感觉在OLTP
方面的特性稍少些，后续应该会在OLTP方面增加更多的支持）。