探索 Milvus 存储系统：如何评估和优化 Milvus 存储性能

欢迎来到探索 Milvus 系列。Milvus 是一款支持水平扩展和具备出色性能的开源向量数据库。Milvus 的核心是其强大的存储系统，是数据持久化和存储的关键基础。该系统包括几个关键组成部分：元数据存储（meta storage）、消息存储（log broker）和对象存储（object storage）。

本文将深入探讨 Milvus 架构，分析其核心存储组件，并介绍如何有效评估 Milvus 存储系统性能。

Milvus 架构

Milvus 采用了分布式架构，确保了存储和计算的分离，并支持水平扩展计算节点。Milvus 架构主要分为四层：接入层（Access Layer）、协调服务（Coordinator Service）、执行节点（Worker Node）和存储服务（Storage）。每一层都可以独立扩展并针对灾难恢复进行了优化。

接入层：作为系统的主要用户接口，由无状态代理组成，处理用户请求并优化响应。
协调服务：作为系统中央协调服务，管理任务分配、集群拓扑、负载均衡和跨工作节点的数据管理。
执行节点：作为执行者，负责完成协调服务下发的指令和 proxy 发起的数据操作语言（DML）命令。
存储服务：对数据持久性至关重要，负责 Milvus 数据的持久化，分为元数据存储（meta store）、消息存储（log broker）和对象存储（object storage）三个部分。

Milvus 存储组件

Milvus 使用以下三个主要的存储组件来确保数据的完整性和可用性。

元数据存储

负责存储元信息的快照，比如 collection schema 信息、节点状态信息、消息消费的 checkpoint 等。鉴于对高可用性、强一致性和事务支持的需求，Milvus 利用 etcd 作为其元存储解决方案。etcd 是一个健壮且分布式的键值存储，对 Milvus 内部的分布式系统至关重要。同时它还处理服务注册和健康检查以及元数据保存等任务。

对象存储

负责存储日志的快照文件、标量/向量索引文件以及查询的中间处理结果。Milvus 采用 MinIO 作为对象存储，另外也支持 AWS S3 和Azure Blob 这两大最广泛使用的低成本存储。但是由于对象存储访问延迟较高，且需要按照查询计费，因此 Milvus 未来计划支持基于内存或 SSD 的缓存池，通过冷热分离的方式提升性能以降低成本。

消息存储

消息存储是一套支持回放的发布订阅系统，用于持久化流式写入的数据，以及可靠的异步执行查询、事件通知和结果返回。执行节点宕机恢复时，通过回放消息存储保证增量数据的完整性。目前分布式 Milvus 依赖 Pulsar 作为消息存储，Milvus standalone 依赖 RocksDB 作为消息存储。消息存储也可以替换为 Kafka 等流式存储。

如何评估和优化 Milvus 存储的性能

持续评估和改进存储性能至关重要。

Etcd：Milvus 的元数据存储

Etcd 是为分布式系统设计的分布式键值存储。在 Milvus 中，etcd 用作元数据存储，存储诸如collection schema 信息、节点状态信息、消息消费的 checkpoint 等关键数据。

磁盘写入延迟对于 etcd 的性能至关重要；速度较慢的磁盘可能会显著增加请求延迟并危及系统稳定性。我们推荐在生产环境中至少保持 500+ IOPS（每秒输入/输出操作）以获得最佳性能，确保 99% 的 fdatasync 持续时间在十毫秒以下。虽然 etcd 通常只需适度的磁盘带宽，但增加带宽可以显著减少恢复时间。因此，我们推荐生产环境的最低磁盘带宽至少为 100MB/s。

为了验证您的存储解决方案是否满足这些标准，可以考虑使用 Fio 进行性能评估，Fio 是一种磁盘性能测试工具。

首先，请确保您的系统上安装了 Fio。然后，运行以下命令，指定挂载存储的目录作为测试数据目录。这个目录应该位于您的存储连接点之下。

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

查看结果，确保 99% 的 fdatasync 持续时间少于 10 毫秒，且写入 IOPS 高于 500。如果满足这些条件，则代表存储性能良好。

以下为输出结果示例：

