众所周知擦除编码由于编码和解码操作增加了额外的复杂性。由于这个缺点，大多数云服务建议使用数据复制来热数据以及纠删码冷数据。
例如，来自 Ceph 文档：
纠删码池压缩规则集针对的是专为冷存储设计的硬件，具有高延迟和访问时间慢的特点。复制池压缩规则集针对的是速度更快的硬件，以提供更好的响应时间。
有没有比“比其他数据访问量更大的数据”更好的热数据定义？
让我们考虑一个依赖于擦除编码的存储系统和在其上运行的应用程序，该存储系统由密集的 I/O 工作负载定义。它被视为热数据吗？
现在，我如何判断我的存储系统的擦除代码是否可行？从应用程序端测量某些特定测试（即随机/顺序读/写）的 IOPS 是否相关？
是否存在一个阈值，表明纠删码不适用于热数据，因为我仅记录（例如）应用程序端 4 kB 块随机写入操作的 IOPS 为 100？如果我记录了一千亿 IOPS 会怎样？
IOPS 是否与这种测试相关（也许其他指标会说明更多）？
我对此有很多疑问，如能得到任何帮助我将非常感激。
答案1
为了使热数据能够进行擦除，您必须考虑一种能够在与文件系统使用的数据块大小相匹配的数据块上正常工作的擦除编码（通常为 4K）。然而这还不够，我们还必须考虑文件系统的架构，特别是它可能对元数据产生的潜在影响（通常是存储每个块的服务器在哪里，等等）。
因此，为了构建使用擦除编码的文件系统，我们必须考虑围绕擦除编码构建文件系统，而不是仅在现有文件系统中添加擦除编码。
纠删码的一个常见缺点是 CPU 时间，大多数基于 Reed-Solomon 的实现都是在大块大小上进行的，以弥补吞吐量问题。因此，大多数实现仅从归档角度考虑它。
但是，有一些替代方案可以使其在小数据块（4K）上工作。在我们的横向扩展 NAS 产品（RozoFS）中，我们使用另一种擦除编码算法（Reed solomon 的案例中是几何与代数算法），该算法的优势在于可以在小数据块大小上提供快速编码/解码（在英特尔 I7 @2GHz 上超过 10 GBytes/s）。
编码/解码速度与它在文件系统范围内的块大小上操作的事实相关，这可以避免在写入随机请求时额外读取的损失。顺便说一下，我们可以解决实时数据的情况，特别是小数据块大小上的随机 I/O 的情况。
如果您对性能方面的细节感兴趣，我们有一个网站，我们在该网站上发布了我们对 Iozone 进行的基准测试（顺序和随机访问测试）。（rozofs.com - 博客部分））。