eBay的chao_ping在Oracle-l中问如何节约历史库的空间, 经过了10年的发展, eBay的历史库积累了100多TB的数据, 并且数据的增幅很大, 虽然历史库用不着很好的存贮, 但这笔成本还是比较大的. 已经使用了压缩表将常规的表的空间压缩到了三分之一到六分之一, 但其中有一半的数据是用LONG或LONG RAW类型存放的, 没有办法用压缩表. 想想再过几年, 这样的历史库空间问题, 也会面临在很多的DBA前面.

    在Oracle中比较花存贮的有如下方面:

    字段编码. 不要小看这个字段编码, 比如状态字段, 用"E"和用"ENABLE"来表示, 当然后者更好读了, 生产库中应用开发人员可能偏向于后者, 但到历史库中时, 不如转换成前者. 其实一个表中一般不止一个这样的状态字段. 因此我将这个摆在第一位.

    索引. 在生产库上就有些索引, 用得很少, 但每次要用, 都是比较重要的情况, 因此不得不心不由己地加索引, 历史库也有一样的情况. 其实有时不如引进针对某类记录的附加表, 来解决大表的索引问题.

    LOB列. 大量的LOB不光是耗性能, 也是很耗空间的, 因为LOB的最小分配单位是一个数据块, 两个LOB值没有办法共享一个数据块. 如果是CLOB, 在变长字符集中存放大量英文文本的话, 浪费更严重, 一个英文字母在LOB中存放需要占用两个字节, 不管是INLINE还是OUTLINE.

    LONG列. 有LONG的列没有办法压缩, 在插入记录时, Oracle也会过量使用空的数据库, 因而浪费空间. 用utl_compress将值取出来, 再存到LONG RAW中或RAW中, 也是不错的选择.

    垃圾数据. 数据库中肯定多多少少会有垃级记录, 象天文数字交易额的交易记录等等, 要筛选这些记录, 过程可能过于复杂, 所以就留了它们.

    当然应对的办法, 也就随之而出了, 压缩及11g中的新的LOB格式. 也许可以将所有的字段进行序列化, 然后存在一个字段中, 要查询时用应用来解开这些字段. 过段时间也好好分析一下我们的历史库, 想想有没有办法省钱.