首字节时间和流媒体

就在不久之前，您在家中接收的唯一流媒体是使用机顶盒 (STB) 通过有线服务或通过天线通过无线方式接收的。大多数人没有意识到的是，它们的工作原理相同：内容不断流式传输，天线调谐到空中频率，而机顶盒通过同轴电缆调谐到频率。

然后互联网赶上了——现在大部分内容都是通过互联网流式传输的。虽然流媒体内容消耗的互联网流量的确切百分比因报告而异，但他们都同意两件事：流媒体内容占互联网流量的大部分，并且该百分比逐年增加。

什么是首字节时间 (TTFB) 以及为什么它对 Internet 视频很重要？

与无线或有线流媒体不断向被授权接收内容的设备广播不同，在互联网视频的情况下，用户的设备需要对内容提出请求，并且只有在握手和授权完成后，视频会开始播放吗？

Time to first byte 是视频流的第一个字节在用户设备上可用所需的时间。用更实际的术语来说，这是某人在流媒体视频上点击播放和视频真正开始播放所花费的时间。

在没有竞争的情况下，用户更愿意等待 10-15 秒，以便内容开始通过 Internet 流式传输。现在新鲜感已经消退，市场竞争激烈，延迟超过几秒钟（甚至任何延迟）可能意味着保留和失去客户之间的区别。

服务器端面临的挑战

流媒体提供商面临多项重大挑战。虽然边缘缓存和 CDN 通过缓存一些更常见的内容来改善用户体验，但这仍然不是所有内容，并且仍然存在从源服务器获取内容的问题。

他们还必须处理多种不同的用例：长期驻留的视频点播 (VOD) 资产（例如电影、节目等）、短期驻留的 VOD 资产（例如现场体育赛事的剪辑等）和 DVR 资产（用户决定“存储”的视频）。

传统的 SAN 和 NAS 解决方案非常适合数据库、共享文件等事务性数据，但不适用于流媒体内容。在提供规模和高可用性所需的协议和多层软件之间，它们是流数据的错误选择。

由于许多对象存储是根据供应商的文件系统架构改编的（与真正的对象存储方法相比），它们需要外部元数据数据库。由于本文中详述的多种原因，这是有问题的。其中之一是它消除了严格一致性的可能性，因为对象和元数据是分开编写的，导致系统容易出现数据损坏。

由于额外的查找调用开销以及需要分别扩展对象存储和元数据存储，因此单独的元数据存储也会导致巨大的性能和可伸缩性问题。

内容寻址存储 (CAS) 和遗留对象存储专为归档/二级存储用例而设计。这些类型存储的突出示例使用 Cassandra 作为它们的元数据存储，这会损害性能和一致性。我们过去曾写过这方面的文章。

当资产变动很大时（即，经常添加和删除视频），可扩展性问题变得更加严重。

MinIO - 数据的最短路径

在 MinIO，我们从头开始构建我们的对象存储来解决这些问题。

让我们回顾一下为确保应用程序具有到达它们尝试访问的数据的最短路径而做出的架构决策。

走走组装

MinIO 被编写为单进程轻量级绿色线程（也称为 Goroutines），专为大规模并发操作而设计。

SIMD 优化

现代 CPU 的功能足以消除对外部加速器或定制 ASIC 的需求。现代 CPU 最重要的特性之一是它们能够执行所谓的单指令多数据 (SIMD) 指令。MinIO 利用了Intel、AMD、ARM 和 PowerPC CPU 中的这些功能。

结果是，通常是 CPU 密集型的操作（如纠删码、加密、校验和验证等）现在变得快速且免费。不需要外部加速器，例如 GPU，因为瓶颈不再在计算层，而是依赖于 I/O 子系统（网络、驱动和系统总线）。

不是传统文件系统的网关

MinIO 是专门为对象存储而构建的。它不仅仅是 SAN 或 NAS 等标准文件系统的网关或 API 代理。

最重要的是，MinIO 使用直接附加存储，即连接到计算机的驱动器。访问视频资产不需要额外的网络或软件层。本地 PCIe 总线比任何对驱动器的网络访问都要快。

简单的

MinIO 软件堆栈中没有不必要的或额外的软件层。

具有本机 S3 API 接口的微服务架构只是一个带有处理程序的 Web 服务器。这种简单性适用于强大且高性能的平台。

没有外部元数据存储的严格一致性

如前所述，外部元数据存储是高性能和可扩展对象存储的最大瓶颈之一。

MinIO 与对象和元数据都严格一致，因为它们是作为单个操作一起写入的。不仅保证在返回 200 OK 时写入对象和元数据，而且不再存在单独元数据存储的瓶颈。

使用对象写入元数据消除了资产高流失率导致的任何潜在问题，其中大量删除会给元数据存储带来巨大挑战。

MinIO 以压缩的 msgpack 格式写入元数据，以减少存储空间并提高检索速度。

没有全局锁

创建真正的分布式系统最具挑战性的部分之一是几乎所有系统都需要全局锁。

