Milvus探究与压测分析

　　通过压测，我们发现某场景下存在milvus的性能提升不上去的问题，并给出基于该场景的解决方案，社区反馈给milvus官方。以下为milvus的设计与压测中遇到的一些问题与解决或跟进方案。

　　1、背景

　　最近用到了向量搜索，所以要对milvus进行压测。同时为了更加深入分析压测中遇到的问题，也对milvus的部分源码与文档进行了走读。其中遇到了一些问题与疑惑，我们也直接与milvus社区或开源贡献者沟通。

　　通过压测，我们发现某场景下存在milvus的性能提升不上去的问题，并给出基于该场景的解决方案，社区反馈给milvus官方。

　　以下为milvus的设计与压测中遇到的一些问题与解决或跟进方案。

　　2、向量搜索与milvus

　　2.1 向量搜索

　　向量搜索简称ANNS，英文全名：Approximate Nearest Neighbor Search 。大致概念是从一堆向量中找出与某个目标向量距离最近的N个向量。最简单粗暴的搜索方式是暴力搜索，但是可以通过扩增索引的方式加快搜索速度，提升大规模查询的QPS。

　　当前的向量索引可以分为四大类：基于树的索引、基于图的索引、基于哈希的索引、基于量化的索引。其中图思路由于较高的召回率、较好的性能和较多的后期优化思路，脱颖而出。

　　2.2 milvus

　　milvus(主要针对2.0以上版本)是一款元原生向量数据库，支持向量的插入，ANNS搜索等。Milvus能够很好地应对海量向量数据，它集成了目前在向量相似性计算领域比较知名的几个开源库(Faiss， SPTAG等)，通过对数据和硬件算力的合理调度，以获得最优的搜索性能。

　　3、milvus架构介绍

　　3.1 milvus的数据集概念

　　数据集概念：

• 　　collection: 数据集，类似于mysql的表。
• 　　channel：基于主键把数据集细分为很多channel，在数据写入与查询时，对应与msg borker中的通道的概念。
• 　　partion：partion把数据集进行了一层划分，常见的partion，比如：日期，按照日期分类存储数据。partion与channel是正交的关系。
• 　　segment：milvus数据集的最小单位，具体的索引都是基于segment去构建的。查询的最小单位也是segment。

　　官网给出数据集读取写入例子：https://milvus.io/docs/v2.1.x/example_code.md

　　数据集查询工具：https://github.com/milvus-io/birdwatcher

　　以下利用birdwatcher展示collection与segment信息：

　　以上输出结果，对该工具进行了改造。

　　具体一个segment在etcd中所有的信息：

　　3.2 milvus架构图

　　milvus官网给出的架构图如下：

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

　　简单介绍下以上各个微服务的功能：

• 　　系统门面：
• 　　Proxy：所有SDK查询都会经过proxy，proxy会把写数据投递到message borker中对应不同的channel，proxy会处理三类数据：写请求,读请求,控制类请求。
• 　　系统协调者：
• 　　RootCoord：类似于传统master角色 主要做一些DDL，DCL的管理，比如：创建Collection，删除Collection，或对于partion做管理。此外还有一个更大的责任，rootCoord给系统分配全局唯一时间戳。
• 　　写数据：
• 　　DataCoord：协调者，分配，管理segment，管理dataNode，处理dataNode的故障恢复等。
• 　　DataNode：消费来自数据流的数据，进行数据序列化，负责把log数据转成log snapshot，刷新到磁盘中。
• 　　索引创建：
• 　　IndexCoord：对sealed SegMent创建索引，管理indexNode。
• 　　IndexNode：负责具体的索引创建事宜。
• 　　查询：
• 　　QueryCoord：数据查询管理，负责管理QueryNode。
• 　　QueryNode：负责具体的数据查询事宜。
• 　　元信息与元数据存储：
• 　　MetaStore：metastore使用ETCD存储。主要负责元信息与元数据的存储。比如：表结构，Segment结构，全局时间戳等。
• 　　写数据消息投递：
• 　　Log Borker：Log broker采用了pulsar。最新的2.0及以上版本中，写入的数据都是先写入Log Broker，然后DataNode从Log Broker中读取。
• 　　数据与索引存储：
• 　　Object Store：Object store当前采用了minio，主要用来存储数据，索引等。

　　　以上可以看出微服务比较多，微服务之间的通信方式主要有以下几种：

　   4、milvus向量写入与读取链路

　　4.1 milvus向量写入路径

• 　　proxy通过produce把数据写入到Message borker的物理channel中。
• 　　DataNode作为消费者消费数据。
• 　　DataNode定期把消费数据存到Object store中。
• 　　DataNode会定期通知dataCoord记录数据元信息。

　　3.2 milvus向量搜索路径

　　以下当前最新版本2.1.4的读流程 ，与网上的读流程版本链路不同，应该是做了改造。

• 　　Proxy收到向量搜索(ANNS)请求后，会把请求丢给shard leader query node。
• 　　Leader querynode 会依据每个segments的分布，把ANNS请求分发给每个Query Node。Query Node内部会基于最小搜索单位Segment，cpu核数等去做并行查询，并做结果reduce。
• 　　Proxy收到所有的请求后，会对search结果做reduce，并返回给客户端。

