Chat with Milvus #10 回顾- Milvus 性能指标

如果你不知道 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 测试结果

| 部分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：

好的，明白。所以你看你如果到时候有什么任何问题，都可以在群里面再随时问我们的。