Milvus探究与压测分析 ｜ 得物技术
以下为milvus的设计与压测中遇到的一些问题与解决或跟进方案。
2.1 向量搜索
向量搜索简称ANNS，英文全名：Approximate Nearest Neighbor Search 。大致概念是从一堆向量中找出与某个目标向量距离最近的N个向量。最简单粗暴的搜索方式是暴力搜索，但是可以通过扩增索引的方式加快搜索速度，提升大规模查询的QPS。
当前的向量索引可以分为四大类：基于树的索引、基于图的索引、基于哈希的索引、基于量化的索引。其中图思路由于较高的召回率、较好的性能和较多的后期优化思路，脱颖而出。
2.2 milvus
3.1 milvus的数据集概念
collection: 数据集，类似于mysql的表。 channel：基于主键把数据集细分为很多channel，在数据写入与查询时，对应与msg borker中的通道的概念。 partion：partion把数据集进行了一层划分，常见的partion，比如：日期，按照日期分类存储数据。partion与channel是正交的关系。 segment：milvus数据集的最小单位，具体的索引都是基于segment去构建的。查询的最小单位也是segment。
3.2 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.1 milvus向量写入路径
proxy通过produce把数据写入到Message borker的物理channel中。
DataNode作为消费者消费数据。
DataNode定期把消费数据存到Object store中。
DataNode会定期通知dataCoord记录数据元信息。
3.2 milvus向量搜索路径
Proxy收到向量搜索(ANNS)请求后，会把请求丢给shard leader query node。 Leader querynode 会依据每个segments的分布，把ANNS请求分发给每个Query Node。Query Node内部会基于最小搜索单位Segment，cpu核数等去做并行查询，并做结果reduce。 Proxy收到所有的请求后，会对search结果做reduce，并返回给客户端。
向量个数 | 索引 | 规格 | 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 |
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 |
扩容查询节点后，短时间内segments没有自动均衡(怀疑，跟进中)
现象描述：
当前进度：
整个压测过程中做了三次写入，有两次没有自动均衡，最后一次自动均衡了。
跟milvus社区维护人员咨询过该问题，他们认为理论上扩增是会自动均衡的。这与我们测出的结果不匹配，后续会继续跟进，找到问题所在。
持续大规模写了很久后，会导致大量growing segment，导致查询性能下降(跟进中)。
现象描述：
多个线程，持续大规模插入向量数据后，通过日志排查，发现部分部分查询节点上的segment一直处于growing状态，虽然这些segment在写入节点已经sealed了，但是某个查询节点并不会自动重新加载这些sealed segments，而是一直认为这些节点处于growing状态。
由于growing 状态的segment查询时不用索引，而是暴力搜索，这样会导致查询变的比较慢，需要手动操作release。
当前进度：
版本升级后，原有数据不兼容(已有方案)。
现象描述：
milvus版本由2.1.4升级到最新版后，原有数据没办法加载，且启动不了。回退版本后，发现数据元信息已经被写坏了，没法加载。解决方案：
后续稳定后，谨慎做版本升级，或升级前做好充分调研。另外官方给出的建议是升级前先merge数据。
千万级别数据，压测QPS不能达到预期(跟进中)
现象描述：
当数据插入千万级别后，发现压测提升QPS比较难，99%耗时下降也比较快，即使通过提升cpu核的个数，提升也不是很明显。
解决方案：
这个可能跟我们使用FLAT索引有关，后续会尝试新的索引方式压测。
不要通过deployment扩容缩容，尽量通过helm去操作
现象描述：
当通过deployment扩容后，因为参数不能统一修改的问题，做不到平滑扩容，比如扩容后可能需要重新release与load数据，造成短时间中断。
活动推荐
主题：
得物无线技术沙龙（第三期）
时间：
12月4日 14:00 - 18:00
报名方式：
更多详情，请点击「沙龙详情」