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

http://mpvideo.qpic.cn/0bf2leaaaaaa3qalyodiobpfawodabmqaaaa.f10002.mp4?dis_k=17550684a324164ea111bfe1002ccce8&dis_t=1588755865

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

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

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

http://mpvideo.qpic.cn/0bf2fyaaaaaaxeal4o3iojpfalwdaaxaaaaa.f10002.mp4?dis_k=8703b1d78039403ab933edc7c18108c7&dis_t=1588755865

| 部分文字实录

* 以下文字部分由语音转文字，已经过一些调整让句意可以更清楚

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 的比较请看影片解说会更清楚喔！）