欢迎来到探索 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 2022
 write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resets
   clat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04
    lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10
   clat 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=207
  iops        : min=  726, max= 1106, avg=968.37, stdev=86.19, samples=207
 lat (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.64
   sync 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），因为它的性能较慢，延迟更高且更不稳定，并且可能成为单点故障。

总结

本文对 Milvus 存储系统进行了深入探索，并全面介绍了 Milvus 存储架构和组件，展现了这些存储组件在支持大规模数据管理和分析中的作用。此外，本文还详细分析了 Milvus 的三个主要存储组件——元数据存储、对象存储和消息存储系统，并提供了评估和优化 Milvus 存储性能的最佳实践。