Chat with Milvus #3 回顾 - ANN-Benchmarks 测试结果

在高维空间中快速进行最近邻搜索已成为一个越来越重要的问题,但是到目前为止,市面上还没有很多客观的比较基准,因此 Erik Bernhardsson 创建了一个 ANN 基准测试工具- ANN-Benchmarks。近日 Milvus 也根据此标准进行了性能测试并对比了 Annoy、FAISS 和 HNSW 等算法 。

这星期二的线上问答我们与参加者分享了Milvus ANN-Benchmarks 的性能测试结果, 并展开与之相关的讨论。

想深入了解测试内容与结果,我们建议观看以下当天活动的录屏, 也欢迎到我们ANN-Benchmarks 的 GitHub Repo 一探究竟:https://github.com/milvus-io/ann-benchmarks

 

| 部分文字实录

* 以下文字部分由语音转文字,已经过一些调整让句意可以更清楚。视频实录请见:https://zhuanlan.zhihu.com/p/112610553

 

User:

请问一个比较简单的问题,纵坐标的 QPS 3e+4 的那个 e 的单位是什么?

 

Milvus:它是一个对数坐标,e 后面是指数, e+2 就相当于是100,10的二次方这样子。所以 2e+2 就是200,5e+2 就是500,然后 e+3 就是1000这样子。

 

User:跟科学计数法似的。

 

Milvus:对,它是一个类似于这种科学计数法,然后它是一个类似于对数坐标系,然后你可以看到他每一个横线,这个横行之间它距离其实是不一样的,越到靠近上部的时候它越密集,但是它每一格跨度就会更大。

 

User:明白,这个就等于是最高的 QPS 基本上在3万。

 

Milvus:对,是的。他这个是在一个 HNSW 一个图索引,然后他对于召回率要求非常低的情况下,它是可以做到 QPS 很高。因为你要求的召回率越低的话,其实你的计算量就越小。

 

所以在这个过程当中很我们也是非常关心说,一般来说大家想用向量搜索技术的场景下面,你们一般会对召回率的要求在什么样的范围里面?因为像图上其实画到最后30%~40%之间,我感觉这个可能是有点过低。好像我之前接触到的都会说要求至少75% ~80%。我不知道就是说大家的一般的场景下是一个什么样的要求?

 

User:正常你说一般75%~80%能够满足召回率的要求?

 

Milvus:对,但它也是看场景的,因为像我刚才讲75%~80%的话,它也是一个视屏去重的场景。每一个视屏当中提取了一些关键的帧,这些关键帧去做匹配的时候,它要求75%~80%左右的,每一个要求75~80的召准率。因为其实一个视频当中有好多帧,所以其实每个都能有75%~80%,综合起来是能够得到一个最终的综合的召准率其实是比80%要高很多的。

 

但是在一般静态的人脸这种的话,招准率的话,我们原来听到的一些需求都是在95%以上的那种要求,所以所以其实在这个图当中,我们是跑了很多测试,画出了整个的一个情况,但是我个人感觉一般可能在生产环境下,当然我们现在接触到的场景也比较有限,可能是感觉是在90%以上的100%这个区间里面,可能大家会更关心一点。

 

User:想说95%和80%这两个点上面两个点位上的话,它在召回的就是在检索的过程中使用的 nprobe 参数是多少?

 

Milvus:对,这边就是 nlist4096,nprobe10。然后你可以再看一个百分之九十几的,nlist 8192, nprobe100。相当于是如果是4096的话,就相当于是50,相当于是5倍的计算量。

 

User:红色的(那条线)那个是 faiss 原生的,然后绿色的是 Milvus 自己实现的,还是说基于 faiss 做了一些改动?

 

Milvus:对,有一些改动,然后有一些..就是这属于用法方式不一样,因为 Milvus 做为一个向量搜索引擎,它数据管理方式和 faiss 的管理方式是不太一样。所以就算你同样去用它也会产生不同的结果。当然在这过程当中,我们也对他做了一些改动和一些这种编译上的优化。

 

User:所以就等于是你们对算法进行了改动,或者是重新实现?

 

Milvus:对,还是算是在基础上进行的改动,并没有去完全的重新的实现。但是这个改动在不同的场景下,它有的改动还是比较大的。包括我们在后续实现删除的时候,它因为我们整个向量数据管理的方式完全不一样,所以它删除的方式就不是faiss 原生的那种删除的方式,我们还是根据自己的实际的情况去做的实现。 

 

User:除了 recall 和 QPS,各个 package 在储存方面的表现有吗?比如 Milvus 和Faiss 在 sift 数据上搭建的索引的储存开销会有差异吗?

 

Milvus:

是这样的,因为 Milvus 也好,faiss 也好,它其实都包含了多个不同的算法。如果都是同类型的算法,都是 IVF 算法的话,大家都是差不多大小的。当然 faiss 也有 HNSW 的图算法,然后 Milvus 也会去对接 HNSW 的算法,在这种情况下都是图算法、都是 IVF 算法的话就是同类的,存储的开销是差异是很小的。只是说大家怎么组织这些数据的方式不一样。因为像 faiss 的话,可能100万条数据作为一个整体去进行管理, Milvus 这边可能会分一些片,比如说假定说他100万条的量,他可能总量就分成了两个50万,但其实整体的大小是不会变的,但是就是你管理向量的方式还是会有差别。

 

