写点什么

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

作者:Zilliz
  • 2024-07-29
    上海
  • 本文字数:3747 字

    阅读完需:约 12 分钟

探索 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 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 对磁盘性能的敏感性,选择适合的块存储类型至关重要。云服务提供商提供了各种块存储选项,每种都具备独特性能特征,适用于不同的工作场景。

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

您还可以使用 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=direct64+0 records in64+0 records out1073741824 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=direct64+0 records in64+0 records out1073741824 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 存储性能的最佳实践。

发布于: 刚刚阅读数: 4
用户头像

Zilliz

关注

Data Infrastructure for AI Made Easy 2021-10-09 加入

还未添加个人简介

评论

发布
暂无评论
探索 Milvus 数据存储系统:如何评估和优化 Milvus 存储性能_人工智能_Zilliz_InfoQ写作社区