Chat with Milvus (1) 問答實錄

時間 2021-01-04

標籤 git github 算法數據庫微信機器學習分佈式性能學習測試欄目 Git 简体版

原文原文鏈接

本週二咱們在線上與 Milvus 的朋友們進行了一場精彩的問答。咱們也爲不能參加的朋友們作了一個完整的文字實錄。以爲字數多看起來很累的朋友們能夠根據本身想了解的內容觀看影片回放。[影片請看這裏！]git

也想加入咱們的討論嗎？咱們會按期在每週二 8:00PM 舉辦這個活動，快與zilliz 小助手（微信：zilliz-tech）報名下週的活動，或是掃描 QR 碼直接報名！github

Q&A 影片/文字實錄

* 語音轉文字可能會有些許差別，實際內容以影音爲準算法

User 1: 你好，我目前也在作特徵檢索這個東西，我想了解一下：你剛剛說的有個特徵分析，而後大家近期會作一些混合查詢的功能。大家未來會支持標準的 SQL 嗎？數據庫

Milvus：標準的 SQL 這一塊，由於咱們如今在作 DSL 設計，因此咱們可能會先去支持像是 ElasticSearch 那樣的一種描述語言。SQL 這部分的話相對來講可能暫時會放在優先級比較低一點的順序。我不知道在您的場景下面你如今是怎麼作的呢？微信

User 1: 咱們的話也計劃作這個東西，但可能會考慮結合其餘有已有的數據庫譬如 PostgreSQL 這些東西來改一下。機器學習

Milvus：那您這邊的話也是作向量類似度搜索而後但願把它整合到一個關係型的數據庫裏是嗎？分佈式

User 1: 是的。性能

Milvus：這部分的話其實在阿里雲上他們有作這樣的一個嘗試，可是其實若是你仔細思考它向量數據背後的存儲的和邊緣計算的方式，和結構化數據的那種方式其仍是差別挺大的。學習

由於在整個傳統的結構化數據庫當中他比較精華的部分多是一個這種 B+ 樹的索引，而後基於 B+ 樹的索引怎麼去作這個 SQL 的優化器的訪問路徑的生成、優化，但在向量這部分其實都用不上，因此可複用的部分我感受是比較少的。測試

User 1: 由於目前 PG（PostgreSQL）不是出了一個相似類似性檢索的插件嘛，他們也就是爲了推廣 PG 作了一些相似於這樣的索引。

Milvus：以前有一個叫 PG-ANN 的項目可是如今這項目好像感受有點不怎麼活躍，當時作了時間也不長，因此這塊的探索確實會有一些挑戰。

User 1: 我看過我們的代碼，我們是否沒有用一些其餘的存儲引擎？

Milvus：是的，目前的話並無用。由於數據庫的存儲引擎其實仍是根據這種數據庫自己的形式去作的存儲引擎，像那些交易型的數據庫他多是按照頁來組織它的數據文件作的存儲引擎。還有像這種 KV 型的，那可能就是 KV 格式的。但向量其實會和他們的需求不太同樣，向量有點像 KV 但又不那麼像，由於咱們在索引的時候好比聚類的索引，有的IVF索引實際上是須要帶一些聚類的信息在裏面的。

因此這部分確實和目前已有的數據存儲引擎會有比較大的差別。因此這部分確實是咱們本身作的，可是底層承載這個數據文件的這部分，咱們接下來的版本是但願對接到S3的存儲當中。這樣的話數據文件放在 S3 的存儲上作高可用和分佈式都會比較容易一些。

User 1: 有沒有考慮過以後結合 HBase or HDFS 這樣的數據庫？

Milvus：HBase 的這塊暫時尚未想過，由於可能場景會太同樣。由於像 HBase 和 HDFS 的話它都是一個一個數據塊嘛，可是在一個向量檢索的場景下面，

其實咱們的文件你也能夠把它說是一個數據塊，可是咱們這個數據塊它實際上是會承載更多的信息的。首先他有聚類的信息，若是是 IVF 索引的話。而後呢，爲了這個 IO 的效率和檢索效率呢其實咱們也是但願這個數據塊可以儘量的大一點，那和 HDFS這部分考慮的因素可能就不太同樣。HDFS 可能就是爲一個文件分紅若干塊，而後每塊可能要128MB大小分佈在多個機器上面。那若是咱們的文件這樣分的話，在不少狀況下可能個人這個聚類信息都是在最初的那個塊上。

