Chat with Milvus #10 Benchmark Testing
如果你不知道 Milvus 性能指標要怎麼看或是在哪裏看的話，可以看此視頻- Milvus 的顧老師教你怎麼看 Milvus 性能報告與如何達到最佳性能。
也可以到以下這兩個地方，有非常詳細的關於 Milvus 性能的集合：
-
https://github.com/milvus-io/bootcamp/blob/master/benchmark_test/performance_benchmark.md
-
https://www.milvus.io/cn/docs/benchmarks_aws
關於ANN-Benchmarks 更多的討論， 可以看我們前期的內容： Chat with Milvus #3 回顧 - ANN-Benchmarks 測試結果
Chat with Milvus #10 Q&A
| 部分Q&A文字實錄
顧老師 @ Milvus：
可以給我們介紹一下您這邊主要關注的是一些什麼樣的場景？然後您現在有沒有開始使用Milvus了呢？有碰到一些什麼問題，或者有一些什麼樣的建議嗎？
User A：
非常高興，我也是第一次參加這樣的一個活動。其實我有幾個方面想要去了解一下，第一個就是分佈式這一塊，我想多瞭解一下，因爲現在好像只是支持共享存儲的這種。一個只讀一個只寫，有沒有更多的一個方式？這是第一個想了解的一個問題。
第二個，之前在GitHub有說的我們的場景可能因爲對精度要求比較高，如果把所有的向量都放在一個索引中，精度就會降低，降低的還挺多的，所以需要就是說根據時間和空間去進行一個過濾法。所以限制的4096這個分片能不能可配置化？大概這兩個問題。
顧老師 @ Milvus：
嗯對，其實第2個問題，我之前今天下午在GitHub上看到你問過這個問題，其實當時我也有一個疑問，其實在你的場景下，相對來說，你是針對一個對象，他會有不同種類的向量，對吧？雖然他們可能都是比如說512維的，但其實他是不同的分區當中的向量其實是不一樣的，針對不一樣的對象提取出來，對吧？
User A：
可能這是一方面，這方面剛纔我說的是他根據時空，比如說其實不同的時空裏你是空間範圍越大，他混淆了數據進來，就會越多。如果你把它縮小到一定的範圍，它這個精度會更高一點。我們這個場景，它的一個空間，就是說就像有很多點位它會非常多，反正就超過10個點左右這樣一些空間。
顧老師 @ Milvus：
所以其實分成兩個層次，我覺得一個是說針對一個物體，如果提取出多種不同的向量的話，其實在接下來的規劃當中，我們會逐步去實現這個就是一個作爲一個實體的模型，就是實體它可以有多種不同的向量，然後檢索的時候可以根據多種不同維度的向量去進行檢索，然後將結果做一個融合，然後做一個融合的打分，最後給出一個排序。但是現在因爲暫時還沒有做到這一部分。我覺得還是會建議，就是說如果是從一個對象當中提取出的不同的向量的話，我們可以把它放在不同的collection裏面，而不是放在不同的partition裏面，因爲它其實本質上是不太一樣的。
然後另外一個關於這個時間，如果說它帶了一個時間戳，那麼，因爲可能我不知道你們的時間戳的每個分區當中放多大範圍的時間，如果是放一天的話，4096 其實可以放好多天了，但是如果你們是放一個小時的話，4096個小時其實也就沒有沒有很久了。所以我覺得其實它可以有另外一種方式，我們也是可以建多個的collection，然後去保存不同時間段的一個東西，因爲其實這部分的檢索，我覺得它其實和傳統數據庫當中也有可以借鑑的部分，你冷熱數據的隔離，就是你以前的數據可能就已經不是經常會去檢索了，其實這些相對較少的數據的話呢，放在不同的單獨的這個地方，可能會更恰當一點。如果我們都把它就是放在一個大的collection，有不同的partition的話，其實如果當你要做一個全量查詢的話，它是會帶來很多的干擾的。
User A：
對，我現在是這樣的一個規劃：我每天創建一個collection，然後對時間劃分我就一天一個collection；對空間，就像剛纔跟你說的，應該更多的是空間，你有很多空間地點，超過4096的空間，我們每個空間算一個partition，然後這個空間的所有數據、特徵我都放在這個partition裏面，這樣的話它就會超過4096這個限制了。
顧老師 @ Milvus：
其實我們之前有一個用戶，他也有類似的問題就是說，他也有很多的聯網的設備，不斷的去捕獲這些視頻流，然後將這些東西彙總到後臺的一個集中的服務端上面。但通常來講的話，其實你也不太會說，爲了每一個設備創建一個分區，通常來講它可能是它的一個地區有，他是爲一個地區去創建一個分區，而這個地區當中可能是就包含了多個設備的。
因爲當上層的業務人員來進行查詢的時候，它本身它也是有一些他的權限的一個概念，他有權限，比如說查看這一片地區當中所有的設備，但是他可能就沒有權限查看另一些這個地區的設備。所以其實相同就是它按照權限來劃分的地區，同一地區的設備其實應該還是能夠放在一起的。因爲這樣的話，一方面他匯聚數據會更加快一點，不會特別的碎片化的。
比如說每個文件是1G的話，如果只是單個設備去不停的提供數據的話，他其實要積累到一個創建index的日誌的時候，其實要花很長時間的，你就會有相當一段時間去檢索它的時候，最後那部分都是要用暴力搜索的方式。如果你能夠匯聚多個設備，比如說你10個設備，他就更容易的去把這些數據積累到一定量，然後去創建這些索引。我不知道你們是不是也是類似這樣一種情況？
User A：
他這個思路也算是一個方案，就是說可能把某個空間路徑放在一個partition裏。讓我考慮一下這個方案， 可以借鑑。
顧老師 @ Milvus：
然後共享存儲的話，其實我們現在是，我們現在一個是用共享存儲，還有一個是類似於那種s3存儲，當然也算是一種共享的雲存儲。我們的計算和存儲是分離開，所以我們的存儲是依賴這些共享存儲的，到目前爲止都是這樣一個打算。
User A：
就沒有其他方案是吧？都一直是共享存儲。
顧老師 @ Milvus：
對，暫時還沒有一個在Milvus這一層提供一個共享數據服務的計劃。
User A：
好的。
顧老師 @ Milvus：
所以你的場景下面你是更多的是要去進行私有化的部署，然後私有化的部署當中，你是有沒有一個私有云的一些基本的服務？
User A：
對我來說，我們大部分都是私有化部署。
顧老師 @ Milvus：
所以如果私有云一些基本的基礎設施的話，其實共享存儲它也是一個比較通用的部分，所以我們就到目前都是覺得說，因爲大家應該都有共享存儲，所以好像沒有必要在我們Milvus這個層面再做一套這個東西。
User A：
好的，我知道了，謝謝。
User B：
我是從這兩天接觸到的系統，我這兩天一直想了解一下，我們的業務它有波峯波谷的現象，就是說我今天問過一個就是說週日週一我們的業務量非常大，但是週二之後開始往下走了，週三基本上沒有業務了。所以我在想平時的時候能不能用CPU，高峯的時候，我想用GPU，這個需求是不是有點不太好弄？
顧老師 @ Milvus：
其實是這樣的，就是說像sq8的索引呢它是這樣的，索引建完之後你用CPU也可以，也可以用GPU。因爲索引建完之後，它數據本身它是不管你是用CPU、後續搜索還是GPU搜索都沒有關係的，它數據格式是中立的。
但是我們這邊對於GPU的設定可能和大家的一個期待可能會有一點點不一樣，因爲大家可能接收到的這種宣傳都是用GPU會非常的快，確實GPU會快，但是它也是有一個限定的場景的，GPU它一般來說更適合處理一個大的批量的狀態。
你看我們剛纔給大家分享頁面上面，我們不需要這種，比如說 nq=1的時候，就是你只做單次查詢的時候，其實CPU會比GPU更快一點。如果你是nq1000的話，用GPU就會更快一點，通常來講。所以可能和你期待的這種高峯的時候，你用GPU能夠加快速度可能還不太一樣，還是得取決於你的高峯階段的查詢，你能不能把它匯聚成一個批量，如果是能匯聚成比較大的批量的話，你用GPU一次性去處理，確實是能夠給你帶來一個性能的提升的。
User B：
理解，之前我理解錯了。哈哈哈。實際上我們都是單次查詢的。
顧老師 @ Milvus：
你們的整個的數據量大概是多大的數據的？
User B：
現在我們是5個多億。
顧老師 @ Milvus：
5個多億的話是那種512維的數據嗎？
User B：
128，512太大了，我們把它壓了一下，變成128了。128的話也可以。現在5個億的是248G左右這樣的。
顧老師 @ Milvus：
對，因爲5億的話它128維你用了壓縮的索引的話，它大概依然還是會需要70G左右的內存的空間。
User B：
我是說我們現有的系統還沒有用咱們系統呢。
顧老師 @ Milvus：
是，我的意思就是說在5億的128維的向量的話，如果用SQ8索引的話，在Milvus裏面大概是需要70G內存的，那70G內存的話你的顯卡的話其實一般來說也到不了顯存，所以如果要走顯卡的話，它是需要多張顯卡才能夠支撐到這個量的。
User B：
我們大部分數據都屬於冷數據，熱數據量很少。也就是搜的時候，我們那天我第一次問，好像是顧鈞，好像就回答我了。我們是按活動來的。
顧老師 @ Milvus：
所以其實你搜索的時候，只要搜索本次的活動，你不要搜索歷史的是嗎？
User B：
搜歷史的話很少，大部分都是搜那麼幾個熱門活動，一天可能就是說五六個比較熱門的活動，其他都是冷數據。
顧老師 @ Milvus：
那會還好，如果是這樣的話，是可以考慮放在不同的collection裏面。這樣的話你每次查詢的時候，就只要讀 collection相關的東西的話，不管你是GPU還是CPU的話，對內存的消耗都會相對小一點。
User B：
對。你也是這樣建議我們這樣做，但是以後我們萬一要做全部搜的話，怎麼處理呢？只能一個一個collection去輪巡嗎？
顧老師 @ Milvus：
全庫的話...這樣的機會會很多嗎？
User B：
現在不多。
顧老師 @ Milvus：
你的活動大概有多少個不同的活動？
User B：
現在好像有四五千個，現在我沒仔細看，但是每個週末正常情況下可能有個一二十個或者十幾個做熱門活動，其他的都做完這種活動了。
User C:
啓動兩個Milvus的實例，然後把一個當做緩存式的用，怎麼樣呢？把熱的活動放在這裏面，然後去經常搜的是先搜熱數據，搜不到的再去全庫裏面再去服務。
User B：
我也想過這個方案，但是collection它有複製功能嗎？將來就是我的熱數據怎麼遷到冷數據這裏去呢？
顧老師 @ Milvus：
對，其實這都是很好的問題。目前確實我們對於這種數據歸檔什麼的這些的工具都還比較缺乏。但是如果大家就對這個需求比較強烈的話，我們是會考慮去看看怎麼去實現這些東西的。
User B：
也就是說現在靠我們業務層自己來控制，數據是雙倍或者是怎麼地的雙寫。
顧老師 @ Milvus：
是的。現在主要的工作都在覈心部分的開發，對於工具鏈上確實有所欠缺。
User B：
只要有方案就可以。
User C:
你們有沒有開發一個類似於純內存版本的這樣一個索引？
User B：
我們現在用的就是純內存的，是因爲它佔內存太大了，而且沒有壓縮是沒有處理的。我們現在用的就是我們自己開發的。它沒有什麼壓縮，但是他都在內存裏做，所以速度還是很快的，就是太佔內存了。
User C:
那你們延遲latency大概能達到多少？
User B：
5億數據的全部搜索一次的話，沒有全部做過，我們都是按活動來的。搞活動來基本上還可以的，速度都是可以的。他在內存裏是還是很快的。
顧老師 @ Milvus：
你們每個活動大概會有多大的數據量？
User B：
有大有小，小的話可能是五六萬，多的話就是三四百萬，就是這些特徵。多的話也都是一個活動就三四百萬或者五六百都不到不了500萬，基本上就400萬左右多的活動。
User C:
這樣的話感覺你直接把這個數據直接在那層面，按照你現在的方法，到底去遍歷也完全ok啊，然後全部都在用他這個工具。
User B：
對，主要是現在考慮成本問題，現在不說了，我們現在系統整個內存需要248G內存，這應該太大了，想把它降下成本。
顧老師 @ Milvus：
對用一些 sq8這樣的索引的話，它可以壓縮一下內存的開銷，只要1/4。
User B：
對，而且以後系統再擴容的話也簡單一點，現在我們雖然也能擴容，但是擴容的成本有點高。因爲全在內存裏。
顧老師 @ Milvus：
你現在這240多G內存算是在單臺服務器上的嗎？
User B：
我們也是網絡化的，可以橫向擴展的。平均分，一臺現在130多個g兩個加一塊就是240、250G。
顧老師 @ Milvus：
請問大龍是能不能介紹一下，您這邊大概是一個主要關注Milvus在一個什麼樣的方面？
User C：
因爲我之前有用以圖搜圖，但是之前用的雲產品的，然後今天包括別人也會問我這方面技術方案，我就大概查了一下這方面的資料。然後主要就是也想找一個向量搜索工具、向量搜索引擎，然後就剛好看到了這方面的資料，就看到了你們這個產品。但我自己還沒有去做評測，我只是看了你們的一些評測的數據和一些文章。
顧老師 @ Milvus：
可以看一下我們 GitHub Repo裏面我們有一套評測的方法和一套示例的，是比較成熟的。
您現在原來用的雲服務的以圖搜圖，能不能給我們介紹一下你用的是哪一家的？然後大概一個是搜多少圖片，然後能夠達到什麼樣的效果？
User C：
我主要用的還是百度的，我覺得百度做的還不錯。然後到我們所有圖片量其實不大，其實就是幾十萬張圖片。只不過就是說我們最核心的是對精確準確率的要求非常高。相當於我們不是說只是說給用戶一個排序，我們是相當於要達到top 1的，準確率要達到儘可能的高，所以最後還是選擇用了百度。
顧老師 @ Milvus：
所以它的雲化的圖片搜索服務的話，相當於說你只要把圖片都交給他，然後就再有一個API去搜這個圖片就可以了是嗎？
User C：
對，我只要上圖片，然後他會告訴我給我一個列表就可以了。
顧老師 @ Milvus：
所以你自己配可以配置嗎？就是可以選擇用什麼樣的模型之類的？
User C：
沒有，他完全對用戶完全只有什麼上傳圖庫，然後複述圖片。靈活性上可能會稍微，也許從這個層面上講可能會稍微差一些，但是我覺得對絕大部分用戶還是比較友好的。
顧老師 @ Milvus：
明白，因爲其實在我們的在線的教程庫當中，也有個以圖搜圖的一個例子，他用的是VGG 的一個模型，所以VGG就是一種圖片整體相似度的一種搜索。
因爲有的人可能是想搜一個圖片，當中提取一個對象進行搜對象，但有的人就是需要整體的。我不知道像您這邊的情況的話，您大概是一個什麼樣的搜索的需求？是整體像就可以嗎？還是說你是需要搜一些比較大的？
User C：
其實我感覺的話，因爲我沒有看百度後面的他的技術細節，但我看了一下Bing後面的技術細節，其實從它的特徵出去，它不是說單一的維度，單一的這種特徵，他身上有很多特徵，包括了text的特徵，其實我們也比較關注text。因爲我們主要是做什麼？實際上就是說我們主要的核心還是說開一個藥盒之後，常規的這種藥盒，我們拍完之後，我們想知道這是什麼藥。單純當然要從藥盒本身的圖像上的特點，也要從藥盒上文字的一些特點都去找相似度比較高的綜合判斷，綜合的一個特徵。但我估計百度它後面應該也不是單一的這種特徵，比如說我用VGG，我估計他應該是還融合了很多。
這個主要是我們當時我覺得檢索的話，其實十幾萬的圖片我完全我拿內存去暴力檢索都能檢索完，主要是在特徵提取這一塊我們當時也不是想花不太想花更特別多的精力，所以就直接用了百度。
顧老師 @ Milvus：
好的，明白。
User C：
所以你覺得核心在於還是他把各種特徵融合的比較好吧？
顧老師 @ Milvus：
是的，通常來講都會有一些，比如說這種哈希的、VGG這種一些OCR的東西等等。包括nb方案的等等，就這些基本的東西應該都可以用。
所以對於你們去調用雲服務接口的話，你們對他的預期的返回的時間是有一個要求的嗎？需要在多長時間內返回？
User C：
我們目前的話，因爲用戶還比較少的情況下，還沒有一個特別就是他的時間這塊還沒有一個很卡的瓶頸，我記得他當時從我自己的感受來講的話，整個的來回應該是在我看到他它應該是在幾十毫秒之內，就能夠返回一個結果。100毫秒左右。我覺得整個的演示在對單張圖片的，就是說我發起一次查詢應該在100毫秒左右，具體我還真沒評測。
顧老師 @ Milvus：
所以你的整套的服務用的是百度的？你其他的外圍的這個應用也是部署在百度雲上嗎？還是說在其他的地方？
User C：
不是，在華爲雲上的。
顧老師 @ Milvus：
其實這100個毫秒還包含了他們兩家之間的這種信託。
User C：
像你們的話是專門成立一個公司去維護這個產品是嗎？
顧老師 @ Milvus：
應該說這是一個公司發起的產品，而不是說先有產品在有公司。
User C：
我明白了，就類似於PingCAP 他們這樣的。
顧老師 @ Milvus：
對，是的。可以這樣理解，就是這樣子的。
User C：
好，挺好。
我今天看文章，我有個問題，就是說因爲我看現在包括他們做搜索檢索的時候，特徵不會都是會用 product，pq壓縮一下嘛，壓縮之後特徵它的，我不知道你們現在索引是基於因爲它壓縮之後，距離計算也不是基於歐氏距離計算的，對吧？我對這個有理解錯嗎？它距離計算是？
顧老師 @ Milvus：
這個pq你指的是哪一個階段的pq？
User C：
對特徵進行一個...我看這個小程序，沒有辦法發圖片，怎麼說我把這個圖片發到羣裏面，你們都在那個羣裏對吧？我看的Bing他們的文章,是因爲他們的Bing後面的以圖搜圖，這是他講他的技術架構的。我覺得你們應該都看過文章這個圖片。
算的，而是用了提前計算好的一些。
顧老師 @ Milvus：
對，他這種PQ指的是查碼錶的，就是說在nlist裏面是查碼錶的一種方式。但其實還是比如說，是歐氏距離的相似度，或者說點積的相似度，就是說還是用查表的方式來進行一個距離的估算。
User C：
所以我主要是疑惑在哪，就是說如果他這種只是純粹查表的話，我對這種特徵的索引方式會不會和我普通的，比如說我算歐氏距離的這種向量的索引方式是能不能適用於這種
壓縮後的這種向量？
顧老師 @ Milvus：
是可以適用的，但是他因爲它這種pk指的是一個編碼的方式，它這個編碼它可能會丟失原始向量的一些細節。精度如果要求比較高的話，可能它達不到要求。
User C：
因爲我看從他論文的評測數據來講的話，它的整個就用PQ之後，它的整個的精度損失還是比較小的，幾乎說可以可以忽略掉，但是從內存的帶來的增益收益上來說，還是非常好的。
顧老師 @ Milvus：
是，它這個就看它編碼壓縮的程度吧。其實PK最重要解決的一個問題是內存開銷上的一個問題吧。精度會有犧牲，會下降一些。更快嗎...其實也不一定。
User C：
我明白了，其實速度主要還是在索引上。
顧老師 @ Milvus：
對，但是你的內存肯定是能降很多。
User C：
明白。因爲是這樣，就是說今天也是有朋友他問我，他們也想做一個以圖搜圖的東西，然後當然了我看了你資料之後，我把你們的產品我推薦給他們，然後我說我看他們的產品的用戶感覺還不錯，從評測的數據上看起來也不錯，所以我就把你的產品直接推給他。對，所以我也是借這個機會把這一塊看一看。
User C：
我看你們文檔裏面好像有描述過這個事兒，基於向量化量化的編碼這塊兒什麼，就這塊兒就是這個描述是嗎？
顧老師 @ Milvus：
對，是的。怎麼講？通常可能大家講的pq都是指 Faiss當中的IVFPQ，就是一個量化編碼這種壓縮。
User C：
我明白了。
User D：
我是昨天晚上看到了，因爲我們原先是做接入做大數據運行的，然後我現在想搭一套圖像檢索的系統。我們是在研究所工作，然後我們所裏是有那種哈希的那種方式來檢索的，昨天晚上我們想找一個開源項目，調研的時候看到你們。我想問一下你們的庫是採用的是文檔的那種方式來進行檢索是嗎？
顧老師 @ Milvus：
不是文檔，應該是這樣講，我們圖片搜索給的例子當中，它是用深度學習的VGG模型把你的圖片轉成向量，然後我們向量存在Milvus當中，然後去做向量搜索的方式去做的檢索。
User D：
以前我們所裏的用的庫是拿Cassandra搭建的一個，然後把它的特徵碼，然後再分級層。
顧老師 @ Milvus：
我們的向量數據是存在Milvus自己裏面的，然後我們會對向量上面再建索引文件，因爲這那部分都在是由Milvus來完成的，而不是藉助以下的其他的數據庫來做存儲和索引。
User D：
那就是支持熱備的例子有嗎？比如說增量來計算。因爲我看的demo好像是支持直接是就相當於放到文件夾裏面。
顧老師 @ Milvus：
對是的，如果你有增量數據的話，其實是可以支持的，是因爲我們其實很多實際場景中當地的用戶當中都是接入的一些實時的設備，有視頻流，有提取圖片實時的插入到Milvus當中，這個是沒有問題的。
User D：
然後我想問一下，現在demo用的是VGG16， 會不會有那種在線的可以支持別的特徵？
顧老師 @ Milvus：
是這樣的，我們現在給的那個例子，它其實相對來說是一個比較簡單的例子，就是向大家展示Milvus能幹嘛的一個東西，所以它就簡單的套了一個vgg使用的模型。後續像這種直接更加垂直的端到端的圖片檢索的東西，我們也會嘗試去做，那個就會可能就更加靈活一點，就允許用戶去自定義自己的那些模型。但是內部配置還比較初期，我們只是有這樣一個構想。
User D：
對，我看了一下你們算法，因爲後期像我們做數據處理的時候是支持那種算子的註冊，然後通過這種流式的方式，動態的來做這個部分。
顧老師 @ Milvus：
對，是的，一般來說都會往那個方向去努力的。
User D：
你們這個項目是開展了多長時間？我看好像也就是半年左右是嗎？
顧老師 @ Milvus：
其實是開發了一年多，然後開源是開展了半年。因爲我們是先期在一些早期用戶那邊去進行了一段時間的孵化，然後去年10月份算是正式的開源。
User D：
明白，我也是剛剛調研，有些地方不太清楚，然後現在也就這麼多問一下，因爲昨天晚上剛看。
顧老師 @ Milvus：
好，您可以嘗試一下我們Bootcamp的那些例子。
User D：
我想問一下安裝就只能採用docker的方式嗎？
顧老師 @ Milvus：
你也可以自己編譯的，在我們GitHub上是有編譯說明的。
User D：
我想是因爲集羣的現在還沒開始，我們新的機器沒有艾特機器人，Docker沒開上，所以有可能在真機上試一下。那就是我想問一下，因爲我看剛纔那幾個都問的問題，都是說他布在了一個單機上，後期它是可以支持多機的是吧？存儲的話，如果是要用一套文件系統，還是多盤也是可以，做個物理盤。
顧老師 @ Milvus：
可以支持的。我們現在都是用的共享存儲，或者說雲存儲、S3雲存儲這樣的。這就是你需要有這樣的共享存儲，或者是雲存儲的一個存儲的系統。
User D：
就是我還要需要搭建一個文件系統。
顧老師 @ Milvus：
對。
這個就是編譯的過程，然後裏面所有的要求都有寫，你可以參照嘗試去編譯一下。他因爲如果你能用Docker的話，肯定是最方便。編譯的話，因爲他有一些前置的庫，你需要都下載齊這個樣子。
User D：
明白。可以了。我昨天看的文檔我以爲只能用Docker的方式。我也沒有別的問題了，如果有問題的在羣裏問諮詢一下就可以了。
顧老師 @ Milvus：
好的，謝謝，所以有什麼問題可以隨時問我們。
User D：
其實我們的場景數據量會很大，超級大。我們那個場景是做輿情方面的。
顧老師 @ Milvus：
輿情方面的..明白，其實我們的一個羣當中有一個用戶他也是有一部分做輿情方面的東西，他會有實時的爲每天的新聞有捕獲進來這樣子的。
User D：
我比的要大得多，捕獲的是新浪的那種。沒有，比那個還大。可能是他的幾十倍。
顧老師 @ Milvus：
每天大概會有多少？
User D：
圖片量大的話可能會達到幾億張左右。但是在沒去重之前，它去重之後可能會下降上百的數量級。因爲到時候去提特徵的時候，可能就是如我看如果是去水印，還加上圖片大小，考慮一張留一張的話，可能會去到上千的那種。因爲我們現在有那個場景可能是需要搭一套，因爲我們用研究所之間他也不給你公佈別人的信息，所以自己調研，我就比較麻煩了。
顧老師 @ Milvus：
好的，明白。所以你看你如果到時候有什麼任何問題，都可以在羣裏面再隨時問我們的。
Note：下週二的會議時間因爲適逢 5/1 假期， 我們下次 Chat with Milvus 線上問答 #11 會在下下週二 （5/12） 8:00 PM 在騰訊會議上開聊。歡迎大家踊躍參與～ 參會鏈接會在交流羣裏與公衆號公佈。
| 歡迎加入 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
