《极限存储方案―――让1T空间存储100T数据.doc》由会员分享，可在线阅读，更多相关《极限存储方案―――让1T空间存储100T数据.doc（3页珍藏版）》请在金锄头文库上搜索。
1、极限存储方案让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条记录用户注册日期编号
2、姓名地址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下
3、城区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条记录，而且随着时间的推移，每天的全量数据将不断的增加。为了解决这个存储问题，于是就引发了一个思考：如何才能节约存储空
4、间，而又能反应数据的历史情况？我们看一下上面3天的记录数，其实一共就是从编号001到012的12个人的记录，其中张三和王五因为搬家变更了一次地址。如果我们给记录加上一个生命期的概念，那么就能达到既节约存储空间，又能反应数据历史变化情况的效果了。用户注册日期编号姓名地址Begin_dateEnd_date5月1日001张三西湖区2011-05-012011-05-025月1日001张三上城区2011-05-032011-05-035月1日002李四西湖区2011-05-012011-05-035月1日003王五上城区2011-05-012011-05-015月1日003王五下城区2011-05-
5、022011-05-035月1日004张1下城区2011-05-012011-05-035月1日005王1西湖区2011-05-012011-05-035月1日006王2西湖区2011-05-012011-05-035月1日007王3上城区2011-05-012011-05-035月1日008王4下城区2011-05-012011-05-035月2日009张2上城区2011-05-022011-05-035月2日010张3下城区2011-05-022011-05-035月3日011张4上城区2011-05-032011-05-035月3日012张5下城区2011-05-032011-05-03
6、如上图，如果将数据存储成以上形式。那么总记录条数减少到了14条。而真实的表，字段要远远比上面例子中的多，每天的记录也远远比例子中的多，所以使用该存储优化方案带来的效果将非常明显。如果要查询5月2号分区的数据，SQL也非常容易写：Select * from table where begin_date=2011-05-02;重复存储是最大的浪费，极限存储方案就是为了解决因为重复存储造成存储空间浪费的问题的。极限存储的适用场景：针对很大很大的表业务上不允许删除历史快照信息。表的数据变化较小（表数据肯定是有变化的，但是表的数据相对比较稳定，不变的数据较多），如用户表，商品表，成交表，订单表等等等等。极限存储的一个总体思想就是通过给表记录设定生命周期的方式，减少重复存储的那些记录。所以当满足以上场景的情况下，表越大，极限存储带来的效果越是明显。
