Milvus在流式數(shù)據(jù)場景下的性能表現(xiàn)是什么

本篇文章給大家分享的是有關(guān)Milvus在流式數(shù)據(jù)場景下的性能表現(xiàn)是什么，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

Milvus 作為一款開源的特征向量相似度搜索引擎，其開源半年以來，在全球已經(jīng)有數(shù)百家企業(yè)或組織用戶。這些用戶涉及各個領域，包括金融、互聯(lián)網(wǎng)、電商、生物制藥等。在部分用戶的生產(chǎn)場景中，其數(shù)據(jù)大多是持續(xù)地、動態(tài)地生成，且要求這些動態(tài)生成的數(shù)據(jù)入庫后能很快被檢索到。

大數(shù)據(jù)處理可分為批式大數(shù)據(jù)（又稱為“歷史大數(shù)據(jù)”）處理和流式大數(shù)據(jù)（又稱為“實時大數(shù)據(jù)”）處理兩類。在大多數(shù)情況下，流數(shù)據(jù)在處理持續(xù)生成的動態(tài)新數(shù)據(jù)方面具有顯著優(yōu)勢。流數(shù)據(jù)是指由多個數(shù)據(jù)源持續(xù)生成的數(shù)據(jù)，通常同時以較小規(guī)模的數(shù)據(jù)記錄的形式發(fā)送，約幾千字節(jié)。流數(shù)據(jù)可為各種形式的數(shù)據(jù)，例如網(wǎng)購數(shù)據(jù)、社交網(wǎng)站信息、地理空間服務，以及通過遙感器測控得到的數(shù)據(jù)。

| Milvus 應用

在用戶需求的驅(qū)動下， Milvus 不斷增加其功能，探索更多的應用場景。Milvus 動態(tài)數(shù)據(jù)管理策略，使得用戶可以隨時對數(shù)據(jù)進行插入、刪除、搜索、更新等操作，無需受到靜態(tài)數(shù)據(jù)帶來的困擾。在插入或更新數(shù)據(jù)之后，幾乎可以立刻對插入或更新過的數(shù)據(jù)進行檢索， Milvus 能夠保證搜索結(jié)果的準確率和數(shù)據(jù)一致性。同時在源源不斷的數(shù)據(jù)導入過程中， Milvus 依然能夠保持優(yōu)秀的檢索性能。由于這些特性， Milvus 可以很好地適用于流式大數(shù)據(jù)的場景。

在很多用戶場景中，結(jié)合了批式大數(shù)據(jù)和流式大數(shù)據(jù)兩種處理方式，從而構(gòu)建一種混合模式，來同時維持實時處理和批處理。比如在推薦系統(tǒng)的實現(xiàn)中，無論是文章、音樂、視頻等推薦或者是電商平臺的商品推薦，都存在許多歷史數(shù)據(jù)。平臺給用戶做推薦時，部分歷史數(shù)據(jù)依舊有被推薦的價值，因此這些歷史數(shù)據(jù)需要經(jīng)過去重、過濾等處理然后存入 Milvus 中。除了歷史保留的數(shù)據(jù)，在推薦系統(tǒng)中每天還會產(chǎn)生新的數(shù)據(jù)，包括新的文章、熱點以及新的商品等，這些數(shù)據(jù)也要及時的導入庫中并且要求能夠很快被檢索到，這些持續(xù)產(chǎn)生的數(shù)據(jù)就是流式數(shù)據(jù)。

隨著越來越多的用戶有動態(tài)插入數(shù)據(jù)、實時檢索的需求，本文將介紹一下基于 Kafka 實現(xiàn)的 Milvus 在流式數(shù)據(jù)場景下的參數(shù)配置和檢索的性能。

| 場景模擬

Kafka 是一個開源的流處理平臺，這里將介紹基于 Kafka 實現(xiàn)的 Milvus 在流式數(shù)據(jù)下的兩個應用示例。

示例一

該系統(tǒng)中使用 Kafka 接收各個客戶端產(chǎn)生的數(shù)據(jù)來模擬生成的流式數(shù)據(jù)。當 Kafka 消息隊列中有數(shù)據(jù)時，數(shù)據(jù)接收端持續(xù)從 Kafka 隊列中讀取數(shù)據(jù)并立即插入 Milvus 中。 Milvus 中插入向量的數(shù)據(jù)量是可大可小的，用戶可一次插入十條向量，也可一次插入數(shù)十萬條向量。該示例適用于數(shù)據(jù)實時性要求較高的場景。全過程如圖所示：

配置：

• index_file_size : 在 Milvus 中，數(shù)據(jù)是分文件存儲的，每個數(shù)據(jù)文件大小在建立集合的時候由參數(shù) index_file_size 值來定義。數(shù)據(jù)寫入磁盤后，成為原始數(shù)據(jù)文件，保存的是向量的原始數(shù)據(jù)，每當原始數(shù)據(jù)文件大小達到 index_file_size 值后，便會觸發(fā)建立索引，索引建立完成后會生成一個索引數(shù)據(jù)文件。

  Milvus 進行檢索時，將在索引文件中去檢索。對于未建立索引的數(shù)據(jù)，將會在原始數(shù)據(jù)文件中檢索。由于未建立索引的部分，檢索會比較慢，因此 index_file_size 不宜設置得過大，本示例中該值設置為 512。（若 index_file_size 過大，會使得未建立索引的數(shù)據(jù)文件較大，降低檢索性能。）

• nlist : 該值表示 Milvus 建立索引后，每個數(shù)據(jù)文件里的向量被分為多少個“簇”。本示例中將該值設置為 1024。

  
  