　　5、milvus压测中的问题分析

　　压测版本：milvus-2.1.4

　　数据维度：512dim

　　索引：

　　5.1 压测结果

向量个数	索引	规格	QPS	99%耗时
十万*512dim	FLAT	2*(8cpu*16Gi)	880	82ms
十万*512dim	FLAT	2*(16cpu*16Gi)	1489	62ms
百万*512dim	FLAT	2*(16cpu*16Gi)	240	200ms
千万*512dim	FLAT	2*(16CPU*32Gi)	20	1.98s

　　5.2 压测中遇到的问题与分析

　　QPS与CPU使用率压不上去，CPU很难超过50%。(已经优化)

　　现象描述：

　　压测过程中，发现QPS始终压不上去，仔细排查发现查询节点的cpu使用率上不去，导致qps也上不去。

• 　　解决方案：

　　初步怀疑是查询节点调度问题，经过各种排查，发现与一个调度参数scheduler.cpuRation高度相关。以下是该参数在不同值的QPS情况。

规格	scheduler.cpuRation	qps
2*(8cpu*16Gi)	20	385
2*(8cpu*16Gi)	100	768
2*(8cpu*16Gi)	120	913
2*(8cpu*16Gi)	140	880

　　该参数主要用来评估一个search task的cpu使用情况，该参数越高，预示该task使用cpu越多，调度的时候，多个task去查询的并行数量就会少一些。现在怀疑并行task太多，并不会达到很高的QPS。

　　milvus并没有公开该参数配置，已经通过issue/enhancement提给milvus社区中了，后续版本应该会有所优化。

　　扩容查询节点后，短时间内segments没有自动均衡(怀疑，跟进中)

　　现象描述：

• 　　比如当前线上有两个查询节点，50个segments均分在两个nodes上。压测中多次发现如果增加一个node后，segments并不会自动均衡到新的node上。
• 　　当前进度：

　　整个压测过程中做了三次写入，有两次没有自动均衡，最后一次自动均衡了。

　　跟milvus社区维护人员咨询过该问题，他们认为理论上扩增是会自动均衡的。这与我们测出的结果不匹配，后续会继续跟进，找到问题所在。

　　持续大规模写了很久后，会导致大量growing segment，导致查询性能下降(跟进中)。

• 　　现象描述：

　　多个线程，持续大规模插入向量数据后，通过日志排查，发现部分部分查询节点上的segment一直处于growing状态，虽然这些segment在写入节点已经sealed了，但是某个查询节点并不会自动重新加载这些sealed segments，而是一直认为这些节点处于growing状态。

　　由于growing 状态的segment查询时不用索引，而是暴力搜索，这样会导致查询变的比较慢，需要手动操作release。

• 　　当前进度：

　　跟milvus社区维护人员咨询过该问题，后续还要持续跟进，找出原因并改进。

　　版本升级后，原有数据不兼容(已有方案)。

　　版本升级后，原有数据不兼容(已有方案)。

• 　　现象描述：

　　milvus版本由2.1.4升级到最新版后，原有数据没办法加载，且启动不了。回退版本后，发现数据元信息已经被写坏了，没法加载。

• 　　解决方案：

　　后续稳定后，谨慎做版本升级，或升级前做好充分调研。另外官方给出的建议是升级前先merge数据。

　　千万级别数据，压测QPS不能达到预期(跟进中)

• 　　现象描述：

　　当数据插入千万级别后，发现压测提升QPS比较难，99%耗时下降也比较快，即使通过提升cpu核的个数，提升也不是很明显。

　　比如以下是使用两个 32核 16G:

• 　　解决方案：

　　这个可能跟我们使用FLAT索引有关，后续会尝试新的索引方式压测。

　　不要通过deployment扩容缩容，尽量通过helm去操作

• 　　现象描述：

　　当通过deployment扩容后，因为参数不能统一修改的问题，做不到平滑扩容，比如扩容后可能需要重新release与load数据，造成短时间中断。

　　所以官网也给出建议尽量通过helm去平滑扩容。

　　6、总结

　　经过压测，milvus是可以满足我们当前业务场景的。以上压测中的一些遗留问题，我们还在跟进中，比如：大量growing segment问题，节点扩增等问题。这些问题并不是100%出现的，有些是在我们极端测试条件下才出现的。后续我们还会持续测试，定位原因，并反馈给社区进一步优化。以上压测的索引采用的是FLAT，官方建议我们采用图索引可以取得更高性能。由于我们当前的业务场景要用到FLAT索引，所以当前先基于FLAT索引去压测。后续会用到图索引，也会进行压测。

　　通过对milvus的压测，顺便了解并学习下milvus的设计。总体来说milvus是一款优秀的云原生向量数据库，它的一些设计理念还是比较先进的，把向量搜索与k8s结合在一起，通过简单的查询节点扩增便可以线性提升向量搜索的性能。对于一款分布式数据库，它实现了读写分离，存算分离。官网给出的文档也比较丰富，工具也比较多，比如：attu，birdwatcher等。

　　来源： 得物技术

  　　>>>>>>点击进入云计算专题