Jobs: 1 (f=1): [W(1)][100.0%][w=1771KiB/s][w=788 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=703: Mon Jul 25 08:36:48 2022write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resetsclat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10clat percentiles (usec):|  1.00th=[    3],  5.00th=[    4], 10.00th=[    4], 20.00th=[    5],| 30.00th=[    6], 40.00th=[    9], 50.00th=[  233], 60.00th=[  343],| 70.00th=[  437], 80.00th=[  553], 90.00th=[  701], 95.00th=[  742],| 99.00th=[ 1172], 99.50th=[ 2114], 99.90th=[ 6390], 99.95th=[ 8455],| 99.99th=[15533]bw (  KiB/s): min= 1630, max= 2484, per=100.00%, avg=2174.66, stdev=193.65, samples=207iops        : min=  726, max= 1106, avg=968.37, stdev=86.19, samples=207lat (usec)   : 2=0.03%, 4=16.49%, 10=27.68%, 20=3.21%, 50=0.71%lat (usec)   : 100=0.27%, 250=2.65%, 500=24.64%, 750=20.40%, 1000=2.57%lat (msec)   : 2=0.82%, 4=0.30%, 10=0.18%, 20=0.03%, 50=0.01%fsync/fdatasync/sync_file_range:sync (usec): min=309, max=21848, avg=741.93, stdev=489.64sync percentiles (usec):|  1.00th=[  392],  5.00th=[  437], 10.00th=[  474], 20.00th=[  529],| 30.00th=[  578], 40.00th=[  619], 50.00th=[  660], 60.00th=[  709],| 70.00th=[  742], 80.00th=[  791], 90.00th=[  988], 95.00th=[ 1369],| 99.00th=[ 2442], 99.50th=[ 3523], 99.90th=[ 6915], 99.95th=[ 8586],| 99.99th=[11994]

在云环境中部署 Milvus 集群时，由于 etcd 对磁盘性能的敏感性，选择适合的块存储类型至关重要。云服务提供商提供了各种块存储选项，每种都具备独特性能特征，适用于不同的工作场景。

以下是在各个云提供商推荐的使用的卷类型和性能指标。

云服务提供商	卷类型	规格	IOPS	P99 sync
AWS	gp3	20Gi	660	4.3ms
GCP	pd-ssd	20Gi	1262	1.3ms
Azure	PremiumV2	20Gi	705	2.6ms
阿里云	cloud_essd	20Gi	1137	3.5ms

您还可以使用 Fio 来确认所选的块存储是否满足 etcd 在 Milvus 部署中正常运行所需的性能基准。

MinIO：Milvus 对象存储工具

MinIO 是一种高性能、Kubernetes 原生的对象存储解决方案，专门针对云原生任务进行了优化。Milvus 使用 MinIO 来存储日志的快照文件、标量/向量索引文件以及查询的中间处理结果。

像 MinIO 这样的对象存储的性能主要通过 I/O 吞吐量而不是 IOPS 来衡量。这个指标显著影响 Milvus 中的各种操作，如加载 Collection、构建索引和插入数据。许多因素影响 MinIO 的吞吐性能，包括网络带宽、Linux 内核性能调优以及单个磁盘驱动器的性能。其中，磁盘性能尤为关键。

我们可以使用 dd 命令来测量单个驱动器的性能。DD 是一个 Unix 工具，它按位从一个文件复制数据到另一个文件，并提供了各种选项来控制每次读写的块大小。

在下面的示例中，当使用 16MB 块大小测试单个 NVMe 驱动器时， O_DIRECT 选项 count=64，每个驱动器写入性能超过每秒 2GB。

$ dd if=/dev/zero of=/mnt/drive/test bs=16M count=64 oflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.443096 s, 2.4 GB/s

在同一示例中，当使用 16MB 块大小测试单个 NVMe 驱动器时，O_DIRECT 选项 count=64，每个驱动器读取性能超过每秒 5GB。

$ dd of=/dev/null if=/mnt/drive/test bs=16M count=64 iflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.187263 s, 5.7 GB/s

磁盘驱动器的读写性能越高，MinIO 的整体吞吐性能越好。我们建议在 MinIO 设置中使用 SSD 或 NVMe 类型的驱动器作为存储磁盘，以获得最佳性能。这些驱动器可以有效支持 MinIO 操作的高吞吐量要求。请避免使用 SAN/NAS 设备作为 MinIO 存储，因为此类存储方式通常会引入并发问题和性能瓶颈，可能会降低系统的效率和响应性。

Pulsar/Kafka：Milvus 消息存储工具

如上所述，Milvus 根据特定的部署模式使用不同的日志代理工具。Milvus 分布式版使用 Pulsar 或 Kafka，而 Milvus Standalone 版本通常使用 RocksDB。

Pulsar 和 Kafka 都用于支持持久性消息存储，并为消息消费提供高吞吐量。它们的性能严重依赖于所使用的磁盘存储类型，因为它们依赖于磁盘 I/O 操作。

对于 Pulsar，高性能磁盘对于保证 BookKeeper 的日志文件的数据完整性和持久性至关重要。Pulsar Ledgers 和 Kafka 都针对磁盘效率进行了优化，利用文件系统缓存，并且在 HDD 和 SSD 上表现良好。然而，对于追求低延时的应用或大规模部署，SSD 有着显著的性能优势。

为了优化性能，应为 Pulsar 和 Kafka 使用多个磁盘设备。特别是对于 Pulsar，使用单独的磁盘存储日志可以将写操作的延迟与读操作隔离开来。为了确保最佳的延迟，不要使用相同的驱动器存储数据、应用程序日志或其他操作系统的活动。这些驱动器可以使用 RAID 配置为单个卷，或者每个驱动器可以格式化并挂载为自己的目录。应避免使用共享存储（SAN/NAS），因为它的性能较慢，延迟更高且更不稳定，并且可能成为单点故障。