这周客户的问题非常多，总是说我的数据不对。于是我对数据梳理了以后发现以前认为是重复数据的，其实并不是，而是我忽略了一个维度。那么这样一来，我们的周详单表就会有500多万的数据。一个月按照4周计算，就要有2000万条数据。而我大概计算了一下，每一个周的分区要占用2G多的存储空间，要知道电信给我们的空间不过是500G左右，我们大家都在用，我一个人每周消耗2G，显然不合适。
这个时候有如下几个解决方案，第一个，将一个月或者几个月以前的数据干掉，以后客户需要的时候从数据仓库抽取数据，然后重新展现就好了。但是这个办法并不是很靠谱，因为数据仓库每一段时间会清理一些表，万一那个时候数据没有了，那群客户一定会把我五马分尸。第二种就是对数据本身进行处理，我想到的办法就是压缩表——compress。
压缩表本身的语句相当简单，总的来讲分为两种类型，一种普通表的压缩，一种是分区表的压缩。相关的语法如下：
--建立普通表
create table table1
(
......
) compress;
--建立分区表
create table table1
(
...
) compress
partition by range(...)
(
partition part_1 values less than(...) compress,
partition part_2 values less than(...) compress,
...
)
如果是一个已经存在的表要进行压缩也很简单：
alter table table1 move compress;
如果是一个分区表的话会更加灵活，只需要压缩你想要压缩的表空间就可以了：
alter table tables1 move partition part_1 compress;
在我遇到的这个情况中，我倾向于在另外一个表空间新建一张分区压缩表，然后在存储过程每周刷新数据的时候，把指定的历史数据转移到这个新的表中，然后清空该分区，这种处理方法不管过多久，表的大小基本上是不变的，不用担心时间长了数据会把表空间占满。
根据我在网上查阅的资料，我发现压缩表其实和平时用rar压缩一大堆word文件是差不多的道理，压缩的时候需要耗费不少时间，压缩以后效果非常明显，占用空间只是以前的一半甚至不到一半，但是想查阅这些数据的时候，却要消耗比平时多的时间。据网上的资料显示，甚至会三倍于非压缩表。所以，压缩表并不适合存储当月的新鲜数据，而比较适合历史数据的存储，因为客户想看一年前的数据的情况基本不大，尤其是这种周详单。
还有一点需要讲的是，插入语句必须有hint：/*+append*/，如果不加这个是没有办法压缩的。存进去还是原来那么大。
« 上一篇：PostgreSQL学习笔记
» 下一篇：一周以来工作总结--关于表的压缩
http://www.cnblogs.com/wingsless/archive/2012/09/23/2699309.html