侯松 - Oracle 12c In-Memory Option应用解析

秦叶农

2018/05/13 发布于 技术 分类

IMO是在Oracle数据库的SGA区中开辟一块列式缓存,将Oracle中的行式数据转换成列式存储格式,然后提供给前端应用用来做查询分析。适合OLAP系统。在2015年中国数据库技术大会上来自平安科技的侯松为我们讲解了Oracle 12c In-Memory Option应用解析。

文字内容
1. Oracle 12c In-Memory Option 应用解析
2. 关于我 侯松  新浪微博:@麻袋爸爸  个人网站: http://www.housong.net  数据库架构师,ACOUG用户组核心成员,9i OCP, 《高并发Oracle数据库系统的架构与设计》作者。  拥有10余年数据库开发、管理和运维经验。擅长项 目管理及金融行业数据库应用架构设计。现任职于 平安科技。  乐于分享与公益,曾担当甲骨文全 球大会特别大使,WDP计划大学校 园行志愿者。
3. 闲话故事 Mr. 跨界 Mr. 转型 1 speed 快 就一个 字 2 speed 快挖 + 快 跟 我是威慑性武器
4. 闲话故事
5. 目录 IMO概述 查询优化 列式存储 并发处理
6. 概述:IMDB  TimesTen可独立运行或者与 Oracle数据库配合使用。当与 Oracle数据库配合使用时,将 Oracle库中行式存储的表加载 到TimesTen中,提供给前端 应用访问。适合OLTP系统。  IMO是在Oracle数据库的SGA 区中开辟一块列式缓存,将 Oracle中的行式数据转换成列 式存储格式,然后提供给前端 应用用来做查询分析。适合 OLAP系统。 OLTP OLAP 高并发短事务 IMDB 常规事务 SGA
7. 概述:In-Memory Option IMO列式存储原理  依赖于行式存储的透明化的独立列式存储方式,可以与行式存储一起使用。  在存储上,IMO不需要额外的磁盘存储空间。  后台自动维护保证实时DML操作的数据读一致性。  IMO特性无需业务应用变更,也无需数据库架构变更(安全、备份、容灾、RAC等)。 在线业务 分析业务
8. 概述:IM内存结构 双重数据格式共同作用
9. 概述:IMO标志特性 IMO的标志性特性: 查询优化 IMO列式存储索引优化查询(In-Memory Storage Index) IMO优化的联立与聚合查询(Bloom Filter) SIMD矢量处理 列式存储 多级别二进制列式压缩(支持自选列列式存储) 行式存储与列式存储的透明化组合读写,并实时自动化后台同步 IMO基于RAC架构的分布式应用
10. 目录 IMDB概述 查询优化 列式存储 并发处理
11. 神话:40万倍性能提升? SQL语句: SQL> select min(test_id), max(test_id), 2 min(org_id), max(org_id) 3 from alex.alex_test; 全表扫描执行计划: IM扫描执行计划:
12. 神话:40万倍性能提升? SQL语句: SQL> select min(test_id), max(test_id), 2 min(org_id), max(org_id) 3 from alex.alex_test; SQL语句统计信息: 行式存储 列式存储 提升倍数 COST 1655009 63273 26 CPU_TIME 68678559 104984 654 ELAPSED_TIME 68868544 104292 660 DISK_READS 0 0 0 BUFFER_GETS 6102958 15 406864 会话级的统计信息: session logical reads session logical reads – IM IM scan CUs columns accessed IM scan rows IM scan rows valid 行式存储 6102958 0 0 0 0 列式存储 6103121 6103106 746 206609165 206609165  40万倍性能提升不成立  列式存储的IM逻辑读独立统计  列式存储的逻辑读包括IMCU的扫描和 IM行扫描  性能提升倍数用执行时间来进行比较更 为合理
13. 神话:40万倍性能提升? SQL语句: SQL> select min(test_id), max(test_id), 2 min(org_id), max(org_id) 3 from alex.alex_test; FULL SCAN BUFFER CACHE DIRECT PATH IN-MEM SCAN Elapsed Time(s) Cpu IO Time(s) Waits(s) 166 140 27 Fetch Calls Buffer Gets 1 6M Read Reqs 47759 Read Bytes 47G 69 68 0.19 1 6M 0 0 87 61 26 1 6M 47751 47G 0.13 0.13 0 1 15 5 90112 最大可达1277 倍的性能提升 最大可达1077 倍的性能提升
14. 揭秘:列式存储索引 IMO列式存储索引:  列数据分割存储在多个IMCU内。  列式索引存储了每个IMCU的 MIN/MAX值,优化MIN/MAX查 询。  列式索引的存在,就避免了传统 索引的创建,可以不必创建任何 传统索引,在谓词过滤查询过程 中,同样获得较大优势,也充分 避免DML操作的索引维护成本。
15. 揭秘:列式存储索引 In-Memory Storage Index:  查询V$IM_COL_CU视图,可以查看到IMCU的具体状态。  可以看到在IMCU的数据字典里记录了其最小值、最大值、长度条目数等信息。 SQL> select objd, tsn, length, dictionary_entries entries, 2 minimum_value minval, maximum_value maxval 3 from v$im_col_cu; OBJD TSN LENGTH ENTRIES MINVAL MAXVAL ----- --- -------- ------- -------------- --------------- 92937 6 6648708 533688 C40C365A21 C50A082A2F0A 92937 6 744758 951 31 373030303137 …… 92937 6 984 3 3031 3032 92937 6 2303894 157580 786E0C0E021019 78950A0F0A3601  IMCU会记录这些内容,是因为Oracle在数据加载时会自动创建各个列的列式索引,并会自动 维护,这也是前言实例中为什么列式存储性能会提升600多倍的关键所在。  列式索引的存在,就避免了传统索引的创建,可以不必创建任何传统索引,在谓词过滤查询 过程中,同样获得较大优势,也充分避免DML操作的索引维护成本。
16. 场景测试 IMO索引查询优化案例: 扫描 性能提升倍数(cache) 全表扫描 索引扫描 内存扫描 单列低区分 1.00 13.81 75.10 前导列低区分 1.00 21.86 75.35 MIN/MAX 1.00 0.20 659.20 分组 1列分组 2列分组 4列分组 性能提升倍数(cache) 全表扫描 索引扫描 内存扫描 1.00 7.73 85.30 1.00 6.28 4.24 1.00 1.48 2.15 排序 1列排序 2列排序 4列排序 性能提升倍数(cache) 全表扫描 索引扫描 内存扫描 1.00 4.21 15.18 1.00 3.80 15.05 1.00 3.39 15.80 1000.00 500.00 0.00 100.00 50.00 0.00 20.00 10.00 0.00 全表扫描 索引扫描 内存扫描 659.20 13.8175.10 单列低区分 全表扫描 85.30 21.8675.35 0.20 前导列低区分 MIN/MAX 索引扫描 内存扫描 7.73 1列分组 全表扫描 15.18 6.28 4.24 1.48 2.15 2列分组 4列分组 索引扫描 内存扫描 15.05 15.80 4.21 3.80 3.39 1列排序 2列排序 4列排序
17. IMO优势与劣势 1. 查询操作扫描大量的行,并使用操作符进行数据过滤,操作符诸如:=、<、>、 IN等; 2. 查询操作选择少量的列,而查询对象表或物化视图中包含了大量的列,比如:某 个表包含100个列,而仅查询其中5个列; 3. 查询操作进行小表与大表的联立(Join); 4. 查询要求进行数据聚合操作。 1. 进行复杂谓词的查询; 2. 查询操作选择大量的数据列; 3. 查询返回大量的数据行; 4. 查询要求进行大表复杂的联立(Join)。
18. IMO布隆过滤器 IMO的布隆过滤器:  在IMO列式存储中,当发生表和表的联立时,引进了布隆过滤器(Bloom Filters)。  当两个表发生联立的时候,特别是一个小表对一个大表发生哈希联立(Hash Join)的时候, Bloom Filters 的优势就非常明显了。  如下执行计划所示,其中DATE_DIM为维度表(小表),LINEORDER为事实表(大表)。 DATE_DIM表进行IM内存的全表扫描, 谓词过滤后,Oracle为其生成一个名 为“:BF0000”矢量或者Bloom Filters,以哈希表的形式保存在PGA中。 “:BF0000”即作为LINEORDER表 进行IM内存扫描的一个组成部分, 非常有效地提升了表哈希联立的性能。
19. IMO布隆过滤器 IMO联立查询优化案例: 联立 二大表无条件 二大表有条件 三大表无条件 性能提升倍数(cache) 全表扫描 索引扫描 内存扫描 1.00 3.61 2.97 1.00 35.19 30.40 1.00 3.54 6.42 全表扫描 索引扫描 内存扫描 40 35.19 30.4 30 20 10 3.61 2.97 0 二大表无条件 二大表有条件 6.42 3.54 三大表无条件 --二大表有条件: SQL> select count(x.test_id) 2 from alex.alex_test t, 3 alex.alex_sales x 4 where t.test_id = x.test_id 5 and x.test_id like '11%'; 二大表有条件索引扫描: --------------------------------------------------------------- Id Operation Name --------------------------------------------------------------- 0 SELECT STATEMENT 1 SORT AGGREGATE 2 NESTED LOOPS * 3 INDEX FAST FULL SCAN ALEX_SALES * 4 INDEX UNIQUE SCAN PK_ALEX_TEST --------------------------------------------------------------- 二大表有条件内存扫描: -------------------------------------------------------------------- Id Operation Name -------------------------------------------------------------------- 0 SELECT STATEMENT 1 SORT AGGREGATE * 2 HASH JOIN 3 JOIN FILTER CREATE :BF0000 * 4 TABLE ACCESS INMEMORY FULL ALEX_SALES 5 JOIN FILTER USE :BF0000 * 6 TABLE ACCESS INMEMORY FULL ALEX_TEST --------------------------------------------------------------------
20. SIMD矢量处理 SIMD处理方式:  单指令多数据值的处理 (Single Instruction processing Multiple Data values)  在一个单一CPU指令周期内 进行一组列值的评估处理。  可以预期加快处理速度到每 秒数十亿行。
21. SIMD矢量处理 SIMD矢量处理原理:  维度表(小表)与事实表(大表)的聚合计算在数据仓库的应用中是最为常见的,IMO基于SIMD 矢量处理特点对列式存储的聚合计算也做了相对程度的优化。  如下是一个三个表的IM聚合过程,Stores、Products为维度表,Sales为事实表。  事实表的大小至少为维度表的10倍,随着维度越多聚合越复杂,该方法的效率将越高。 阶段一:准备 1. IM内存扫描各个维度表。 2. 两个表分布创建一个新的数据结构“Key Vector。 3. 根据各维度的Key Vector,在PGA中生成一个 新的二维矢量数据的数据结构(In-Memory Accumulator)。 4. 根据选择的维度创建临时表 阶段二:计算 5. 应用各维度的Key Vector,IM扫描表Sales。 6. 与临时表进行Hash Join,输出最终结果。
22. SIMD矢量处理 IMO聚合查询优化案例: ---------------------------------------------------------------------------------------------------------------------------------------------------- Id Operation Id O peNraatmioen Name 聚合-------性--能--提-升--倍--数--(-c-a-c-h-e-)---------------- -------0--- ---S--E--L--E-C--T---S--T--A-T--E--M-E--N--T----------------------------------- ---------------------------------- 全0 表 扫SE描LEC星T 型S转TA换TEME内N存T 扫描 3表星型 1 1T.E0M0P TAB8L.9E3TRANSF2O9R.2M6ATION 1 TEMP TABLE TRANSFORMATION 2 3 LOAD AS VECTOR SELECT GROUP BY SYS_ TEMP_第0FD一9D6阶6E7段_9322468 3表雪花 5表雪花 2 1.0L0OAD A1S1.3S4ELECT 32.14 3 1.00VECTOR7.2G0ROUP BY14.20 4 KEY VECTOR CREATE BUFFERED 4 SKYESY _VTECETMORP_C0REFADTE9DBU6F6FEER7E_D 9322 46:K8V 0000 5 6 TABLE ACCESS LOAD AS SELECT INMEMORY FULL ASLYESX_ _TOERMGP__I0DFD9D66E8_9322468 7 :VEKCVTO0R0G0R0OUP BY 40.00 30.00 全5表扫 描 索引TA扫B描LE AC内C存ES扫S描INMEMORY FULL 8 9 AKLETEYABXVL_EECOTAROCRCGE_CSRSIEDAITNEMEBMUOFRFYERFEUDLL :AKLVE0X0_ 0C1REATED_BY 6 LOAD AS SELECT 10 HASSYHSG_RTOUEPMBPY_0FD9D66E8_9322 468 7 8 29.26VECTOR GR3O2U.1P4 BY KEY VECTOR CREATE * 11 BUFFERED * * 12 13 HASH JOIN :THKAAVBSLH0E0JAO0CI1CNESS FULL SYS_ TEMP_0FD9D66E7_9322468 9 TABLE ACCESS INMEMORY FULL 14 ALTEABXL_ECARCCEEASSTEFDUL_LBY SYS_T EMP_0FD9D66E8_9322468 20.00 10.00 10 * 118.9 3 * 12 1*.0013 HASH GROUP BY 14.20 HASH J11O.I34N 7.20 TABLE ACCESS FULL H1A.0S0H JOIN 1.00 15 16 VIEW VECTOR GROUP BY VW_V T_1B3第5BA二0F 阶段 17 HASH GROUP BY 18 19 SYS_KTEKYEEYMVEVPCE_TC0OTROFRDUSU9ESDE 66E7_9322 46::KK8VV00 000010 * 20 TABLE ACCESS INMEMORY FULL ALEX _TASK 0.00 31表4星 型 TAB3表LE雪花ACCESS FU5L表L雪花 -Pr-e-d-ic-a-t-e-I- n-f-orS-m-Ya-tSi-o-_n-T-(i-Ed-eM-nt-Pi-_f-i0-ed-F-bD-y-9o-pD-e-r6a-6t-i-Eo-n8-i_-d-)9:-3--2-2--4-6--8-- ------------------------ -S-Q3L>表S星EL型E C聚T o合11.56a_i d, VIEW c.cy_iVd,ECSTUOMR(taGsRkO_UidP) BY VW_VT_1B35BA0F --------------------------------------------------- 5 - inmemory(""O"".""ORG_ID"" LIKE '1011%') filter(""O"".""ORG_ID"" LIKE '1011%') 9 - inmemory(""C"".""CREATED_BY"" LIKE 'Z%') 2 FR OM a1l7ex. alex_org_idHASH GoR,OUP BY filter(""C"".""CREATED_BY"" LIKE 'Z%') 3 4 aa1ll8eexx.. aalleexx__ctraesaktedK_EbYy VctE,CTOR USE 5 WHE RE t1.9org _id = o.org_iKdEY VECTOR USE :KV0001 11 - access(""ITEM_8""=INTERNAL_FUNCTION(""C0"") AND ""ITEM_9""=""C2"") 12 - filter(""C2"" IS NOT NULL) :KV0000 13 - access(""ITEM_10""=INTERNAL_FUNCTION(""C0"") AND ""ITEM_11""=""C2"") 20 - inmemory(""T"".""CREATED_BY"" LIKE 'Z%' AND ""T"".""ORG_ID"" LIKE '1011%' AND 6 7 A ND* t2.0cre ated_by = c.crTeAatBeLdE_bAyCCESS AND o.org_id like '1011%' INMEMORY FULL ALEX_TASK SYS_OP_KEY_VECTOR_FILTER(""T"".""CREATED_BY"",:KV0001) AND SYS_OP_KEY_VECTOR_FILTER(""T"".""ORG_ID"",:KV0000)) 8 A-ND--c-.-c-re-a-t-e-d_-b-y--l-ik-e--'-Z-%'-----------------------fi-lt-er-("S-"Y-TS"_-"O.P-"_"K-CERY-E_AV-TEEC-DT-_OBR-Y_"F-"IL-LTIE-KRE(-"'"-ZT-%"'"-.A"-N"DC-R"E-"ATT-"E"D-._-"B"Y-O"R"-G,_:-IKDV-"0"0-0L1I)KEAN'D1011%' AND 9 GROUP BY o.a_id, c.cy_id; SYS_OP_KEY_VECTOR_FILTER(""T"".""ORG_ID"",:KV0000)) 第一阶段 第二阶段
23. SIMD矢量处理 三表星型聚合查询优化案例: Elapsed Cpu IO Fetch Time(s) Time(s) Waits(s) Calls FULL SCAN (cache) 69 69 0.13 1 Buffer Gets 6M Read Reqs 0 Read Bytes 0 STAR TRANS (cache) 4.91 4.80 0.11 1 524k 2125 65M IN-MEM SCAN (cache) 2.27 2.25 0.00 1 55 2 16384 SIFNUT-ALMRLESTMCRSAACNNA执SNF执行O行计RM计划划A分T分I析O析N::执行计划分析: ========================================================================================================================================================================================================= = =I=d== ===============O=p=e=r=a=t=i=o=n============== =============N=am=e============= ==R=o=w=s==== ==C=o=s=t== ====T=i=m=e===== =S=t=a=r=t=== ==E=x=e=c=s= ====R=o=w=s==== ==Re=a=d== ==R=e=a=d=== ==Wr=i=t=e== ==W=r=i=t=e== ==M=e=m=== ==A=c=t=i=v=i=t=y= ==A=c=t=i=v=i=t=y==D=e=ta=i=l== ==I=d= = ==============O=pe=r=a=t=i=on=========== ===== ==========N=a=m=e==== ==(E=s=t=i=m)= = =R=o=w=s== = =Ac=Ct=ois=vt=e(= s=)= =T=Ai=cm=tei=v=e= = ==St=a=r=t= =( =A=cE=txu=ea=cls=)= ==R=eqR=so=w= s=B=y=t =es=R=e =a=dRe=q =s=R=e a=d=B=yt= e=s=M =e=(m=Ma=x =)=A= c=t=iv=(i%=t)=y== = A=c=t=i(=v#i=t=sya=m=Dp=elte=sa=)i=l = ==I=d== = ==========O==p=e=r=a==t=i=o==n=========== ============= ====N=a=m==e================ ====R=o==w =s=(=E=s=t= i==m=)C=o= s==t== === ==TA=c=it=m=ie=v=e=(=s=)== ==SA=ct=t=ai=rv=t=e== = ===E=x=e==c =s=(= =A=c=t=u=aR=l=o)=w= s==R=e=q= s=== =M=B=ey=tm=e=s== ==(A=M=ca=t=xi=)=v= i=t==y=(= %=)==A=c=t=i= =v=i=t=(=y#==sD=ae=m=tp=al=ie=s=l=)= === = = ==0== == S=E=L=E=C=T==ST=A=T=E=M=E=N=T=============== ====== ============================ = ===(=E=s=t=i= =m=)== === ====== ==A=c=1t== i=v=e=(=s=+=)2== ==A==c=t=1i=v =e=== ====1=3== == ===(=A =c=t=u==a=l=)= = ===(=M=a= x==)== ==== =(=%=)==== == =====(=#== =s=a=m=p==l=e=s=)===== === = ==1234567013452=0123 = = S=ET=SLHELL=EEAHMOVVO=LHCSTHAPAEKEATHAATS=EAHDCETCDBSAHTTYAT=CSATAAOBOASGLHB=THSABSRVLRSTRELJ=HBLEEAOJEOESGCGS=SGLTUAOIERTAREEPCIAN=TRJETLOOCOLMCNC=AOOREURCUEEBEC=TUIAACPEPCNYSENTCST=EPNCTSSSBRSB=MCSFYEYF=EBEOAIUFRTN=NYSLUMEM=TSLLAE=TBML=FIUOOFR=UNFY=LE=LRF=EUDL=L= ==A=L=E= X=_:A=OKL=RVE0X=G0_= _0O=I0RAA=GDLL_=EEI=XXD=__OC=RR=GE=_A=IT=DED=_=B=Y==== == ===5=2116110=5 =45 =886=68082=81511= 352004=1284162862048= = =22=MM3777=000111= KK39K== =1111111= =====666+++++++=99912000000333113= = ====1111111=++++++=++++ 333333=2222 == ==55=61161111111=0321012= =1111== ==155= 5277=622211=04KK33=5 =75=1126=33K0 == = ==11= =12=MM=8811= 99=22= ==2212=798MMM126=1617 =.862=4 =7 = = ==C=p=u = =( =1=)========= = 864 KTEAYHBAVLSEECHTAOCJRCOECISRNSEABTYE BIUNFDFEEXRERDOW ID BA TC:HKEVD00 01ALEX_TASK 88 3 42 5 34K 2M701 K 1 6+904 1++ 22 12214 1 5 72K5 72K 2M 6553 6 6 0.00 Cpu (3) 1190178956 HAHSATHSBAHBGIBTTLRJTIBAAEOOMTIUIBBAMTAPNPAMLLCPAEECBCPEYOASAANNMSCCVDEERCCIRGNEESEMSSIESSMOONRFFYTUUOLLFLLURLOLW IDAASLLEEX X__ATCLAREXSE_K ACTREEADT_EBD_YBY 1211233451 32 4266K47700 55541 9 2M 1 1 1 6+++91220333 111+++++ 33322 12214 113 113 11 5 76214K9951 7222K4 6198M3811 .MK5 3 20.C0p0u ( C6p7u)(1) ==11=20= = =====H=AS=H==JBO=IIT=NM=A=P==IN=D=E=X==RA=N=G=E==SC=A=N==== ===== =B=I=X=_=TA=S=K=_=C=RE=A=T=E=D=_B=Y= ======12= = =6=7=0=5=2 = = ====== =1= =====+=23= = ====1=+= 1= =====11=3= ====1=7= 0=5=6= ==2=1 =2=5= ===6 5=M=B== == ====1 =M= ===20=.=0=0== = C=p=u==(1=)======= 1131 TABLBEITAMCACPESMSERFGUELL SYS_T EMP_0FD9D66AE_96B9C90 10 2 1 +23 1+ 3 111 1 34881 92 38M 1142 VIEWBITMAP INDEX RANGE SCAN VW_VT _1BBI3X5_BTAA0FSK_ORG_ID 13 67050 1 +21 1+ 3 113 10 435 = =1=5== =========VE=C=T=O=R==G=R=O=U=P==B=Y=============== ============================ ======1=3== ==6=7=05=0== ==========1== =====+=2== =====1== ========1=3== ====== ======== ======= ======== =1=3=3=1=2== ========== ================= 16 HASH GROUP BY 13 67050 1 +2 1 0 17 KEY VECTOR USE :KV0000 1 +2 1 572K 18 KEY VECTOR USE :KV0001 1 +2 1 572K 19 TABLE ACCESS INMEMORY FULL ALEX_TASK 534K 64544 2 +2 1 572K 100.00 in memory (2) 20 TABLE ACCESS FULL SYS_TEMP_0FD9D66AF_96B9C90 11 2 1 +2 1 11 1 8192 =========================================================================================================================================================================================================
24. 查询优化小结  IMO特性能极大程度地提升查询性能,特别是数据扫描(Data Scanning)方面的。  Joins和Vector-By聚合也可以预期非常高的性能优势。  然而,没有一项技术可以成为魔术,Sorting、常规聚合等仍然会消耗较长时间。
25. 目录 IMDB概述 查询优化 列式存储 并发处理
26. 压缩级别 IMO列式压缩的级别 压缩级别 NO MEMCOMPRESS MEMCOMPRESS FOR DML MEMCOMPRESS FOR QUERY LOW 说明 数据无压缩(但是做了列式存储后,较行式存储仍 有一定压缩量。) 最小级别的压缩,有利于DML操作的性能优化。 最优化查询性能(缺省值) MEMCOMPRESS FOR QUERY HIGH 查询性能优化,同时获得更大空间压缩比。 MEMCOMPRESS FOR CAPACITY LOW 获得更大的空间压缩量。 MEMCOMPRESS FOR CAPACITY HIGH 最优化空间节省,活动最大的压缩比。  IMO进行列式压缩后,大致可以获得2~20倍的空间节省,不仅取决于压缩级别选项,同样依赖 于数据本身的特点。  MEMCOMPRESS FOR CAPACITY HIGH虽然压缩比最大,但在查询性能上不会有太大的劣势。
27. 压缩级别 IMO列式压缩的级别 优先级别 CRITICAL 说明 数据库打开的时候,IM对象就自动加载。 HIGH CRITICAL级别对象加载完成后,如果空间足够,自动加载该级别对象。 MEDIUM LOW NONE CRITICAL、HIGH级别对象加载完成后,如果空间足够,自动加载该级别对象。 CRITICAL、HIGH、MEDIUM级别对象加载完成后,如果空间足够,自动加载该级 别对象。 该级别为缺省值,当IM对象被第一次扫描时,如果空间足够,触发该对象的加载。  非必要情况,尽可能选择默认的NONE级别,提升数据库启动过程的效率。  对于必要加载对象,可以选择非繁忙时段,手工触发加载,因为加载过程会有较高的CPU开销。
28. 压缩对比测试 列式存储加载压缩测试:  以测试大表ALEX_TEST为例,各级别压缩比为1.16~6.51,最大未及10倍压缩。  从加载速度上来看,开启10个加载进程,加载速度与压缩比呈正比例上升趋势。 Wnnn数 表名 10 ALEX_TEST 10 ALEX_TEST 10 ALEX_TEST 10 ALEX_TEST 10 ALEX_TEST 10 ALEX_TEST 行数 表大小 缓存大小 (GB) (GB) 缓存类型 206,609,165 46.61 40.09 NO MEMCOMPRESS 206,609,165 46.61 38.79 FOR DML 206,609,165 46.61 18.59 FOR QUERY LOW 206,609,165 46.61 14.6 FOR QUERY HIGH 206,609,165 46.61 9.8 FOR CAPACITY LOW 206,609,165 46.61 7.16 FOR CAPACITY HIGH 加载时间 (s) 191 199 436 456 612 692 压缩比 1.16 1.20 2.51 3.19 4.76 6.51 800 600 400 200 1.16 0 NO MEMCOMPRESS 1.20 FOR DML 2.51 3.19 4.76 6.51 8.00 6.00 4.00 2.00 FOR QUERY LOW 压缩比 0.00 FOR QUERY HIGH FOR CAPACITY LOW FOR CAPACITY HIGH 加载时间(s)
29. 数据加载 列式存储加载压缩测试: 通过top命令监视,可见在Wnnn进程进行IM数据加载的过程中, 是非常消耗CPU资源的,10个Wnnn进程几乎都独占了一个逻辑CPU。 进一步证明了数据加载过程不可以在实例启动时进行。
30. 数据加载 列式存储压缩比估算方法: DECLARE l_blkcnt_cmp l_blkcnt_uncmp PLS_INTEGER; PLS_INTEGER;  此方法实际上就是通过 l_row_cmp l_row_uncmp PLS_INTEGER; PLS_INTEGER; 进行列式缓存来进行估 l_cmp_ratio PLS_INTEGER; l_comptype_str VARCHAR2(100); comp_ratio_allrows NUMBER := -1; 算,成本开销过大。 BEGIN dbms_compression.get_compression_ratio(  尽量不要使用。 -- Input parameters scratchtbsname => ‘ALEXTBS', ownname => 'ALEX', objname => ‘ALEX_TEST', subobjname => NULL, SQcLo>mpsteylpeect segme=n>t_name, 2 round(bytes / 1024 / 1024 / 1024, 2) seg_size, dbms_compression.comp_inmemory_query_low, 3 round(inmemory_size / 1024 / 1024 / 1024, 2) inmem_size, -- Output parameter 4 round(bytes_not_populated / 1024 / 1024 / 1024, 2) progress_size, blkcnt_cmp => l_blkcnt_cmp, b5lkcnt_uncmipnmem=o>ryl__cbolmkpcrnets_suinocnmpi,nmemory_comp, r6ow_cmp popul=a>tel__srtoawt_ucsmp, r7ow_unfcrmopm v$im_=s>eglm_ernotws_;uncmp, cmp_ratio => l_cmp_ratio, SEcGoMmEpNtTy_pNeA_MsEtr SEG=_>SIlZ_EcoImNpMtEyMp_eS_IsZtEr,PROGRESS_SIZE INMEMORY_COMP POPULATE_STATUS --s-u-b-s-e-t-_-n-u-m-r-ow-s--=->---- ---------- ------------- -------------- --------------- dbms_compression.cCoMmPp3_$r9a2t9i3o7_allrows4)6;.87 14.8 16.23 FOR QUERY LOW STARTED dbms_output.Put_line('The IM compression ratio is ' l_cmp_ratio); END;
31. 压缩对比测试 IMO与同类DB压缩对比:  下例为IMO与Exadata上,财务库用户帐户信息表(压缩前约35GB大小)的对比测试结果。 15.00 10.00 5.00 8.79 4.72 10.73 8.53 12.30 10.11 Exadata IMO 压缩比 0.00 query high capacity low capacity high  下例为IMO与HANA上,财务库总账平衡表的对比测试结果。 表名 GL_BALANCES 表大小(GB) 251.37 缓存大小(GB) 缓存类型 93.41 FOR QUERY HIGH 67.78 FOR CAPACITY LOW 52.37 SAP HANA 51.53 FOR CAPACITY HIGH 压缩比 2.69 3.71 4.80 4.88
32. 批量导数 事实表(Fact Table)批量导数:  对于OLAP的应用来说,常见事实表的批量导数操作,极少出现短小事务行为。  通常情况,事实表上有较多数量的索引,批量导数时,会先删除索引,在完成导数后再重建。  列式存储事实表后,可以不建任何传统索引,同样可以获得高效查询能力,且避免了导数带来的 索引维护成本,随着表的大小越大,其优势越明显。 表名 操作方法 大小(GB) 索引数 导数(s) 建索引(s) 列式缓存(s) 总时间(s) 方法一:建立索引,导数 TASK_TEST 方法二:导数,重建索引 方法三:导数,列式缓存 方法一:建立索引,导数 TASK_TEST 方法二:导数,重建索引 方法三:导数,列式缓存 2.25 46.61 1305.01 5 198.53 198.53 18000 5 3512.57 3512.57 0 35.48 0 0 6949.2 0 0 1305.01 0 234.01 90 288.53 0 18000 0 10461.77 436 3948.57 2G表批量导数 40G表批量导数 1500 20000 1000 500 15000 10000 5000 0 方法一 方法二 方法三 0 方法一 方法二 方法三 导数(s) 建索引(s) 列式缓存(s) 导数(s) 建索引(s) 列式缓存(s)
33. RAC应用 IMO基于RAC架构的分布式应用  大对象(分区表)IMCUs分布式存储: - AUTO(默认) - BY ROWID RANGE - BY {SUB}PARTITION  容错 - DISTRIBUTE子句控制IMCU在RAC节 点间的副本冗余方式 - DISTRIBUTE ALL表示每个IMCU在所 有RAC节点存储副本
34. 目录 IMDB概述 查询优化 列式存储 并发处理
35. 并发星型聚合 星型聚合并发场景测试:  前面提到在星型聚合的场景测试中,IMO的SIMD查询方式较传统Bitmap星型转换查询方式的性 能提升3~4倍;  当面对高并发查询的时候,SIMD的性能优势并没有减弱;  然而,并发压力较大的时候,Bitmap星型转换会需要使用较多PGA空间。 TPS(星型聚合) 14.00 12.00 10.00 8.00 6.00 4.00 2.00 0.00 1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 SIMD 0.35 2.13 4.60 6.55 9.38 10.0 11.0 11.0 11.5 11.4 11.1 11.7 11.2 11.3 11.3 11.5 10.6 11.0 11.0 11.2 11.1 BITMAP 0.17 0.95 2.68 2.97 3.97 4.53 5.47 5.23 4.27 3.92 4.87 4.65 4.95 4.77 4.98 4.90 5.67 4.57 4.83 4.28 4.93
36. 并发短事务处理 短事务并发场景测试:  OLTP应用的短事务处理,概念中IMO为是列式存储,将会较大的性能劣势,然而事实并非如此。  In-Mem较之No-Index仅有10%~20%的性能下降,列式存储并未出现预期的较大性能损失。  而Bitmap中,因为DML需要进行位图索引的维护,出现大量的enq: TX - row lock contention等待时 间,整体性能下降明显。  之所以,IMO应用并没有像索引应用一样,造成短事务处理的劣势,是因为IMO的维护是异步完成的,后 台进程自动维护保证DML操作的数据读一致性。 TPS(短事务) 3000.00 2500.00 2000.00 1500.00 1000.00 500.00 0.00 1 5 10 20 30 40 50 60 70 80 90 100 Bitmap 313.47 171.37 280.92 180.87 132.93 110.10 99.02 86.12 75.58 58.40 55.45 48.45 In-Mem 96.80 1151.98 2252.52 1724.50 1694.57 1582.62 1482.73 1419.53 1394.55 1317.48 1312.52 1388.22 No-Index 386.10 2726.63 2499.65 2072.22 1955.83 1787.60 1826.05 1899.27 1603.57 1751.45 1623.23 1645.05
37. 并发短事务处理 Bitmap,Top10等待事件: 出现大量的enq: TX - row lock contention等待事件, 整体性能下降明显。 In-Mem,Top10等待事件: 出现预期内的buffer busy waits 之外,还出现了IM buffer busy 的等待,此为Oracle维护IMCU journal来保证数据一致读的行为, 也是性能下降的原因。 No-Index,Top10等待事件: 无特别值得关注点。
38. 混合并发场景 20.00 15.00 10.00 5.00 0.00 In-Mem混成场景 60 55 50 45 40 35 30 25 20 15 10 5 1 20.00 15.00 10.00 5.00 0.00 SIMD TX Bitmap混成场景 60 55 50 45 40 35 30 25 20 15 10 5 1 Bitmap TX 65 70 65 70 75 75 80 80 85 85 90 90 95 95 100 100 2000.00 1500.00 1000.00 500.00 0.00 200.00 150.00 100.00 50.00 0.00 混合并发场景测试:  将前面两个并发测试场景(星型聚 合查询、短事务处理)混合起来测 试,模拟MIS库的操作行为。  其中,短事务处理持续为并发度为 100,而星型聚合查询为并发度递 增,如图横坐标所示。  Bitmap的测试结果显示,短事务处 理和星型聚合查询TPS并无较大损 失。  In-Mem的测试结果显示,短事务 处理和星型聚合查询TPS也并无较大 损失,同时保持了较Bitmap的优 势。  可见,IMO对于MIS库的混合场景 应用是有较大益处的。