1、背景

最近用到了向量搜索，所以要對milvus進(jìn)行壓測。同時(shí)為了更加深入分析壓測中遇到的問題，也對milvus的部分源碼與文檔進(jìn)行了走讀。其中遇到了一些問題與疑惑，我們也直接與milvus社區(qū)或開源貢獻(xiàn)者溝通。

通過壓測，我們發(fā)現(xiàn)某場景下存在milvus的性能提升不上去的問題，并給出基于該場景的解決方案，社區(qū)反饋給milvus官方。

以下為milvus的設(shè)計(jì)與壓測中遇到的一些問題與解決或跟進(jìn)方案。

2、向量搜索與milvus

2.1 向量搜索

向量搜索簡稱ANNS，英文全名：Approximate Nearest Neighbor Search 。大致概念是從一堆向量中找出與某個(gè)目標(biāo)向量距離最近的N個(gè)向量。最簡單粗暴的搜索方式是暴力搜索，但是可以通過擴(kuò)增索引的方式加快搜索速度，提升大規(guī)模查詢的QPS。

當(dāng)前的向量索引可以分為四大類：基于樹的索引、基于圖的索引、基于哈希的索引、基于量化的索引。其中圖思路由于較高的召回率、較好的性能和較多的后期優(yōu)化思路，脫穎而出。

2.2 milvus

milvus(主要針對2.0以上版本)是一款元原生向量數(shù)據(jù)庫，支持向量的插入，ANNS搜索等。Milvus能夠很好地應(yīng)對海量向量數(shù)據(jù)，它集成了目前在向量相似性計(jì)算領(lǐng)域比較知名的幾個(gè)開源庫（Faiss， SPTAG等），通過對數(shù)據(jù)和硬件算力的合理調(diào)度，以獲得最優(yōu)的搜索性能。

官網(wǎng)：https://milvus.io/

3、milvus架構(gòu)介紹

3.1 milvus的數(shù)據(jù)集概念

數(shù)據(jù)集概念：

• collection: 數(shù)據(jù)集，類似于mysql的表。
• channel：基于主鍵把數(shù)據(jù)集細(xì)分為很多channel，在數(shù)據(jù)寫入與查詢時(shí)，對應(yīng)與msg borker中的通道的概念。
• partion：partion把數(shù)據(jù)集進(jìn)行了一層劃分，常見的partion，比如：日期，按照日期分類存儲(chǔ)數(shù)據(jù)。partion與channel是正交的關(guān)系。
• segment：milvus數(shù)據(jù)集的最小單位，具體的索引都是基于segment去構(gòu)建的。查詢的最小單位也是segment。

官網(wǎng)給出數(shù)據(jù)集讀取寫入例子：https://milvus.io/docs/v2.1.x/example_code.md

數(shù)據(jù)集查詢工具：https://github.com/milvus-io/birdwatcher

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

以上輸出結(jié)果，對該工具進(jìn)行了改造。

具體一個(gè)segment在etcd中所有的信息：

、

3.2 milvus架構(gòu)圖

milvus官網(wǎng)給出的架構(gòu)圖如下：

按照分組又可以分為以下幾大類別：

簡單介紹下以上各個(gè)微服務(wù)的功能：

• 系統(tǒng)門面：

• Proxy：所有SDK查詢都會(huì)經(jīng)過proxy，proxy會(huì)把寫數(shù)據(jù)投遞到message borker中對應(yīng)不同的channel，proxy會(huì)處理三類數(shù)據(jù)：寫請求,讀請求,控制類請求。

• 系統(tǒng)協(xié)調(diào)者：
• RootCoord：類似于傳統(tǒng)master角色 主要做一些DDL，DCL的管理，比如：創(chuàng)建Collection，刪除Collection，或?qū)τ趐artion做管理。此外還有一個(gè)更大的責(zé)任，rootCoord給系統(tǒng)分配全局唯一時(shí)間戳。
  
• 寫數(shù)據(jù)：
  
• DataCoord：協(xié)調(diào)者，分配，管理segment，管理dataNode，處理dataNode的故障恢復(fù)等。
  
• DataNode：消費(fèi)來自數(shù)據(jù)流的數(shù)據(jù)，進(jìn)行數(shù)據(jù)序列化，負(fù)責(zé)把log數(shù)據(jù)轉(zhuǎn)成log snapshot，刷新到磁盤中。
  
• 索引創(chuàng)建：
  
• IndexCoord：對sealed SegMent創(chuàng)建索引，管理indexNode。
  
• IndexNode：負(fù)責(zé)具體的索引創(chuàng)建事宜。
  
• 查詢：
  
