众所周知，由于编码和解码操作， 纠删编码增加了额外的复杂性。 由于这个缺点，大多数云服务build议使用热数据的数据复制和擦除冷数据的编码。
例如，从Ceph文档：
擦除编码池压碎规则集针对的是用于冷存储的硬件，具有高延迟和较慢的访问时间。 复制缓冲池规则集旨在提供更快的硬件，以提供更好的响应时间。
热数据的定义比“比其他数据更容易访问的数据”更好吗？
让我们考虑一个依靠擦除编码的存储系统和一个运行在其上的应用程序，这个应用程序由I / O密集型工作负载来定义。 它被视为热门数据吗？
现在，我怎么能说我的存储系统的擦除代码是否可行？ 测量某些特定testing（即随机/顺序读取/写入）的应用程序IOPS是否相关？
是否存在一个阈值，说删除代码不适用于热数据，因为我只logging（例如）100个IOPS应用程序端用于4 kB块的随机写入操作？ 如果我logging一千亿IOPS呢？
IOPS是否与这种testing相关（也许其他度量会说更多）？
我对这个问题充满疑问，任何帮助都会感激不尽。
为了使热数据的擦除可行，你必须考虑擦除编码，该擦除编码在与文件系统（通常为4K）所使用的数据块大小相匹配的数据块大小上工作正常。 但是，这还不够，我们还要考虑文件系统的体系结构，尤其是它可能对元数据（可能每个块被存储的服务器的位置等）可能产生的影响。
所以为了构build一个使用擦除编码的文件系统，我们必须考虑围绕擦除编码构build文件系统，而不是仅仅在现有文件系统中添加擦除编码。
擦除编码的一个共同的缺点是关于CPU时间，基于Reed-Solomon的大部分实现都是在较大的块大小上进行的，以弥补吞吐量问题。 出于这个原因，他们中的大多数只是将其归档。
但是，还有一些替代方法可以在小数据块（4K）上工作。 在我们的横向扩展NAS产品（RozoFS）中，我们使用其他的擦除编码algorithm（对于里德 – 所罗门（Reed solomon）的情况，使用几何对比代数algorithm），其优点是可以在小数据块大小上提供快速编码/解码（超过10 GB /在Intel I7 @ 2GHz上）。
与在文件系统范围内以块大小操作的事实相关联的编码/解码速度允许避免在写入随机请求上额外读取的惩罚。 顺便说一句，我们可以解决实时数据的情况，特别是小数据块大小的随机I / O的情况。
在你的performance方面，我们有一个网站是有趣的，我们发布了基准，我们做了Iozone（顺序和随机访问testing）。 （rozofs.com – 博客部分））。