• Milvus 在不斷插入數(shù)據(jù)的過程中，會不停的建立索引。為了保證檢索的效率，這里選擇了用 GPU 資源建立索引，用 CPU 資源進行檢索。
  

性能：

本示例中，在持續(xù)導入數(shù)據(jù)之前，向集合中插入了一億條 128 維的向量，并建立 IVF_SQ8 索引，來模擬歷史數(shù)據(jù)。此后持續(xù)的向該集合中隨機的間隔 1-8 秒插入 250-350 條向量。隨后進行多次檢索，檢索性能如下：

在上述性能記錄中，第一次檢索時間指的是每次有新增數(shù)據(jù)導入后的檢索時間，第二次檢索時間是在第一次檢索后沒有新的數(shù)據(jù)導入前的檢索時間。

橫向比較，發(fā)現(xiàn)第一次檢索時間大于第二次，是因為第一次檢索時會將新導入的數(shù)據(jù)從磁盤加載到內(nèi)存。

縱向比較來看，在數(shù)據(jù)持續(xù)導入過程中，第一次檢索耗時持續(xù)增長。這是因為在持續(xù)導入數(shù)據(jù)的過程中，新增數(shù)據(jù)文件會和之前未建立索引的數(shù)據(jù)文件合并，檢索時會將新合并的數(shù)據(jù)文件從磁盤加載到內(nèi)存。隨著導入數(shù)據(jù)的增多，合并好的這個新文件會越來越大，從磁盤加載到內(nèi)存的耗時也將增加。其次，導入的這部分數(shù)據(jù)都未建立索引，隨著未建立索引的數(shù)據(jù)增多，在這部分數(shù)據(jù)中檢索的時間也會逐步增加。第二次檢索耗時也越來越長，但其耗時增長幅度相較于第一次較小。是因為第二次檢索沒有將數(shù)據(jù)從磁盤加載到內(nèi)存的過程，耗時增長只是因為未建立索引的數(shù)據(jù)越來越多。數(shù)據(jù)在導入到約 100 萬條的時候（每個數(shù)據(jù)文件是 512 MB , 向量 128 維，所以每個數(shù)據(jù)文件約 100 萬條向量），觸發(fā)了建索引的閾值。當索引建立完成，檢索時均是在索引文件中進行檢索的，所以這個時候的第二次檢索時間又回到動態(tài)導入數(shù)據(jù)前的性能。

在本示例持續(xù)導入數(shù)據(jù)的過程中（累計導入約 100 萬），每隔 5 秒采樣查詢一次，并記錄其查詢時間。整個過程查詢性能趨勢如下圖所示，縱坐標表示查詢耗時，橫坐標表示整個查詢過程的時刻，以秒為單位。

在這個折線圖中，大部分點（圖中處于上方的這些點）對應上述表格中的第一次檢索時間。從圖可以看出，導入數(shù)據(jù)后的第一次檢索時間有較大幅度上升的趨勢。少數(shù)點（圖中處于下方的這些點）對應上述表格中的第二次檢索時間，第二次檢索時間有一個稍微上升的趨勢。在該示例中，因為數(shù)據(jù)頻繁導入，所以檢索時更多的是在有新數(shù)據(jù)導入后去檢索的情況。從上述圖中還可以看到，當導入數(shù)據(jù)總量達到建索引的閾值時，建立完索引之后的查詢時間又恢復到動態(tài)導入數(shù)據(jù)之前的水平。

同時經(jīng)測試，新插入的數(shù)據(jù)，在一兩秒后即能被檢索到。

示例二

該系統(tǒng)中使用 Kafka 接收各個客戶端產(chǎn)生的數(shù)據(jù)來模擬生成的流式數(shù)據(jù)，當 Kafka 隊列中有數(shù)據(jù)到達時，讀取 Kafka 中的數(shù)據(jù)，當數(shù)據(jù)積累到一定量（本示例中為 10 萬）的時候，批量插入 Milvus 中，這樣能夠減少插入次數(shù)，提高整體檢索性能。該示例適用于對數(shù)據(jù)實時性要求不那么高的場景。該過程流程如圖：

配置：該示例的配置同示例一。

性能：在導入新的數(shù)據(jù)之前，查詢耗時約 0.027 秒。在后續(xù)導入過程中，每次批量插入 10 萬條數(shù)據(jù)。數(shù)據(jù)導入過程中，數(shù)據(jù)導入后的第一次檢索時間以及第二次檢索時間和示例一的表中顯示時間差不多。由于沒有頻繁的數(shù)據(jù)導入操作，所以在檢索時，大多數(shù)時候的檢索時間都對應上述表中的第二次檢索時間。

在本示例持續(xù)批量導入數(shù)據(jù)的過程中（累計導入約 100 萬），每隔 5 秒采樣查詢一次，并記錄其查詢時間。整個過程查詢性能趨勢如下圖所示，縱坐標表示查詢耗時，橫坐標表示整個查詢過程的時刻，以秒為單位。

在該該折線圖中可以看到，由于插入頻率降低，所以大多數(shù)檢索時對應示例一表格中的第二次檢索時間。只有在每次導入十萬數(shù)據(jù)后，檢索耗時相對較長。同樣的，在建完索引之后，查詢時間也恢復到導入數(shù)據(jù)之前的水平。

從上述兩個示例的性能表現(xiàn)折線圖來看，在有頻繁的檢索操作，同時對新增數(shù)據(jù)的實時性要求不高的情況，累計批量數(shù)據(jù)插入是更優(yōu)的選擇。

| 結(jié)語

以上就是Milvus在流式數(shù)據(jù)場景下的性能表現(xiàn)是什么，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。