• QueryCoord：數(shù)據(jù)查詢管理，負(fù)責(zé)管理QueryNode。
  
• QueryNode：負(fù)責(zé)具體的數(shù)據(jù)查詢事宜。
  
• 元信息與元數(shù)據(jù)存儲(chǔ)：
  
• MetaStore：metastore使用ETCD存儲(chǔ)。主要負(fù)責(zé)元信息與元數(shù)據(jù)的存儲(chǔ)。比如：表結(jié)構(gòu)，Segment結(jié)構(gòu)，全局時(shí)間戳等。
  
• 寫數(shù)據(jù)消息投遞：
  
• Log Borker：Log broker采用了pulsar。最新的2.0及以上版本中，寫入的數(shù)據(jù)都是先寫入Log Broker，然后DataNode從Log Broker中讀取。
  
• 數(shù)據(jù)與索引存儲(chǔ)：
  
• Object Store：Object store當(dāng)前采用了minio，主要用來存儲(chǔ)數(shù)據(jù)，索引等。
  

以上可以看出微服務(wù)比較多，微服務(wù)之間的通信方式主要有以下幾種：

4、milvus向量寫入與讀取鏈路

4.1 milvus向量寫入路徑

• proxy通過produce把數(shù)據(jù)寫入到Message borker的物理channel中。
• DataNode作為消費(fèi)者消費(fèi)數(shù)據(jù)。
• DataNode定期把消費(fèi)數(shù)據(jù)存到Object store中。
• DataNode會(huì)定期通知dataCoord記錄數(shù)據(jù)元信息。

3.2 milvus向量搜索路徑

以下當(dāng)前最新版本2.1.4的讀流程 ，與網(wǎng)上的讀流程版本鏈路不同，應(yīng)該是做了改造。

• Proxy收到向量搜索(ANNS)請求后，會(huì)把請求丟給shard leader query node。
• Leader querynode 會(huì)依據(jù)每個(gè)segments的分布，把ANNS請求分發(fā)給每個(gè)Query Node。Query Node內(nèi)部會(huì)基于最小搜索單位Segment，cpu核數(shù)等去做并行查詢，并做結(jié)果reduce。
• Proxy收到所有的請求后，會(huì)對search結(jié)果做reduce，并返回給客戶端。

5、milvus壓測中的問題分析

壓測版本：milvus-2.1.4

數(shù)據(jù)維度：512dim

索引：

5.1 壓測結(jié)果

5.2  壓測中遇到的問題與分析

QPS與CPU使用率壓不上去，CPU很難超過50%。(已經(jīng)優(yōu)化)

現(xiàn)象描述：

壓測過程中，發(fā)現(xiàn)QPS始終壓不上去，仔細(xì)排查發(fā)現(xiàn)查詢節(jié)點(diǎn)的cpu使用率上不去，導(dǎo)致qps也上不去。

• 解決方案：
  初步懷疑是查詢節(jié)點(diǎn)調(diào)度問題，經(jīng)過各種排查，發(fā)現(xiàn)與一個(gè)調(diào)度參數(shù)scheduler.cpuRation高度相關(guān)。以下是該參數(shù)在不同值的QPS情況。

該參數(shù)主要用來評(píng)估一個(gè)search task的cpu使用情況，該參數(shù)越高，預(yù)示該task使用cpu越多，調(diào)度的時(shí)候，多個(gè)task去查詢的并行數(shù)量就會(huì)少一些。現(xiàn)在懷疑并行task太多，并不會(huì)達(dá)到很高的QPS。

milvus并沒有公開該參數(shù)配置，已經(jīng)通過issue/enhancement提給milvus社區(qū)中了，后續(xù)版本應(yīng)該會(huì)有所優(yōu)化。

擴(kuò)容查詢節(jié)點(diǎn)后，短時(shí)間內(nèi)segments沒有自動(dòng)均衡(懷疑，跟進(jìn)中)

現(xiàn)象描述：

• 比如當(dāng)前線上有兩個(gè)查詢節(jié)點(diǎn)，50個(gè)segments均分在兩個(gè)nodes上。壓測中多次發(fā)現(xiàn)如果增加一個(gè)node后，segments并不會(huì)自動(dòng)均衡到新的node上。

• 當(dāng)前進(jìn)度：
  整個(gè)壓測過程中做了三次寫入，有兩次沒有自動(dòng)均衡，最后一次自動(dòng)均衡了。
  跟milvus社區(qū)維護(hù)人員咨詢過該問題，他們認(rèn)為理論上擴(kuò)增是會(huì)自動(dòng)均衡的。這與我們測出的結(jié)果不匹配，后續(xù)會(huì)繼續(xù)跟進(jìn)，找到問題所在。