那不少狀況下我一個文件都是但願在一塊兒讀的，若是要去到不一樣的節點上讀的話，不一樣的節點載入不一樣的分片以後又沒有那個聚類的信息，那就會比較尷尬。

User 1: 咱們如今有一些業務場景，譬如除了類似檢索還有一些特徵聚類的業務還有一些其餘分類的業務。咱們的特徵已經存進去了，想把咱們本身的聚類、分類這樣的一些算子集成在這個項目（Milvus）裏頭，這個項目提供這些開放的接口嗎？

Milvus：是這樣的，就是說其實在咱們如今的現有的用戶端場景當中， Milvus 就是負責存向量特徵這部分的；用戶的應用和模型都是在上層本身去構建的，在目前這個階段。因此對於大家來說的話也是同樣的，你的算子也行你的應用也好都是在上層的，而後你把特徵存到 Milvus 當中而後作一個索引和搜索加速就能夠了。

User 1: 那目前只提供檢索這一個功能？

Milvus：您是但願（好比說你有100萬的向量）把這個向量建完索引後聚類的信息可以得到嗎？

User 1: 是的，這些聚類的信息好比果動態的一些聚類，好比天天入10萬的向量進去而後我就天天發就算是更新這樣的一些算子，基本上就是存儲，而後上面算子是一層也有檢索的算子還有分類的一些算子。

Milvus：我大概明白你的意思，可是它的實現是這個樣子：好比說原始的 FAISS 當中，假定你有10萬的數據先做預訓練，他會預訓練出一個大的分類，那麼你後續插入的數據那就是根據這個原來訓練出來的大的分類而後把這個數據放在那裏面。那麼，這種狀況你能夠說你是作了一個分類也好或是聚類也好，可是在咱們的這種向量搜索引擎，由於提供向量就更進一步的向量數據管理的狀況下，實際上是這個樣子：就說你這邊假定有了100萬條個向量過來，那可能這100萬假定他們放在了同一個文件裏面，那這100萬條向量，他在這個文件裏面他就是造成了一個好比說 IVF 的這個分類的結果。

明天你又來了100萬條向量，它可能也在一個文件裏面，那個文件又是單獨的。另外一個就是這個索引會訓練另外一套分類的結果，因此其實你不斷的有新的東西進來，它們會新建新的索引文件，當它達到預值以後。因此在這種狀況下，若是說你要去把它作聚類或分類的話，那你就須要在這個東西上面一層（業務層）你須要有個大的整體的分類指導的一個件，好比說就這個東西過來它和最初的，譬如說你有100個分類，那和最初的100個分類去比較它和哪一個最近。因此這個會有點不太同樣。由於咱們把流式更新進來的數據分紅了若干個文件，而後每一個文件的聚類信息都不同，因此回給你的東西可能就不會是一個統一的一個東西。目前 Milvus 的定位就是一個比較基礎的爲 AI 服務的一個向量搜索引擎。

User 1: 在後期沒有考慮集成更多的機器學習的算子？譬如 SVM，邏輯迴歸等。

Milvus：這一部分的話目前尚未計劃放在裏面。咱們如今目前在作的一些集成有像是一些新的 ANN 算法。譬如，咱們本來沒有 HNSW 或是 ANNOY，咱們後續會把他們集成進去。

User 1: Milvus 有的現有的應用場景？

Milvus：深度學習方面，好比說這種安防類的智慧城市、智慧零售，也有這種互聯網的一些作SaaS平臺的，作這種智能海報生成，它會有不少基礎的圖片的元素而後根據用戶需求去搜索圖片庫，造成一個個性化的海報。還有一部分是作這個推薦系統的，就是給用戶推薦一些視頻、短視頻這些場景，還有一部分是天然語言處理方向。由於像你們如今可能比較多的用了這種 Bert 的模型，生成的也是這種高維的向量。在咱們 Milvus 的網站上面咱們還有一個化合物分子分析的 demo，那部分它不是一個 AI 的模型，它是一個基於規則的模型轉換成一個特徵向量，而後呢咱們用這種計算谷本類似度。

User 2: 您剛纔這邊說大家的這個索引固件是文件分塊以後從新訓練碼本，這樣的話會不會存在說這個碼本不統一？

