極限存储方案―――让1T空间存储100T数据.docVIP

极限存储方案―――让1T空间存储100T数据！ 下面将介绍一种海量数据的存储方案，在适当的场合下使用该方案，可以大大节约存储空间。 举个最简单的例子，比如有一张表，它有4个字段: 用户注册日期, 编号，姓名，地址 该表5月1日的记录如下：当我们全量同步这张表的时候，则5月1日的分区中存在8条记录 用户注册日期 编号 姓名 地址 5月1日 001 张三 西湖区 5月1日 002 李四 西湖区 5月1日 003 王五 上城区 5月1日 004 张1 下城区 5月1日 005 王1 西湖区 5月1日 006 王2 西湖区 5月1日 007 王3 上城区 5月1日 008 王4 下城区 该表5月2日的记录如下：当我们全量同步这张表的时候，则5月2日的分区中存在10条记录 用户注册日期 编号 姓名 地址 5月1日 001 张三 西湖区 5月1日 002 李四 西湖区 5月1日 003 王五 下城区（王五搬到了下城区） 5月1日 004 张1 下城区 5月1日 005 王1 西湖区 5月1日 006 王2 西湖区 5月1日 007 王3 上城区 5月1日 008 王4 下城区 5月2日 009 张2 上城区 5月2日 010 张3 下城区 该表5月3日的记录如下：当我们全量同步这张表的时候，则5月3日的分区中存在12条记录 用户注册日期 编号 姓名 地址 5月1日 001 张三 上城区 张三这个人搬家了，因此地址变换了 5月1日 002 李四 西湖区 5月1日 003 王五 下城区 5月1日 004 张1 下城区 5月1日 005 王1 西湖区 5月1日 006 王2 西湖区 5月1日 007 王3 上城区 5月1日 008 王4 下城区 5月2日 009 张2 上城区 5月2日 010 张3 下城区 5月3日 011 张4 上城区 5月3日 012 张5 下城区 数据仓库中的数据，存放的是反应历史变化情况的快照数据，一般一旦数据进入数据仓库，都会保留相当长的一段时间。因此当一些大表，而且每天增长量又相当大的情况下，传统的存储方式就会占用相当大的存储空间。（我们不能只保留最近一份全量数据，把之前的都删除，这样就不能反应历史情况了。） 就比如上面这个例子中，5月1号的数据存放了8条记录；5月2号的数据存放了10条记录，5月3号的数据，存放了12条记录，而且随着时间的推移，每天的全量数据将不断的增加。 为了解决这个存储问题，于是就引发了一个思考：如何才能节约存储空间，而又能反应数据的历史情况？ 我们看一下上面3天的记录数，其实一共就是从编号001到012的12个人的记录，其中张三和王五因为搬家变更了一次地址。如果我们给记录加上一个生命期的概念，那么就能达到既节约存储空间，又能反应数据历史变化情况的效果了。 用户注册日期 编号 姓名 地址 Begin_date End_date 5月1日 001 张三 西湖区 2011-05-01 2011-05-02 5月1日 001 张三 上城区 2011-05-03 2011-05-03 5月1日 002 李四 西湖区 2011-05-01 2011-05-03 5月1日 003 王五 上城区 2011-05-01 2011-05-01 5月1日 003 王五 下城区 2011-05-02 2011-05-03 5月1日 004 张1 下城区 2011-05-01 2011-05-03 5月1日 005 王1 西湖区 2011-05-01 2011-05-03 5月1日 006 王2 西湖区 2011-05-01 2011-05-03 5月1日 007 王3 上城区 2011-05-01 2011-05-03 5月1日 008 王4 下城区 2011-05-01 2011-05-03 5月2日 009 张2 上城区 2011-05-02 2011-05-03 5月2日 010 张3 下城区 2011-05-02 2011-05-03 5月3日 011 张4 上城区 2011-05-03 2011-05-03 5月3日 012 张5 下城区 2011-05-03 2011-05-03 如上图，如果将数据存储成以上形式。那么总记录条数减少到了14条。 而真实的表，字段要远远比上面例子中的多，每天的记录也远远比例子中的多，所以使用该存储优化方案带来的效果将非常明显。 如果要查询5月2号分区的数据，SQL也非常容易写： Select * from table where begin_date ’2011-05-02’ and end_date ’2011-05-02’; 重复存储是最大的浪费，极