MinIO 通过确保锁是细粒度的并且在每个对象级别完全消除了对全局锁的需求。这样，对一个对象的操作不会影响任何其他对象。我们的版本控制机制确保没有资源争用，因此不需要全局锁。

直接输入输出

内核缓存会对延迟和内存管理造成巨大影响。MinIO 绕过内核缓存来优化流性能以及弹性和持久性。

纠删码

可大规模实现低 TTFB 的最终 MinIO 设计模式是纠删码。连同节点的无状态性质，这不仅以合理的成本提供了对驱动器和节点故障的高容忍度，而且由于元数据是用对象的每个分片写入的，因此可以从任何驱动器中高效地获取整个对象.

流式工作负载的优化

上一节详细介绍了 MinIO 对于需要对象存储的任何工作负载的优势。MinIO 还专门针对流式工作负载进行了优化。

原生流媒体协议

HTTP(S) 专为直接流式传输给最终用户而设计。MinIO 原生支持 S3 接口和 HTTP 协议，非常适合流式视频。

分段上传

视频通常是大文件。MinIO 允许将这些视频文件分解成一组可以上传的部分。由于能够并行上传部分，这极大地提高了吞吐量。此外，较小的部分允许从网络问题中快速恢复，能够随着时间的推移暂停和恢复部分的上传，等等。

流式范围获取

为了获得对视频流的细粒度控制 - 例如，从视频中的特定点继续或提供剪辑 - 重要的是整个对象不需要首先加载到内存中然后让对该对象执行的操作。这种低效率会大大增加 TTFB 和使用的内存量。MinIO 支持范围获取，其中部分对象可作为流使用。应用程序能够提供对象的偏移量、所需长度甚至特定版本。

流媒体块支持

为了确保在流式传输时可以有效地读取对象，MinIO 在每个块而不是简单地在对象级别添加校验和。这消除了在开始流式传输之前加载整个对象的需要。这也显着降低了内存利用率，因为不必将整个对象加载到内存中。

校验和也是使用 Highway Hash 算法计算的，该算法比更常用的 CRC32 方法效率更高。更重要的是，CRC32 容易发生哈希冲突，因此在防止静默数据损坏方面不够可靠。MinIO 对 Highway Hash 进行了优化，以在保持哈希强度的同时实现接近内存速度的哈希。

作为擦除编码机制的一部分，对象分片被确定性地放置。这允许读取并行性，这在 RAID 或 NAS 设置中是不可能的。同样，由于每个分片都有完整的元数据，它可以获取整个对象。

基准测试结果

我们进行了一系列测试，以展示流式工作负载的性能一致性。

测试配置

测试是在 8 节点集群上完成的。请注意，这些是较旧的系统，NVMe 驱动器的额定顺序读取速度仅为 2GB/s 左右。较新的 NVMe 驱动器显示在 PCIe 3.0 上的 3.5GB/s 到 PCIe 4.0 上的 8GB/s 之间。PCIe 5.0 为 12 GB/s，但目前价格过高。这意味着数字只会变得更好。

每个节点包括：

• 内存：384GB

• 网络：100Gbps

• 10 个 1TB NVMe 驱动器

结果 #1：即使在高并发率下，TTFB 也非常低

我们运行的第一个测试测量了高并发率对 TTFB 的影响。选择 1 MB 的对象大小是因为流媒体提供商使用它来实现更好的 CDN 缓存。

第 75 个和第 90 个百分位数的结果以毫秒为单位：

MinIO 在并发负载下提供极其一致的性能。在 4000 个并发请求时，第 75 个百分位数的 TTFB 保持在 0.5 秒以下。

结果 #2：偏移读取的 TTFB 与给定并发的对象大小无关

该测试评估从不同大小的物体的不同偏移量读取的效果。此处使用较大的文件来确保搜索值足够高以具有重要意义。

第 75 个和第 90 个百分位数的结果以毫秒为单位：

结果表明，对于固定的并发性，偏移读取的 TTFB 在对象大小之间是一致的。

结果 #3：偏移读取的 TTFB 对于给定的并发性是一致的

下一个测试测量了从具有不同增加的并发性的对象中的不同偏移读取的效果。这里也使用了更大的文件来确保搜索值足够高以具有重要意义。

第 75 个和第 90 个百分位数的结果以毫秒为单位：

结果表明，对于给定的并发性，TTFB 独立于从中读取的对象中的偏移量。

不要只相信我们的话 - 自己进行基准测试。

由于大多数互联网流量都是流式传输，TTFB 已成为衡量性能的重要指标。众所周知，缓慢的 TTFB 会降低客户体验并导致大量客户流失。正如这篇博文所展示的，无论大小、偏移量和并发性如何，从 MinIO 提供的对象都享有较低的 TTFB。

来和我们谈谈 (sales@minio.org.cn ) 或下载 MinIO并亲自尝试。你会发现为什么世界上一些最大的流媒体公司在 MinIO 上标准化他们的基础设施。