背景
我们做了三种方案的测试分别是：
- Elasticsearch + elastiknn : es+插件的方式，分别测试 exact 和 lsh 的耗时和吞吐量，链接：Elasticsearch 向量搜索插件调研和测试
- Elasticsearch + 自带的向量搜索能力，测试只有 exact 的耗时和吞吐量，链接：Elasticsearch 官方自带的向量搜索压测
- OpenSearch + 自带的向量搜索能力，分别测试 exact 和 hnsw 的耗时和吞吐量，链接：OpenSearch 向量搜索压测
第三方对不同插件的概述：
结论
在10并发+持续10秒的场合下，可以得到下面的结论
- 我们可以看到 LSH 的召回率是三者中最低的，只有85%，基本上可以放弃这种算法在业务上的应用，LVSPQ 插件开源社区基本上不维护了，也不考虑了；
- es+ elastiknn 的方式，exact 平均耗时10ms，耗时低，插件自身有做针对向量的优化，可以应用在业务上；
- es+原生实现，exact 平均耗时70ms，能用，对耗时不敏感的业务友好，es 7.14.1 为什么不做插件那种对向量的优化? 因为现在 7.14.1 的版本依赖的 Lucene 是 8.9.0，向量的优化工作是落到了 Lucene，这个版本的 Lucene 对向量搜索支持还不够好，但是根据 Lucene 9 的开发记录，会针对向量做更好的支持，假如升级到 9 后，exact 应该是能做到跟插件的一样的耗时，然后 es 8.0 也会有原生对 hnsw 的支持，es 8+ 这个未来的版本是一个对向量搜索的支持更友好，相关功能更多的版本；
- opensearch knn 的方案是最接近阿里云和百度云的，对比各自的文档的内容，有理由相信阿里和百度他们实现是有借鉴 os knn 的代码，所以我认为 os knn 就是等于阿里云或百度云的方案，因为 os 是基于 es 的 7.10.2，Lucene 也是 8.9.0，它的 exact 耗时跟 es 7.14 的略差，平均耗时90ms；
- opensearch knn hnsw 方案，非常出色，在100w+256维的数据量下，平均耗时能做到10ms，根据第三方做的召回率的测试，有95%+，在大数据量，耗时敏感，准确敏感的业务上，hnsw是最好的方案，缺点也明显的，非常吃内存。
结合我们的业务场景，相似度搜索的有当天库，历史库和固定库，无论是哪种库，数据量都是相对少，在0~10w之间。
- elasticsearch + elastiknn + exact 的方案是能满足当前的需求，但是后续新版本更新基本上就停了；
- opensearch + knn + exact 跟 elasticsearch + exact 略差，同时由于 opensearch 无论是从版本迭代还是从社区活跃度来看，都是比 elasticsearch 落后，这里不考虑 opensearch +knn + exact；
- opensearch + knn + hnsw，更适合大数据量的业务场景，我们这里不合适；
- elasticsearch + exact 的优势是后续版本升级可以直接享受到社区的迭代，尤其是 8.0 的版本，将会拥有更多 knn 相关优化和功能的支持。
建议
1、现阶段，推荐使用 elasticsearch 7.14.1 + elastiknn 7.14.1.2 + exact 的方案；
2、elasticsearch 8+ 版本的使用可以当成后续升级迭代相关业务服务的一个优化点；
3、不考虑 opensearch，原因是社区维护落后，相对消极。
下面是 Elasticsearhc 8.0 关于 knn 支持部分
链接
- 阿里云插件：https://help.aliyun.com/document_detail/145062.html
- 百度云插件：https://cloud.baidu.com/doc/BES/s/Rke3o8qos
- 第三方插件：https://elastiknn.com/
- 官方支持：https://www.elastic.co/guide/en/elasticsearch/reference/master/dense-vector.html
- OpenSearch: https://opensearch.org/docs/latest/search-plugins/knn/index/
一些辅助理解的链接：
本文由 Chakhsu Lau 创作，采用 知识共享署名4.0 国际许可协议进行许可。
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。