點擊觀看完整視頻實錄
⌛ 時間戳
02:31-09:07 Attendee A：Milvus 在 GPU 的支持與性能上的一些問題
09:17-21:00 Attendee B：Milvus 分佈式相關討論
視頻後半段畫面遺失了 但很謝謝另外兩位小夥伴的參與
| Milvus Q&A 部分文字實錄
Attendee= 參會者
Attendee B：
我本身對分佈式這塊還是滿感興趣的， 想問一下社區這邊之後的規劃？也希望有機會和大家一起做開發促進這塊的推動、落地。
顧老師@Milvus：
現在分佈式的話，其實整體上來說兩種思路，一個是基於像現在這種 Mishards 這種 sharding 的方式做一些分庫。那麼現在主要的一些性能瓶頸可能會是在讀取元數據上面，我們現在是在想怎麼樣去解決這個問題，現在有一些思路去解決這種讀取元數據時候的這種競爭，這是一種思路。
然後另外一種也是一直在關注，比如說類似於這種分佈式的一致性協議 raft 這種協議，因爲現在這些用的比較多一點，但其實 raft 也有它自己的限制。
Attendee B：
對，副本這種限制的確是一個問題。
顧老師@Milvus：
這是一方面，分佈式執行的三副本大家現在都能接受，這個問題倒還好。但是怎麼講，因爲 raft 本身它所針對的場景它可能不是那麼的適合這種頻繁的更新，然後像如果是在這種一般的場景下面，就是結構化數據庫的場景下，比如說賬務系統上也做了一次轉賬，那麼它其實傳日誌過去的時候，就是說你把你的賬戶上的餘額從一個數字更新到另外一個數字，但是它這部分的量很小。但是你想如果是在一個向量的場景下面，通常來講我們也沒有更新的操作，更多的就是插入了一個比如說 512 的 2K 一條，這個量其實是非常大的。raft 協議這樣的模式，其實它不是那麼的適合這種大數據量的更新，它不是那麼的友好的。所以其實可能怎麼說也在研究，但是也不敢說它是不是一定能解決這個問題。所以現在就是兩種思路，然後都可能要做一些探索。當然在這種 sharding 的方式上解決元數據訪問的衝突，相對來說可以解決更快一點，因爲現在有一些思路，然後可以去做一些嘗試。
Attendee B：
瞭解。我可以提幾個小的參考嘛？
第一個就是說我覺得關於 raft 協議的場景上，然後因爲它本身其實看起來是一個強一致性，或者說在一定時間內它是要達到最終的一致性。那麼在這種場景下，其實 2K 的這種數據就向量而言，因爲我們做的是人臉檢索，其實 2K 數據應該算是比較大的，這種應該還算比較少的。
顧老師@Milvus：
所以你有大量實時的數據更新進來的時候，因爲其實 512 維的維度並不高，如果是 768 或者 1024 數據量會更大，如果你要有一個非常頻繁的 feed 的把數據這種這種注入進來的話，其實整個 raft 的集羣的網絡的壓力可能會比較大，它和傳統單純的 SQL 的數據庫不太一樣，SQL 的數據庫很大情況下，插入是比較少，可能很多的是在做更新，更新的話其實你只要同步 redo SQL 那部分的一個字段加上一個主鍵這樣子，其實內容不是那麼的多的。
Attendee B：
那是不是說其實我們要同步的是一種 binlog，而不是直接去同步元數據？
因爲我理解元數據的同步，比如說類似於增刪改查這種其實是比較頻繁的，假設增刪改查比較頻繁，其實會有一些數據合併的問題，其實就不如去看一下，比如說類似於Redis（很久之前看過，但現在已經忘得差不多了），它會有一些類似於類似於 binlog的，比如說你在某些數據上+1-1，然後反覆多次之後，其實可能對於整個集羣的影響沒有那麼多，當然它是一個比較簡單的程序，它就是數值型的可能和向量型的還是不太一樣。但是如果是頻繁的這種增插的話，我理解增插還好說，因爲其實你可以打個批量包，甚至用數據壓縮的方式，都可以去在一定程度上解決問題。但是合併的策略應該需要去想一下。
然後第二個是說你說的關於文件讀取或者說數據索引文件，我覺得其實可以考慮看不同的索引類型去做這個事，因爲更多的場景下，比如說剛纔說到的一些人臉的搜索上，它可能是需要比較精準，它是 Flat 的，或者說就是那種最精準的暴力搜索，但是一些其他的比如說 IVF/IVFPQ 其實它就不是一個精準搜索。在這種情況下，其實索引或者說建立的方式上，我理解其實就相當於會里面的優化。我的建議是針對不同的索引類型可能從不同的方式或者從不同的角度去解決可能會更好一些。根據場景來，也不能都用同一個方式去解決，我的建議是這樣。
顧老師@Milvus：
怎麼說呢，因爲畢竟想做成一個通用性的技術，然後也引入了像 write-ahead log （WAL）這樣的方式，而且也會存向量的原始的數據。所以其實更多還是希望能夠有一個相對大家都差不太多的方式去統一的做這些東西，但這個東西確實是一個怎麼說呢？和這個會有點不太一樣，所以在這方面是有點不太好辦的地方。
Attendee B：
只是提議，因爲如果說作爲開源的話，其實可能對於大家更多是一個專用場景的話，可能這會比較難。這就相當於通用和深度，你選一個的話通用上可能兼容情況更好，纔有更多的人用，但是深度上可能就是說可能在某一個方向上，某些人或者某些領域就會影響不是那麼好，然後他們只能說我在這個技術來去改造，對吧？
顧老師@Milvus：
是的，所以其實關於日誌同步是一個比較複雜的問題，因爲傳統數據庫還是可以去...redo log 其實量還是可以縮的比較小，但是一旦是涉及到這種插入的話或者刪除的話，其實它是全量數據更新過去的。所以在很多年以前我還在 IBM 工作的時候，我們當時是做一個兩個數據庫集羣之間的數據同步工具，在一個國內比較大的銀行那邊做 POC，然後就會發現說這當中最大的一個挑戰就在於在正常情況下，其實數據庫是不需要記全量日誌的。就是說我一條記錄上面，比如說我更新了字段，比如說這條記錄有 10 個字段，字段 1 到字段 10，假定我在一次，其實比較多的是更新的，就是查詢的操作是最多的，然後去更新，最後纔是插入。在做更新操作的時候，可能你更改了字段 2 和 3，那麼在數據庫的日誌當中它只會記 2 和 3 的東西在日誌裏，所以他其實日誌的量會比較小。
當我們去把這些 redo log 去同步出去的時候，其實那樣量也都還好，因爲你只同步了兩個字段。但是在某一些場景下，當然用戶要做一些審計的時候，他想知道的東西可能不單單是哪一些字段被修改了，他想知道說比如說字段 1 是賬戶的 ID，他想知道說在這段時間內有哪些賬戶的信息被修改，這個時候你日誌發送出去的內容就不單單只是被修改的那些，需要把剩下那些沒有修改過的都發出去，因爲以防用戶他在某些業務場景下他需要用到不同的數據，然後這時候你就會發現你的日誌量暴增，又帶來了各種日誌的問題，傳輸的問題等等，所以其實在這個場景下面就始終是巨大的一個挑戰。
而向量又很不幸，它又不是這種我把 512 維的數據，他又不能說我改了其中的兩個數據，這樣通常來說都是不斷的插入新的 512 維的數據兩邊一條，所以在這個當中其實確實如果真跑起一個 raft 集羣的話，可能對網絡會有一定的壓力，所以這也是一直在考慮的一個問題。
Attendee B：
好的好的，感謝。
顧老師@Milvus：
非常感謝 Yan 對我們這個項目這麼的關注，我們其實在 Slack 上也有一個開發者的頻道，也歡迎大家就是想要參與到項目開發的同學能夠加入到裏面，我們以後也會把我們的社區變得更有組織性，如果對於那些想要參與到開發工作當中的同學的話，我們也會有更多的這種深度的技術交流的這種機會，去探討這些未來的 roadmap 之類的。
希望加入 Milvus 爲社區貢獻代碼嗎？歡迎加入 Milvus Slack 開發者頻道！
| 歡迎加入 Milvus 社區
github.com/milvus-io/milvus | 源碼
milvus.io | 官網
milvusio.slack.com | Slack 社區
zhihu.com/org/zilliz-11/columns | 知乎
zilliz.blog.csdn.net | CSDN 博客
space.bilibili.com/478166626 | Bilibili
