ES 向量检索性能测试 & 把向量检索性能提升100倍！

时间：2024-10-25 09:15:45

  向量检索不仅在的跨模态检索场景中应用广泛，随着chat gpt的火热，es的向量检索，在Ai领域发挥着越来越大的作用。

  本文，主要测试es的向量检索性能。我从就开始关注ES的向量检索了。当前ES已经发布到 8.10 版本。以下是官方文档的链接：

   /guide/en/elasticsearch/reference/current/

  本文，在测试的时候使用的是8.3版本（因为测试的时候只发布到这里 ）。

  在本文中，妥妥滴都是干货，因为不仅有性能测试，还有搜索性能优化。这里预告以下，在千万规模数据中做的测试，将检索性能提升了将近100倍。在本文中可以看看性能是如何被优化的。

一、背景

测试ES - KNN向量检索性能、写入性能、准确度、资源占用情况。针对该需求，搭建一个8.3.0版本的ES节点，使用ES8.3.0版本的java Client高级API来调用KNN搜索。

测试资源介绍

机器情况

ES情况

插件

数据规模

数据情况

单台机器

48核心

64G内存
磁盘为HDD盘（也测了SSD盘）

单个节点

单个索引

单个分片

不带副本

优化后的段的个数为1

ES版本 8.3.0
JVM31G

elastiknn

 
  1. 34W（340507）
  2. 1000W

数据结构（索引结构和配置）

结构：三个字段，一个向量字段存放512维度的向量数据。一个路径字段，存放图片路径，一个文档id

二、测试结果

写入性能

批量写数据，使用es bulk提交数据，数据刷新间隔时间30s（近实时）。

数据量

总耗时

平均每张耗时

340507

170s

0.5ms

写入数34万，耗时170s。

最佳查询性能

 最终的性能如下表,千万级别的检索可以在毫秒级别。经历了两轮优化。

数据规模

检索 top-N

平均耗时

最长耗时

34w

（512维度）

检索 top-1

[3] ms

[110] ms

检索 top-10

[6] ms

[150] ms

检索 top-100

[26] ms

[810] ms

1000W

（512维度）

检索 top-1

[14] ms

[390] ms

检索 top-10

[22] ms

[220] ms

检索 top-100

[42] ms

[73] ms

~ps 最长耗时是非常重要的指标，要重点关注。这很可能是用户在第一次点击搜索的时候出现的情况。短板效应。

检索优化过程

  说明：使用ES原生KNN检索，尝试做了三轮优化。第一轮是对写入的数据，进行一次合并优化；第二轮使用使用开源的插件elastiknn进行优化。第三轮是将数据放在SSD磁盘的机器上。每轮提升两倍。整体性能提升近10倍。（测试结果会受到了Linux os cache的影响，磁盘上的数据从磁盘读取到os cache中 ）如果追求检索性能，应该增加内存，来达到将更多的数据放在缓存中去做检索的目的。

  ps~ 以下相同颜色做对比。第一轮对比，是forceMerge的优化。第二轮是插件优化。第三轮在千万数据集下做测试，接近生产需求，并且包含了三项优化一起做的场景。把三种优化，放在一起，带来更多的提升！

  其中forceMerge优化，只能对不再发生变化的数据做优化。比如昨天入库的数据不再新增和修改，则优化可以生效。但是不适用于实时入库的数据！

数据规模

优化项

检索 top-N

调用次数

总耗时

平均耗时

最长耗时

30W

不优化

检索 top-2

22727

[1148351] ms

[50] ms

-

force

Merge

检索 top-2

22727

[698089] ms

[30] ms

-

不优化

检索 top-10

22727

[1962618] ms

[86] ms

[5183] ms

插件优化

检索 top-10

22727

[795893] ms

[35] ms

[360]

force

Merge

检索 top-10

22727

[1385920] ms

[60] ms

[2016] ms

1000W

不优化（HDD）

检索 top-10

-

-

10 - 20 s

20s

SSD 优化

检索 top-10

22727

[2781526] ms

[122] ms

5s

SSD + 插件 优化

检索 top-10

22727

[1046376] ms

[46] ms

5s

SSD + 插件 + merge优化

检索 top-10

22727

[] ms

[22] ms

[220] ms

使用elastiknn插件优化检索（只看插件优化)

数据合并

检索 top-N

调用次数

总耗时

平均耗时

最长耗时

优化前

检索 top-10

22727

[1161129] ms

[51] ms

[387]

优化后

检索 top-10

22727

[795893] ms

[35] ms

[360]

优化后

检索 top-100

22727

[5776099] ms

[254] ms

[8759]

华为云es + 自研插件 性能（性能比原生好10倍左右）

测试数据集

