1、背景

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

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

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

2、向量搜索與milvus

2.1 向量搜索

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

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

2.2 milvus

milvus(主要針對2.0以上版本)是一款元原生向量數(shù)據(jù)庫，支持向量的插入，ANNS搜索等。Milvus能夠很好地應(yīng)對海量向量數(shù)據(jù)，它集成了目前在向量相似性計算領(lǐng)域比較知名的幾個開源庫（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ù)集細分為很多channel，在數(shù)據(jù)寫入與查詢時，對應(yīng)與msg borker中的通道的概念。
• partion：partion把數(shù)據(jù)集進行了一層劃分，常見的partion，比如：日期，按照日期分類存儲數(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é)果，對該工具進行了改造。

具體一個segment在etcd中所有的信息：

、

3.2 milvus架構(gòu)圖

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

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

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

• 系統(tǒng)門面：

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

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

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

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

4.1 milvus向量寫入路徑

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

3.2 milvus向量搜索路徑

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

• Proxy收到向量搜索(ANNS)請求后，會把請求丟給shard leader query node。
• Leader querynode 會依據(jù)每個segments的分布，把ANNS請求分發(fā)給每個Query Node。Query Node內(nèi)部會基于最小搜索單位Segment，cpu核數(shù)等去做并行查詢，并做結(jié)果reduce。
• Proxy收到所有的請求后，會對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始終壓不上去，仔細排查發(fā)現(xiàn)查詢節(jié)點的cpu使用率上不去，導(dǎo)致qps也上不去。

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

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

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

擴容查詢節(jié)點后，短時間內(nèi)segments沒有自動均衡(懷疑，跟進中)

現(xiàn)象描述：

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

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

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

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

• 當前進度：

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

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

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

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

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

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

比如以下是使用兩個 32核 16G:

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

不要通過deployment擴容縮容，盡量通過helm去操作

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

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

6、總結(jié)

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

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