持續(xù)大規(guī)模寫了很久后，會(huì)導(dǎo)致大量growing segment，導(dǎo)致查詢性能下降(跟進(jìn)中)。

• 現(xiàn)象描述：
  多個(gè)線程，持續(xù)大規(guī)模插入向量數(shù)據(jù)后，通過日志排查，發(fā)現(xiàn)部分部分查詢節(jié)點(diǎn)上的segment一直處于growing狀態(tài)，雖然這些segment在寫入節(jié)點(diǎn)已經(jīng)sealed了，但是某個(gè)查詢節(jié)點(diǎn)并不會(huì)自動(dòng)重新加載這些sealed segments，而是一直認(rèn)為這些節(jié)點(diǎn)處于growing狀態(tài)。
  由于growing 狀態(tài)的segment查詢時(shí)不用索引，而是暴力搜索，這樣會(huì)導(dǎo)致查詢變的比較慢，需要手動(dòng)操作release。

• 當(dāng)前進(jìn)度：

跟milvus社區(qū)維護(hù)人員咨詢過該問題，后續(xù)還要持續(xù)跟進(jìn)，找出原因并改進(jìn)。

版本升級(jí)后，原有數(shù)據(jù)不兼容(已有方案)。

版本升級(jí)后，原有數(shù)據(jù)不兼容(已有方案)。

• 現(xiàn)象描述：
  milvus版本由2.1.4升級(jí)到最新版后，原有數(shù)據(jù)沒辦法加載，且啟動(dòng)不了?；赝税姹竞螅l(fā)現(xiàn)數(shù)據(jù)元信息已經(jīng)被寫壞了，沒法加載。
• 解決方案：
  后續(xù)穩(wěn)定后，謹(jǐn)慎做版本升級(jí)，或升級(jí)前做好充分調(diào)研。另外官方給出的建議是升級(jí)前先merge數(shù)據(jù)。

千萬級(jí)別數(shù)據(jù)，壓測QPS不能達(dá)到預(yù)期(跟進(jìn)中)

• 現(xiàn)象描述：
  當(dāng)數(shù)據(jù)插入千萬級(jí)別后，發(fā)現(xiàn)壓測提升QPS比較難，99%耗時(shí)下降也比較快，即使通過提升cpu核的個(gè)數(shù)，提升也不是很明顯。
  

比如以下是使用兩個(gè) 32核 16G:

• 解決方案：
  這個(gè)可能跟我們使用FLAT索引有關(guān)，后續(xù)會(huì)嘗試新的索引方式壓測。

不要通過deployment擴(kuò)容縮容，盡量通過helm去操作

• 現(xiàn)象描述：
  當(dāng)通過deployment擴(kuò)容后，因?yàn)閰?shù)不能統(tǒng)一修改的問題，做不到平滑擴(kuò)容，比如擴(kuò)容后可能需要重新release與load數(shù)據(jù)，造成短時(shí)間中斷。
  

所以官網(wǎng)也給出建議盡量通過helm去平滑擴(kuò)容。

6、總結(jié)

經(jīng)過壓測，milvus是可以滿足我們當(dāng)前業(yè)務(wù)場景的。以上壓測中的一些遺留問題，我們還在跟進(jìn)中，比如：大量growing segment問題，節(jié)點(diǎn)擴(kuò)增等問題。這些問題并不是100%出現(xiàn)的，有些是在我們極端測試條件下才出現(xiàn)的。后續(xù)我們還會(huì)持續(xù)測試，定位原因，并反饋給社區(qū)進(jìn)一步優(yōu)化。以上壓測的索引采用的是FLAT，官方建議我們采用圖索引可以取得更高性能。由于我們當(dāng)前的業(yè)務(wù)場景要用到FLAT索引，所以當(dāng)前先基于FLAT索引去壓測。后續(xù)會(huì)用到圖索引，也會(huì)進(jìn)行壓測。

通過對milvus的壓測，順便了解并學(xué)習(xí)下milvus的設(shè)計(jì)。總體來說milvus是一款優(yōu)秀的云原生向量數(shù)據(jù)庫，它的一些設(shè)計(jì)理念還是比較先進(jìn)的，把向量搜索與k8s結(jié)合在一起，通過簡單的查詢節(jié)點(diǎn)擴(kuò)增便可以線性提升向量搜索的性能。對于一款分布式數(shù)據(jù)庫，它實(shí)現(xiàn)了讀寫分離，存算分離。官網(wǎng)給出的文檔也比較豐富，工具也比較多，比如：attu，birdwatcher等。