Milvus：是的，由於每一個分片他都是從新訓練的分類，因此其實每一個文件當中的分類信息都不同，那其實這樣作呢它固然由於從新訓練它會有必定的代價。固然若是 GPU 的話會很快。它的一個好處在於說他後續進來的數據分佈若是和原來不同的話其實不會形成太大的影響，由於像好比說我用20%的數據訓練出來一個分類的話，那其實後續的數據可能和先前訓練的數據的分佈狀況不同，那就可能會出如今某一個聚類當中的數據特別多，那你索搜某些地方的時候時間的響應就會不太均衡。

像咱們如今這種模式的好處就是，後進來的數據反正它也都是從新訓練的，因此當我去索搜固定空間大小的時候，它的響應時間相對來講是比較一致的。

User 2: 個人想法是咱們要不要就是採用這個分佈式的結構而後對全局的數據加碼本，這樣的話碼本是統一的，還有一個就是使用數據分部監控的方式會不會對精度會更好一些？

Milvus：先回答以前的第一個問題：若是假定我有兩個節點，在兩節點上共享這個碼本，但其實仍是沒辦法解決以前講到的那個問題。就是你訓練的集合你真實進來的, 它可能分佈上是不同的。它可能會出現一些分類的不均，形成性能波動，這個其實問題沒法避免。另一種狀況是像 Facebook 當中他作的那個用 FAISS 當集羣的時候他是把，好比說他分200個類好了，他弄個20臺機器，2 臺一組，那每一組他去 host 200個類中的10%，好比20個類就在那個機器上面，那你新來的數據呢他根據你的所屬的類的去插入到具體的某一組機器上面。

那其實這個也是同樣的問題，就是當你後來的係數據他分佈發生了比較顯着的變化的時候，那你可能就是在這10組機器有一些可能特別的忙，存的向量數據特別的多，仍是會形成問題。而後當在這種狀況下咱們若是對全局的全部的向量數據作一次從新的分類的訓練的話，其實代價會比較大。這個就有點像傳統數據庫表當中你老往裏面插數據，而後不停的刪數據以後你的索引就亂了，就必須作一些全局的索引的重建，而這個是會形成必定時間的向量搜索服務的不可用。

因此也是由於這個緣由，咱們如今考慮下來的這種模式也算是一種權衡吧。FAISS 在他們論文當中講的那種模式，可能就是20臺機器，兩臺一組，每組分一些分類（以及其餘方式）在理論上來說它可以提供很是好的查詢的性能，可是在實際實操的時候尤爲當你不斷數據進去的時候他的維護成本實際上是比較比較大的。

第2個問題：統一碼本的另外一個挑戰就像是傳統數據庫同樣的，須要有個實時的統計信息而後按期去查看，由於這些好比說聚類型的索引它最基礎的算法都是 K-means，那 K-means 的含義就是 K 個 means，但願均勻分紅 K 個類，因此就是若是是個統一碼本就須要不停的去監控這些東西，而後必定確保說當這個數據在不一樣類當中的這個分佈不均勻到必定程度的時候是須要去觸發從新建索引、從新計算全部分類的這個操做。因此其實就個是這種監控它會給用戶帶來一個更更加容易的一種方式去發現潛在的性能問題。可是當你重建整個分類的時候所形成的這種維護成本和不可用的時間其實仍是在那，只是當用戶是有意識的去觸發這個事情的時候，他能夠放在一個相對來講業務低谷的時候，那不可用形成的影響能夠降到比較小。

User 1: 如今這個系統的單機容量最大的多少？實測的單機容量

Milvus：是這樣的，就是在咱們本身的這個物理機上咱們實測的一個最大的數據集是來自於sift-1b，它是128維的數據10億條，那咱們測試的機器那是一個 512G內存的一個雙路的機器。可是經過咱們由於在 IVF 索引中能夠用一種 scalar quantization 轉 SQ8 索引，那它實際的內存消耗是在140G 左右。而後在咱們一些實際部署的一些用戶的產品下面由於他們是1024維的向量，基本上每一臺作個千萬上億級的也是沒有問題。就人臉的那種1024維的向量通常的這種512GB內存或256GB內存的機器支持到上億條是沒有問題。

User 3: 算子擴展怎麼支持？

Milvus：若是是指 ANNS 的算子擴展的話那其實在咱們的代碼結構當中有一些說明。由於以前有一個作智慧零售的用戶有問到說他們若是想增長一些咱們如今尚未的索引應該怎麼作。在咱們 index 的相關目錄下有一個開發的說明。若是您這邊有興趣的話的話會後咱們把連接發給你，咱們也能夠在羣裏交流。