标签：
一直以来，所看到的企业存储产品里，当有dedup和compression俩兄弟时，都是dedup在先，compession随后。似乎自然而然，然而这样的顺序是必须的么？是最佳的吗？
这会是个问题吗？
简单来看，假设处理的block(segment, ...) 都是基于定长:
1. compression是CPU密集，on the wire, 不需额外的查找，通常输入的size不能太小 以利于发现pattern 提高效率。compression容易通过ASIC做提速，事实上IBM, HP等很多都有
2. dedup要复杂很多，以online为例，需要计算(depends， 通常比compression CPU消耗少；多个hash另外一回事), 需要额外fg 查找和更新，甚至中间会有IO(cache miss，byte比对)。block越大 metadata越少 但dedup效率越差；block越小，粒度越细 则dedup效果可能越好，但metadata就越多，内存吃紧。offline的dedup
以XtremIO为例，block定长。它第一代产品就带来inline dedup，压缩是后来才补上的，这和它的架构密切相关: content-based addressing，write-NVRAM和内部两次fw。进来算了hash之后，根据hash要做一次partiton，交给某个node, 如果先compression(说实话，未尝不可)，进来的节点就得承受compression + hash，然和才能balance到其他节点，这会影响其global balance；不过可能好处是压缩后保存-mirror，cache消耗可能会低些。
实际工程中，影响顺序非常关键的因素是: 1）block size选择以及变化对工程量的影响，2）workload自身是可dedup和可压缩性。
1.dedup后，unique block的size是不变的，8KB/16KB, ...这对定长block的FS/LUN(多数如此)更友好，而压缩后size则是变化且未定的，处理起来就有些额外的工作，你最好buffer-split一下，最后可能还是会浪费些磁盘
2. 高重复率的数据先dedup，总能迅速减少数据量；反之高压缩比的 同样道理。可惜，实际过程中，这个重要信息往往不得而知。
然而，最近看到一家反其道而为之，压缩在前，dedup在后。为什么？怎么样呢？
Tegile 全闪存
这家公司2010年左右成立，最早做混合阵列(2012，T3100-T3400)，直到2014年刚刚推出全闪存 （T3600，T3800）,产品和能力在短短1年时间即进入Gartner-Visionarie远见象限，确实不易。所有系统都采用ZFS平台，是少有的支持Block和FS的全闪，其dedup/compression做的比较有特色: per pool, per LUN/FS, block size from 4KB ~ 128KB (fixed once set)
最近其官方博客发布了些测试和对比，摘要重点如下。
1. 从最终data reduction效果来看，定长情况下，给定数据量，则无论哪个在前 哪个在后，最终效果是一样且确定的. --意思是说，客户们放心，没蒙你 咱家的效果不差
2. 从reduction效率(CPU, 时间)来看，它的测试表明，通常都是先压缩效率占优，仅当数据是非常高dedup率且几乎没有压缩性时 先dedup才有些优势。--so 更多的workload 比如数据库等等还是乖乖的服从我的方法，先压缩一把。
CF – Compress First
HF – Hashing First
c – cost of compression per unit
h – cost of hashing per unit
X is put as 1000 units, sha256 for h, LZ4 for c. The number is time to process those units. The lower， the better
CF: X*c + Y*h [4760 ns]
HF: X*h + X*c [4760 ns]
Case Verdict: CF and HF are equal
CF: X*c + X/2*h [2940 ns]
HF: X*h + X*c [4760 ns]
Case Verdict: CF is better
CF: X*c + X/2*h [2940 ns]
HF: X*h + X/2*c [4200 ns]
Case Verdict: CF is better
CF: X*c + X*h [4760 ns]
HF: X*h + X/2*c [4200 ns]
Case Verdict: HF is better
CF: X*c + X*h [4760 ns]
HF: X*h + X/5*c [3864 ns]
Case Verdict: HF is better
CF: X*c + 3X/4*h [3850 ns]
HF: X*h + X/5*c [3864 ns]
Case Verdict: CF is better
CF: X*c + X/2*h [2940 ns]
HF: X*h + X/5*c [3864 ns]
Case Verdict: CF is better
CF: X*c + X/4*h [2030 ns]
HF: X*h + X/5*c [3864 ns]
Case Verdict: CF is better
这可能可以提供一个思路，至少说明有人这么做了，效果可以，但具体你该用哪种，必须结合你的总体架构，应用场景，workload等。如果自己都不了解自己的情况，别人就谁也都帮不上了。
标签：
原文地址：http://www.cnblogs.com/zhaojp/p/4615092.html