DataSet1：SIFT开源数据集，维度128，Base数据集100万条

DataSet2：SIFT10M开源数据集，维度128，Base数据集1100万条

DataSet3：GIST开源数据集，维度960，Base数据集100万条

检索性能

数据

索引类型

查询Top1

查询Top10

查询Top100

Rec

RT

QPS

Rec

RT

QPS

Rec

RT

QPS

SIFT

GRAPH

0.992

2.63

6200

0.998

2.66

6000

0.992

3.79

4200

SIFT10M

GRAPH

0.998

3.20

5000

0.998

3.31

4800

0.985

4.82

3400

GIST

GRAPH

0.971

10.0

1500

0.963

12.0

1350

0.911

20.1

600

GIST

GRAPH_PQ

0.954

4.06

4000

0.934

6.54

2450

-

-

-

说明：

Rec表示Topk召回率，RT表示平均查询时延（毫秒），QPS表示查询吞吐量；

由于GIST的维度较高，通过使用GRAPH_PQ加速能够极大地提升查询性能，以损失精准度为代价，来提升速度

三、索引结构

以下索引，30万数据规模用一个分片即可。1000万数据规模，给3个分片。


  "knn_image_index": {
    "aliases": {},
    "mappings": {
      "properties": {
        "my_image_vector": {
          "type": "dense_vector",
          "dims": 512,
          "index": true,
          "similarity": "l2_norm"
        },
        "pic": {
          "type": "keyword"
        },
        "pic_path": {
          "type": "keyword"
        }
      }
    },
    "settings": {
      "index": {
        elastiknn": "true",
        "routing": {
          "allocation": {
            "include": {
              "_tier_preference": "data_content"
            }
          }
        },
        "refresh_interval": "30s",
        "number_of_shards": "1",
        "provided_name": "knn_image_index",
        "creation_date": "1681825402139",
        "number_of_replicas": "0",
        "uuid": "KjqLhlv2SMGxlwWIjgJCMw",
        "version": {
          "created": "8030099"
        }
      }
    }
  }
}

四、资源使用情况

磁盘占用量

30W数据，占用1.7G磁盘空间。

内存占用量

内存使用量极少。

五、测试结论

  ES支持ANN检索、支持删除、支持修改、数据写入性能平均每条耗时5ms。数据存储不占用内存空间，都在磁盘上。1000W图片占用磁盘空间50GB。

  检索性能以下为最佳状态。存储使用SSD盘、使用elastiknn插件做优化、对数据做合并，merge成一个segment。能够达到最好的性能如下表。

数据规模

检索 top-N

平均耗时

最长耗时

34w

（512维度）

检索 top-1

[3] ms

[110] ms

检索 top-10

[6] ms

[150] ms

检索 top-100

[26] ms

[810] ms

1000W

（512维度）

检索 top-1

[14] ms

[390] ms

检索 top-10

[22] ms

[220] ms

检索 top-100

[42] ms

[73] ms

是否能够满足使用需求

六、插件调研、开源测试工具调研、向量算法

KNN - plugin

插件

优点

缺点

git地址

活跃度

elastiknn

1、性能提升一倍

2、社区持续活跃，一直跟着最新版本的ES版本去发布的插件

3、不用改官方的检索语法

暂未发现待调研

GitHub - alexklibisz/elastiknn: Elasticsearch plugin for nearest neighbor search. Store vectors and run similarity search using exact and approximate algorithms.

最后一次更新一天前。持续活跃

k-NN

相对elastiknn，该插件支持把底层生成hnsw一个结构加载进内存

基于内存构建

GitHub - opendistro-for-elasticsearch/k-NN: ��� A machine learning plugin which supports an approximate k-NN search algorithm for Open Distro.

最后一次更新时间在2021年

GSI's Elasticsearch K-NN Plugin

据说是使用GPU加速的插件

未开源，找不到

GSI's Elasticsearch k-NN Plugin | GSI Technology

-

开源向量性能测试工具

项目

优点

缺点

git地址

活跃度

对N个向量检索数据库做性能测试

GitHub - erikbern/ann-benchmarks: Benchmarks of approximate nearest neighbor libraries in Python

最近两天

对十亿规模的向量数据做测试

GitHub - harsha-simhadri/big-ann-benchmarks: Framework for evaluating ANNS algorithms on billion scale datasets.

最近两天

GSI's Elasticsearch K-NN Plugin

GitHub - jobergum/dense-vector-ranking-performance: Performance evaluation of nearest neighbor search using Vespa, Elasticsearch and Open Distro for Elasticsearch K-NN

两年前（21年）

向量检索相关算法

图像检索：向量索引 

蚂蚁金服 ZSearch 在向量检索上的探索 · SOFAStack

相关文章