大数据时代下数据重删的考虑



大家周末愉快，今天我也是首次推送有偿阅读文章，虽然平时工作忙，但在下班后尽可能挤时间总结一些平时工作中遇到的技术来和大家分享，但是每次看到文章的阅读量，发现关注我的粉丝人数和阅读量相差太大，我的积极性和主动性每次都承受着打击，推送有偿阅读主要目的是想了解下，到底有多少忠实读者在默默关注支持我，另一方面通过投票也想大家反馈下自己关注的内容，以便我以后有针对性的进行文章内容调整。

因为最近跟数据重删压缩打交道比较多，所以今天的话题也是重删压缩。在备份、主存储及AFA存储中，重删压缩功能可以说是必选项，但是站在用户角度和存储厂商角度我们会面临这两个需要取舍的困窘。

站在用户角度，从理论上来说，删除重复数据是会减少数据的可靠性，特别是在备份场景中。备份的目的就是为了提高数据的可靠性，但重删之后，这些重复数据都不存在了。但有付出就有收获，我们获得了存储空间上的节省，可以写更多数据进来。同时，之前的重复数据不是一种有规划的重复，重复数据应该怎么分布，如何避免某一个磁盘、磁盘框、机柜损坏之后，数据还可以读出来等等都没有考虑。

为了提高数据可靠性，可以针对重复度较高的数据，采用写多份拷贝的形式来提高这些重复数据的可靠性，同时，也可以根据存储的布局和组网，将这些拷贝按照相应的规则分部到不同的故障域中，更进一步提高系统的可靠性。

针对存储厂商，重删特性垃圾回收都是一个非常头疼的问题，垃圾回收存在两种不同的方法，基于引用计数和全盘扫描。这两种方式都各有优缺点，例如引用计数要求数据块的引用计数一定正确，不能有任何的错误，特别是不能多减，不然会出现数据不一致。这就要求系统中必须实现要有保证强一致的方法，比如事务。全盘扫描虽然不用保证强一致性，但需要进行全盘的读取，所以性能上不会那么好。

在随机业务场景中，重删之后使得数据分布更散，并且容易导致下层的空间管理单元中出现空洞，如果空洞很多，则导致存储空间的利用率不高，所以一般都会涉及到数据空间的整理及搬移。如何搬移才能保证较好的分配效果，使得这些空洞能被最大可能性的利用起来，并且不对后续的读写性能带来较大的影响，是一件很有挑战性的工作。

传统的重删压缩功能实现都放在存储层、在存储软件栈中增加重删压缩模块的实现方式。这种实现方式一方面使得单个节点的实现变得更复杂，同时如果涉及到节点间的通信，将会把整个存储系统进一步复杂化，在超过数百个节点时，这种通信交互是不可想象的。

免费阅读就到此为止，关于重删压缩分类、不同场景的重删方法、不同厂商实现方法、云存储服务上的重删压缩等详细介绍，通过打赏后，我会各自推送到相应读者微信上，打赏金额可以不限，打赏的目的开篇已经说明，希望得到的大家支持、技术投票和建议，今后推出更好的文章。

温馨提示：

请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。