向量搜索与Milvus性能测试分析

背景

在进行向量搜索性能测试的过程中，我们深入分析了Milvus，并与社区和开源贡献者进行了沟通。我们发现了一些性能问题，并提出了解决方案，同时得到了社区的反馈。

向量搜索与Milvus

2.1 向量搜索简介

向量搜索，即ANNS（Approximate Nearest Neighbor Search），是从大量向量中快速找出与目标向量距离最近的N个向量的过程。除了暴力搜索，还可以通过构建索引来加速搜索，提高查询性能。

2.2 Milvus概述

Milvus是一款云原生向量数据库，支持大规模向量数据的插入和ANNS搜索。它集成了多个知名的向量相似性计算库，如Faiss和SPTAG，通过优化数据和硬件资源的使用，实现高性能搜索。

Milvus架构解析

3.1 数据集概念

  • Collection：数据集，类似于数据库表。
  • Channel：基于主键细分数据集，类似于消息代理中的通道。
  • Partition：对数据集进行划分，如按日期分类。
  • Segment：Milvus数据集的最小单位，索引和查询的基本单元。

3.2 数据集操作工具

  • 官方文档提供了数据集的读取和写入示例：示例代码
  • 数据集查询工具：Birdwatcher 使用Birdwatcher展示Collection和Segment信息，并对其进行了改造，以展示etcd中的Segment信息。

3.3 Milvus架构图

Milvus的架构图详细展示了系统组件及其交互方式。具体架构图可参考Milvus官网。

结论

通过对Milvus的深入分析和性能测试，我们发现了一些性能瓶颈，并与社区合作提出了改进方案。Milvus作为一个高性能的向量数据库，在处理大规模向量数据方面具有明显优势。
图片

按照分组又可以分为以下几大类别：

图片

微服务架构简述

系统门面系统门面是用户与系统交互的入口，负责接收用户的请求并将其转发至相应的服务。

ProxyProxy 是 SDK 查询的必经之路，它将写数据投递到 Message Broker 中的不同 Channel。Proxy 处理的数据类型包括：

  • 写请求
  • 读请求
  • 控制类请求

系统协调者系统协调者负责协调各个微服务之间的工作，确保系统的稳定运行。

RootCoordRootCoord 扮演传统 master 角色，主要负责：

  • DDL 和 DCL 管理，例如创建或删除 Collection
  • 分区管理
  • 分配全局唯一时间戳

写数据

DataCoord作为协调者，DataCoord 负责：

  • 分配和管理 Segment
  • 管理 DataNode
  • 处理 DataNode 的故障恢复

DataNodeDataNode 负责：

  • 消费数据流
  • 数据序列化
  • 将日志数据转换为日志快照
  • 刷新数据到磁盘

索引创建

IndexCoordIndexCoord 负责：

  • 对 Sealed Segment 创建索引
  • 管理 IndexNode

IndexNodeIndexNode 负责具体的索引创建工作。

查询

QueryCoordQueryCoord 负责数据查询管理，主要任务是管理 QueryNode。

QueryNodeQueryNode 负责执行具体的数据查询任务。

元信息与元数据存储

MetaStoreMetaStore 使用 ETCD 存储，负责存储：

  • 元信息
  • 元数据例如表结构、Segment 结构、全局时间戳等。

写数据消息投递

Log BrokerLog Broker 使用 Pulsar，负责：

  • 接收写入的数据
  • DataNode 从 Log Broker 中读取数据

数据与索引存储

Object StoreObject Store 使用 Minio，主要用来存储：

  • 数据
  • 索引

微服务间通信方式微服务之间的通信方式多样，确保了系统的灵活性和扩展性。

图片

4

milvus向量写入与读取链路

4.1 milvus向量写入路径

**
图片

3.2 Milvus 向量搜索路径概述

1. 数据写入流程

  • 代理层操作：Proxy 通过 produce 方法将数据发送到 Message Broker 的物理通道中，实现数据的初步接入。

  • 数据节点角色：DataNode 作为消费者，负责从 Message Broker 中拉取数据进行处理。

2. 数据存储与元信息管理

  • 数据存储：DataNode 定期将处理后的数据存储到 Object Store 中，确保数据的持久化存储。

  • 元信息记录：DataNode 同时会定期向 DataCoord 发送通知，以便记录和管理数据的元信息。

3. 向量搜索流程

  • 数据索引：在 Milvus 中，数据首先需要被索引化，以便于后续的快速搜索。

  • 向量匹配：用户根据需求发起向量搜索请求，Milvus 根据索引进行向量匹配，找到最相似的向量。

  • 结果返回：匹配完成后，Milvus 将搜索结果返回给用户，完成整个搜索流程。

4. 系统优化与维护

  • 性能监控：系统需要定期监控性能，确保数据处理和搜索的效率。

  • 故障恢复：系统应具备故障检测和恢复机制，以应对可能的系统异常。

  • 扩展性考虑：随着数据量的增长，系统应支持水平扩展，以适应更大的数据处理需求。
    图片

Milvus 2.1.4 版本性能测试分析报告

1. 测试环境与配置

  • 版本: Milvus 2.1.4
  • 数据维度: 512维
  • 索引类型: FLAT