User:我在看文档的介绍的时候,讲到集群方式的部署那一块,然后底下有一个共享存储,所以我想能不能再介绍一下共享存储这一块,因为我在里看那个文档好像写的是比较简单,没有看太明白这一块。

 

Milvus:对现在的集群的话,一般比如说你用了一个 NFS 那它就是一个共享存储,因为其实我们在 slack 频道里面也有一些老外在问,就是说因为我们从下一版本开始 Milvus 会支持 write ahead log,就是 WAL log 方式去记日志,有的人就会说做集群的时候能不能通过同步 redo log 的方式,把数据在不同的节点当中去进行同步的。但是这里因为这种方式是通过 redo log 在不同存储节点之间进行数据同步,这个是比较适合类似于像 AWS Aurora 就是这样做的,它这种结构数据的数据库当中,它比较容易去实现这部分的内容。但是在向量这边的话呢,因为我们都是在一个写节点上去生成索引文件的,索引文件其实它的构建的开销是比较大的,所以我们就没有考虑让他在不同的节点上分别去构建,所以我们通过统一的写节点构建了索引之后,放在共享存储上,然后不同的读节点都可以去读到这个已经生成好的索引节点。

 

这样的话当你如果是做一种混合的方式去部署整个集群的话,写节点上你是可以用GPU 去做索引构建的加速的, 那读节点上你可能就不需要 GPU,你只要 CPU 去服务一下查询的请求就可以了。

 

在后续的版本当中,因为我们现在下一个版本是单机的话会先接到 S3 的存储上,那以后我们集群也会像 S3 的存储这种方式,云存储的方式去对接。这样的话对于整个集群的部署会做比较方便一点。

 

User:共享存储这一块现在使用的是哪一种方式?

 

Milvus:我们现在的话用 NFS 的方式,当然如果你是其他的那种分布式的共享存储的话也可以

 

User:它是不是也是一个那种类似分布式文件系统的?

 

Milvus:对,有一些分布式文件系统也是做共享存储的,像这种的话也是可以去使用的,因为S3的话,它相当于是..不太一样,它是一种云端的对象存储,而且还很便宜,所以说我们也是考虑到可能像大家现在越来越多上云的,或者说自己本身环境现在也是做私有云部署的,对象存储应该来说都是一个比较标准的配置。那么我们就把我们的存储对接到上面的话,对大家部署起来应该是会带来一些便利性, 我们现在是这么想的。

 

User:好的。那它对象存储这一块是不是和阿里云的 OSS 那种是差不多的。

 

Milvus:是对是差不多的对象存储 S3 那套 AWS 开始搞起来的,所以现在每个云厂商都有那套对象存储。

 

User:我是想了解咱们没有 Milvus 的整体系统架构设计,这一块在哪儿,有没有相应的文档?或者是分享的会议?

 

Milvus:整体的架构的话,我们会在下一个版本发布的时候,我们也会有新的文档出来,到时候的话我们会把我们整个的0.7.0上的一些架构的情况都在那个文档当中有体现,然后我们也会有一些技术文章或在我们的专栏里面,所以你也可以关注一下我们的在知乎上的,或者说我们的微信公众号发的一些技术的文章。

 

您这边的话现在是有一些什么样的场景,想要打算去用这种向量搜索的手段去实现什么业务的目标吗?

 

User:具体的新场景还没有出现,但是基本上都是和图像或者是视频搜索这一块,比方说相似通图检测,或者是相似图像推荐这种。

 

Milvus:所以您是做图像方面的一些这种去重和推荐的这些,对,我们其实现在有一些用户确实是在这么用,推荐一些短视频,然后想要去做一些这种短视频的去重、图像去重这些。图像搜索确实是一个挺用的挺多的一个部分。

 

User:有建索引时间的指标没?

 

Milvus:在 ANN-benchmarks 当中的话,刚才也提到了是有建索引的指标的,但是它这个 ANN-Benchmark 都是限定在 CPU 的场景,那它其实比较可能会有点不是特别全面,因为Milvus 的话,我们一般都会建议用户写入节点,最好是做一个 GPU 的节点,这样的话它建索引会快很多。可能具体我们在这种比较下,是不是应该把 GPU 建索引的时间也作为一种加入进去,可能会更全面一点我在想。

 

(想了解不同算法具体所需的 build time/recall 的比较请看影片解说会更清楚喔!)

想参加 Milvus 线上问答的活动?下周二 8PM 第四期活动快来加小助手微信 zilliz-tech 报名!

 

| 欢迎加入 Milvus 社区

github.com/milvus-io/milvus | 源码

milvus.io | 官网

milvusio.slack.com | Slack 社区

zhihu.com/org/zilliz-11/columns | 知乎

zilliz.blog.csdn.net | CSDN 博客

© 2020 ZILLIZ

实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值