以下为milvus的设计与压测中遇到的一些问题与解决或跟进方案。
向量搜索简称ANNS,英文全名:Approximate Nearest Neighbor Search 。大致概念是从一堆向量中找出与某个目标向量距离最近的N个向量。最简单粗暴的搜索方式是暴力搜索,但是可以通过扩增索引的方式加快搜索速度,提升大规模查询的QPS。
当前的向量索引可以分为四大类:基于树的索引、基于图的索引、基于哈希的索引、基于量化的索引。其中图思路由于较高的召回率、较好的性能和较多的后期优化思路,脱颖而出。
按照分组又可以分为以下几大类别:
简单介绍下以上各个微服务的功能:
系统门面:
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,主要用来存储数据,索引等。
以上可以看出微服务比较多,微服务之间的通信方式主要有以下几种:
proxy通过produce把数据写入到Message borker的物理channel中。
DataNode作为消费者消费数据。
DataNode定期把消费数据存到Object store中。
DataNode会定期通知dataCoord记录数据元信息。
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 |
解决方案:
初步怀疑是查询节点调度问题,经过各种排查,发现与一个调度参数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 |
当前进度:
整个压测过程中做了三次写入,有两次没有自动均衡,最后一次自动均衡了。
跟milvus社区维护人员咨询过该问题,他们认为理论上扩增是会自动均衡的。这与我们测出的结果不匹配,后续会继续跟进,找到问题所在。
现象描述:
多个线程,持续大规模插入向量数据后,通过日志排查,发现部分部分查询节点上的segment一直处于growing状态,虽然这些segment在写入节点已经sealed了,但是某个查询节点并不会自动重新加载这些sealed segments,而是一直认为这些节点处于growing状态。
由于growing 状态的segment查询时不用索引,而是暴力搜索,这样会导致查询变的比较慢,需要手动操作release。
当前进度:
现象描述:
milvus版本由2.1.4升级到最新版后,原有数据没办法加载,且启动不了。回退版本后,发现数据元信息已经被写坏了,没法加载。
解决方案:
后续稳定后,谨慎做版本升级,或升级前做好充分调研。另外官方给出的建议是升级前先merge数据。
现象描述:
当数据插入千万级别后,发现压测提升QPS比较难,99%耗时下降也比较快,即使通过提升cpu核的个数,提升也不是很明显。
解决方案:
这个可能跟我们使用FLAT索引有关,后续会尝试新的索引方式压测。
现象描述:
活动推荐
主题:
得物无线技术沙龙(第三期)
时间:
12月4日 14:00 - 18:00
报名方式:
更多详情,请点击「沙龙详情」