当前位置：个人在线分享 > ES 8的向量检索性能调优实践
  • 文章介绍

    • 有疑问？请点击复制链接咨询！

    前言

    ES的官方实验室曾发布过一篇博客，介绍了使ES向量检索性能获得显著提升的技术要点与展望：

    1. 多线程搜索能力的利用：Lucene 的分段架构允许实现多线程搜索能力。Elasticsearch 通过同时搜索多个段来提高性能，使用所有可用的 CPU 核心的计算能力显著减少了单个搜索的延迟。
    2. 加速多图向量搜索：通过在邻近图中平衡探索和利用，调整扩展匹配集的大小，控制运行时间和召回率之间的权衡，这对于在多个图中实现最佳搜索性能至关重要。
    3. 信息交换优化：在多图搜索场景中，通过智能地在搜索之间共享状态，使基于全局和局部竞争阈值的遍历决策更加明智，从而提高搜索效率。
    4. Java 最新进展的利用：通过 Project Panama Vector API，Java 代码现在可以无缝地与 SIMD 指令交互，解锁矢量引擎。
    5. 标量量化：Lucene 引入了标量量化技术，这是一种有损压缩技术，可以在不牺牲搜索性能的情况下显著减少内存需求。
    6. 压缩技术的改进：通过将每个维度从 7 位压缩到 4 位，进一步减少了数据大小，同时保持了搜索结果的准确性。
    7. 二进制量化的探索：未来可能会将二进制量化技术集成到 Lucene 中，这有可能彻底改变向量存储和检索。
    8. 多向量集成：Lucene 和 Elasticsearch 通过嵌套字段和连接功能，支持在顶级文档中管理多个嵌套文档，允许跨嵌套文档进行搜索，并随后与它们的父文档连接。
    9. 预连接优化：在搜索子向量段落时，Lucene 能够在搜索 HNSW 图的同时预先连接到父文档，确保返回的是文档而不是段落，这提高了效率。

    这些技术如果得到集成，大部分是对用户透明的，我们今天要说的是在实践层面，对于向量检索有哪些调优考虑。

    段合并只有20%的性能提升吗？

    在之前的初步测试中，我们已经得出一个确定的结论（ESrally已专门为此设计了测试用例），在测试工具默认参数的情况下，段合并可以带来全面的 20%性能提升（也就是无论其他参数如何变换，QPS和latency性能表现提升趋势接近一致）。

    我们观察数据量（约 260 万 96 维数据）：

    原始文档的大小解压缩后是 20 GB。

    将数据写入ES后索引实际占用的存储：

    # 合并前：4.5GB
curl  http://localhost:9200/_cat/indices/vectors?v
health status index   uuid                   pri rep docs.count docs.deleted store.size pri.store.size dataset.size
green  open   vectors f4iuM6vjTGiBwz8lofwqFw   2   0    2500000            0      4.5gb          4.5gb        4.5gb

## Running force-merge 100%- 合并后：1GB
curl  http://localhost:9200/_cat/indices/vectors?v
health status index   uuid                   pri rep docs.count docs.deleted store.size pri.store.size dataset.size
green  open   vectors f4iuM6vjTGiBwz8lofwqFw   2   0    2500000            0        1gb            1gb          1gb

    跟随后续的并发调优，我们可以看出段合并的巨大优势，不止 20%！

    并发 QPS 调优

    并发10的情况

    无法直接修改搜索并发，需要改动源码目录 .rally/benchmarks/tracks/default/dense_vector/challenges 的 default.json：

    # 修改示例
{
   
  "name": "knn-search-100-1000_multiple_segments",
  "operation": "knn-search-100-1000",
  "warmup-iterations": 100,
  "clients": 10,
  "iterations": 1000
}

    测试指令：

    ./esrally race --track-path=/root/.rally/benchmarks/tracks/default/dense_vector --target-hosts=localhost:9200 --pipeline=benchmark-only  --offline  --report-file=/home/elastic/ssd_dv_s2-c1-30g-d1-sc10-1.csv --report-format=csv --track-params="bulk_indexing_clients:1" --user-tags="shards:2,clients:1,mem:30g,disk:1,sc:10"

    对比基线为全默认值，变量为 sc：10，也就是搜索并发度为 10。

    比较两次测试结果：

     ./esrally compare --baseline b337fb0a-39cf-4119-abe5-6dd4be745a32 --contender 576b29d8-98a0-458d-8af1-27830068df80 --report-file /home/elastic/dv-shards2-sc10_1.csv  --report-format csv

    • knn-search-10-100 +883.02%

    • knn-search-100-1000 +866.39%

    • knn-search-10-100_multiple_segments +496.02%

    • Knn-search-100-1000_multiple_segments +269.07%

      在 10 搜索并发的情况下，对比结果显示 QPS 相比默认参数提高数倍。而且，段合并对性能的影响也放大了。

    CPU 使用率明显上升了：

    总体 52.9%使用率, es 进程使用了 2538% 的 CPU。

    注意，每轮测试需主动删除 ES 中的测试索引（vectors）！

    curl -XDELETE  http://localhost:9200/vectors

    继续测试

    并发 20/30/40/50 的情况。

    20 search
    Mean Throughput,knn-search-10-100_multiple_segments,169.83212959330336,1223.2297240422738,+1053.39759,ops/s,+620.26%

90th percentile latency,knn-search-10-100_multiple_segments,4.8985810310114175,15.743541764095427,+10.84496,ms,+221.39%

99th percentile latency,knn-search-10-100_multiple_segments,6.255753734731111,61.14699723257214,+54.89124,ms,+877.45%

Mean Throughput,knn-search-100-1000_multiple_segments,71.8843832772858,286.788544718593,+214.90416,ops/s,+298.96%

99th percentile latency,knn-search-100-1000_multiple_segments,15.602529068710282,114.20343654463056,+98.60091,ms,+631.95%

Mean Throughput,knn-search-10-100,198.15221100022976,4285.480938609085,+4087.32873,ops/s,+2062.72%

99th percentile latency,knn-search-10-100,3.9556266699219123,3.956923596560939,+0.00130,ms,+0.03%

Mean Throughput,knn-search-100-1000,93.08795806647417,2109.4832627430874,+2016.39530,ops/s,+2166.12%

99th percentile latency,knn-search-100-1000,13.300802457379177,12.577712316997342,-0.72309,ms,-5.44%
    30 search

    后续仅记录代表性的结果：

    Mean Throughput,knn-search-10-100,198.15221100022976,5736.259111262101,+5538.10690,ops/s,+2794.88%

Mean Throughput,knn-search-10-100_multiple_segments,169.83212959330336,1253.008883159874,+1083.17675,ops/s,+637.79%

    注意到，多段的检索性能已经达到瓶颈了，1223 -> 1253 ops。

    40 search
    # 合并段
Mean Throughput,knn-search-10-100,198.15221100022976,6327.666524710088,+6129.51431,ops/s,+3093.34%

# 多段
Mean Throughput,knn-search-10-100_multiple_segments,169.83212959330336,1307.2178700891045,+1137.38574,ops/s,+669.71%

## 延迟
99th percentile latency,knn-search-10-100,3.9556266699219123,8.661079301964493,+4.70545,ms,+118.96%

99th percentile latency,knn-search-10-100_multiple_segments,6.255753734731111,112.7571176411585,+106.50136,ms,+1702.45%

    ES 8的向量检索性能调优实践插图

    监控数据显

    本站无任何商业行为
    个人在线分享 » ES 8的向量检索性能调优实践
    admin

    admin 钻石

    分享到：

    相关推荐

    E-->