2. 性能测试结果以下是在不同数据规模和硬件配置下的查询性能测试结果：

| 向量个数 | 索引 | 规格 | QPS | 99%耗时 || ——–

  • | —
  • | —
  • | –
  • | ——-
  • || 十万512dim | FLAT | 2(8cpu16Gi) | 880 | 82ms || 十万512dim | FLAT | 2*(16cpu16Gi) | 1489 | 62ms || 百万512dim | FLAT | 2*(16cpu16Gi) | 240 | 200ms || 千万512dim | FLAT | 2*(16CPU*32Gi) | 20 | 1.98s |

3. 遇到的问题与解决方案

3.1 QPS与CPU使用率问题
  • 现象: 在压测过程中，QPS无法提升，CPU使用率难以超过50%。
  • 解决方案: 调整scheduler.cpuRation参数，发现其与QPS有直接关系。参数值越高，单个search task使用的CPU资源越多，导致并行任务数减少，影响QPS。 | 规格 | scheduler.cpuRation | QPS || ————
  • | ——————
  • | —-
  • || 2*(8cpu16Gi) | 20 | 385 || 2(8cpu16Gi) | 100 | 768 || 2(8cpu16Gi) | 120 | 913 || 2(8cpu*16Gi) | 140 | 880 |
3.2 Segments自动均衡问题
  • 现象: 扩容查询节点后，segments未自动均衡到新的节点。
  • 进度: 进行了三次写入操作，其中两次未自动均衡，一次自动均衡。正在与Milvus社区沟通，以确定问题原因。
3.3 Growing Segments问题
  • 现象: 持续大规模写入后，部分查询节点上的segment长时间处于growing状态，影响查询性能。
  • 当前状态: 需要手动操作release以解决growing segments问题。正在跟进此问题，以寻求自动解决方案。

4. 结论与建议

  • 结论: Milvus 2.1.4 版本在不同规模数据集和硬件配置下表现出不同的性能，其中scheduler.cpuRation参数对性能有显著影响。
  • 建议: 根据测试结果调整参数以优化性能，同时关注社区更新，解决自动均衡和growing segments的问题。

5. 后续计划

  • 继续与Milvus社区合作，跟进并解决发现的问题。
  • 定期进行性能测试，以评估社区更新对性能的影响。
    图片

版本升级与数据兼容性问题解决方案

1. 问题概述

在将Milvus版本从2.1.4升级到最新版本后，我们遇到了原有数据无法加载的问题，并且服务启动失败。在尝试回退版本后，发现数据元信息已经损坏，导致数据无法加载。

2. 解决方案

  • 谨慎升级：在后续稳定版本发布后，我们将更加谨慎地进行版本升级。

  • 充分调研：在升级前，将进行充分的市场调研和测试，以确保升级的可行性和安全性。

  • 数据备份：官方建议在升级前对数据进行合并备份，以防止数据丢失或损坏。

3. 现象描述

升级后，原有数据无法加载，服务启动失败，数据元信息损坏。

4. 后续行动

  • 持续跟进问题，与Milvus社区维护人员保持沟通，共同寻找问题的根本原因并制定改进措施。

千万级别数据的压测QPS问题

1. 现象描述当数据量达到千万级别时，我们发现提升查询每秒处理次数（QPS）变得困难。即使增加CPU核心数，性能提升也不明显，99%的响应时间也有所下降。

2. 测试环境

  • 使用了两个具有32核CPU和16GB内存的服务器进行压力测试。

3. 跟进状态目前，我们正在积极跟进此问题，探索可能的解决方案，以期达到预期的QPS性能。

图片

解决方案分析

我们发现使用FLAT索引可能影响性能，未来计划尝试其他索引方式以进行压力测试。

不建议使用Deployment进行扩容缩容

  • 原因：Deployment扩容可能导致参数不一致，需要重新release和load数据，这可能造成服务中断。

  • 建议：根据官网推荐，尽量使用Helm进行平滑扩容操作。

现象描述

在Deployment扩容后，由于参数无法统一修改，导致无法实现平滑扩容，可能会引起服务短时间中断。

压测总结

经过压测，Milvus能够满足我们当前的业务需求。但还有一些问题需要继续跟进，例如大量growing segment问题和节点扩增问题。这些问题并非总是出现，而是在极端测试条件下才会显现。我们将继续测试，定位问题原因，并与社区合作进行优化。

索引选择当前使用的是FLAT索引，但官方推荐使用图索引以获得更高性能。由于业务需求，我们先基于FLAT索引进行压测，未来将根据需要对图索引进行测试。

Milvus设计理念Milvus是一款先进的云原生向量数据库，其设计理念包括向量搜索与Kubernetes的结合，以及通过查询节点的扩增来线性提升性能。它实现了读写分离和存算分离，官网提供了丰富的文档和工具，例如attu和birdwatcher。

技术分享关注得物技术，每周一三五晚18:30更新技术干货。如果文章对你有帮助，欢迎评论、转发和点赞。

活动推荐得物无线技术沙龙（第三期）

  • 时间：12月4日 14:00
  • 18:00
  • 报名方式：点击沙龙详情获取更多信息。