做了个10G中的压缩表测试，发现压缩比例还是比较高的，关键看数据是否按照重复性高的列在排序
也对压缩表和非压缩表查询进行了对比，测试结果表明解压还是存在不少的CPU消耗，时间居然比普通表要久，
但数据很多是经过cache的,相信在IO比较多的查询上，IO量的节省带来的效益应该可以盖过CPU计算产生的消耗
  
cnckweblog@DWALI> create table nocompress_10G as select * from all_objects;

Table created.
cnckweblog@DWALI>create table compress_10G nologging compress as select * from nocompress_10G;

Table created.

cnckweblog@DWALI> select SEGMENT_NAME,sum(BYTES) from user_extents where segment_name in (’NOCOMPRESS_10G’,'COMPRESS_10G’) group by SEGMENT_NAME;
SEGMENT_NAME                   SUM(BYTES)
—————————— ———-
NOCOMPRESS_10G                 2134900736
COMPRESS_10G                    639631360

全表扫描，压缩表比较有优势
cnckweblog@DWALI>select count(*) from nocompress_10G;

  17995776

1 row selected.
Elapsed: 00:00:05.69

cnckweblog@DWALI>select count(*) from compress_10G;

  17995776

1 row selected.
Elapsed: 00:00:01.50

owner列应该是高度压缩的，选择他会引起CPU的消耗，结果压缩表比较慢
cnckweblog@DWALI>select count(*) from nocompress_10G where owner = ‘mm’;
         0

1 row selected.

Elapsed: 00:00:05.64

cnckweblog@DWALI>select count(*) from compress_10G where owner = ‘mm’;

         0

1 row selected.

Elapsed: 00:00:07.35

把表膨大N倍，现在普通表是12G，压缩表是3.7G,我们的缓冲区只有7G

cnckweblog@DWALI> select SEGMENT_NAME,sum(BYTES) from user_extents where segment_name in (’NOCOMPRESS_10G’,'COMPRESS_10G’) group by SEGMENT_NAME;
SEGMENT_NAME                   SUM(BYTES)
—————————— ———-
NOCOMPRESS_10G                 1.2549E+10
COMPRESS_10G                   3707764736

在来看看这场CPU和IO之间的争斗
cnckweblog@DWALI>select count(*) from NOCOMPRESS_10G;
 
 106983103
 
 1 row selected.
Elapsed: 00:01:03.10

cnckweblog@DWALI> select count(*) from COMPRESS_10G;

 106983103

 1 row selected.
Elapsed: 00:00:17.43

现在压缩表占优势了
cnckweblog@DWALI>select count(*) from compress_10G where owner = ‘mm’;
     112646  consistent gets
        265  physical reads
    Elapsed: 00:00:36.30

cnckweblog@DWALI> select count(*) from nocompress_10G where owner = ‘mm’;
     382073  consistent gets
     292476  physical reads
    Elapsed: 00:01:12.62
   
可以看到，使用压缩表时空间大约是普通表的1/3，如果数据经过比较好的排序，重复性较高，比例可能更高，
在查询压缩表时，CPU有一定的开销，在CACHE比较充足的情况下，压缩表表现的并不好，但当表的数据比较
大时，IO瓶颈是关键，远远盖过了CPU计算，所以数据仓库的大型表使用压缩应该还是比较合适的,当然你得保证CPU够猛

有7人发表了评论  ↓发表评论↓

• 

  除非并行特别大，一般来说 cpu 应该问题不大

  fcp @ March 13, 2008 |

• 

  并该是 并发

  fcp @ March 13, 2008 |

• 

  已经在用啦,不过dml会有一定些性能影响

  brotherxiao @ March 14, 2008 |

• 

  所以应用压缩表适合数据仓库应用，对于经常发生dml操作的应用影响还是很大。

  勇斌 @ March 17, 2008 |

• 

  (:

  vogts @ March 17, 2008 |

• 

  我们这边去年年初开始用的，有些表的压缩效果非常好，空间只为原来的40%。有些表压缩效果不是很好。压缩率还是跟表中数据分布有很大关系。查询的话性能也会好，因为IO少了，CPU开销倒还好，在我们这边使用综合效果不错。

  blue_prince @ April 9, 2008 |

• 

  前两天遇到压缩表的bug,在10203中,如果一行数据大于一个block size,压缩会报600错误,这个在11G才修正,不知道10204里面解决没有,如果使用大点的block size,碰到的几率应该小很多

  八神 @ April 10, 2008 |

Name (必填)

Mail (不会公开) (必填)

网站

表情：<(￣︶￣)> | (⊙ˍ⊙) | ＞﹏＜ | ｂ（￣▽￣）ｄ | （─.─||） | (^_-)

[ Ctrl+Enter提交 ]