重删在带来空间节省、IO效率提高的同时，有什么弊端？

重删是个好东西，我笔记本装了win10后都配了deduplication，配合ssd非常好。现在的缺陷就是性能有些损耗，毕竟要耗费资源去做重删这个工作。

如果是企业级产品，把重删集成到硬件存储里，效果非常不错。对主机端的性能没有影响。用过ibm的7650G和emc的dd670。去重率高的吓人，当然这也和备份系统使用，数据本来就重复的多相关。可能两家厂商在底层算法上各有千秋，但作为使用者，还真感觉不到啥差别，用户也不太在乎。

svc现在有RTC，实时数据压缩，可惜没实测过，用过的朋友的可以聊聊

由于每个供应商检查的数据块大小各不相同。一些供应商固定数据块的大小，一些则使用不同大小的块(有一些甚至允许终端用户改变固定块的大小，这会令人更加困惑)。固定块的大小可能为8 KB或64 KB，区别在于块越小，被判定为冗余的几率越大。这也就意味着消除的冗余更多，存储的数据更少。固定块只存在一个问题：如果文件发生变化，而重复数据删除产品依然利用上次检查到的固定块，那就可能无法监测冗余部分，因为文件中的数据块已被改变或移除，而利用的固定块仍是变化之前的，剩下的比较就没有意义了。

　　各种规模的块能够提高普通冗余的监测几率，尤其是在文件发生变化以后。这种方法能够监测文件中可能发生的实样模或断点，从而分割数据。即使文件变化，数据块被转移，这种方法也能发现重复的数据。不足之处呢？这种方法能改变块大小，需要供应商追踪并比较多个ID，因此会影响增大规模、增加计算时间。

重删近年来也是异常火爆的入门技术，其原理大多都是给数据切片，形成指纹，同样的指纹进行dedup，不一样的落盘，显然确实会节省空间，但是对于数据源的特性，去重比也是千差万别，在备份领域，一般像虚机，我们这边用DD4200，去重比高达10倍左右，而数据库应用去重比要低很多，这也合情合理。现在SVC貌似也在考虑融入去重的技术，我们可以关注一把。

    重删确实是一种比较实用的技术，而且效果也比较明显，像好多厂商宣传的10:1、8:1的重删比例，    但是在使用重删不当的情况下，也会严重影响性能和带宽：

    重删分为源端和目标端、在线和后处理等几种方式，针对备份大多是目标端的后处理方式，这样不会影响生产业务的性能，但是重删功能不仅是备份中使用，生产的数据中心也在使用，此时如果使用不当就会严重影响性能，例如重删可以基于块或是文件类型进行重删，针对块的重删，因为经过重删后，原有的数据被打散（原有的数据被非重复数据+重复数据的逻辑地址映射等关系），如果应用是多读多写类型的，很对读IO类型，这样就会带来性能影响，因为在读数据的时候，存储软件需要进行大量的数据拼接的结算，如果数据量非常大，这样就不太好了，

    所以，重删并不适合所有的应用，至少多读和大数据块以及文件类型的应用不太适合

重删最主要的是用时间换空间，备份领域在异地数据传输的时候，通过重删技术可以减少对高带宽的依赖，是比较好的解决方案。

删重是不错的，能够压缩空间节省存储资源。但是对性能上会造成影响。并且使用不当的话会对系统造成严重的性能问题。这个得结合业务和应用场景来看。比如对于热点数据就不建议使用删重，如果是归档历史数据就可以采用删重。这个都得根据场合来进行确认。

重删目前的缺陷就是性能有些损耗，如果是企业级存储产品，把重删集成到硬件存储里，效果还是不错的。

重删是个不错的技术，几年前这个技术应用起来还比较麻烦，因为要达到系统去重的目的，需要达到很多条件，而众多条件中有一条不满足，它就不会重删，所以当时看来很坑爹，不过现在经过这几年的改进，已经好很多了！而且在备份系统上浪费一些性能资源做重删还是可行的！

重删在备份领域的确是个非常不错的点，尤其是在对虚拟化平台上的备份，效果特别的明显，为用户节省了大量的备份存储空间。就是在性能上要考虑源端重删时对于源主机的性能影响。