Elasticsearch BBQ 与 OpenSearch FAISS：向量搜索性能对比

作者：来自 Elastic Ugo Sangiorgi

Elasticsearch BBQ 与 OpenSearch FAISS 的性能对比。

带有二值量化的向量搜索：使用 BBQ 的 Elasticsearch 比使用 FAISS 的 OpenSearch 快 5 倍。Elastic 收到了来自社区的请求，希望澄清 Elasticsearch 与 OpenSearch 在性能上的差异，特别是在语义搜索 / 向量搜索方面，因此我们进行了这些性能测试，以提供清晰、数据驱动的对比。

二进值量化对决

以原始形式存储高维向量会占用大量内存。量化技术通过将这些向量压缩为更紧凑的表示形式，大幅减少内存占用。搜索过程在压缩空间中进行，从而降低计算复杂度，特别是在处理大型数据集时，提高搜索速度。

Elastic 致力于将 Lucene 打造成顶级的向量引擎。我们在 Elasticsearch 8.16 中基于 Lucene 引入了更优的二值量化（BBQ），并在 8.18 和 9.0 中进一步优化。BBQ 基于一种新的标量量化方法，将 float32 维度压缩为比特，实现了约 95% 的内存压缩率，同时保持了较高的排序质量。

另一方面，OpenSearch 使用多个向量引擎：nmslib（现已弃用）、Lucene 和 FAISS。在之前的一篇博客中，我们对 Elasticsearch 和 OpenSearch 的向量搜索进行了比较。我们使用了三个不同的数据集，并在两种产品上测试了不同的引擎组合和配置。

本博客聚焦于两款产品当前可用的二进值量化算法。我们使用 openai_vector 的 Rally track，测试了 Elasticsearch 的 BBQ 与 OpenSearch 使用 FAISS 的二进值量化。

测试的主要目标是在相同召回率水平下评估两种方案的性能。什么是召回率？召回率是衡量搜索系统成功检索到多少相关结果的指标。

在本次评估中，recall@k 尤为关键，其中 k 表示所考虑的前 k 个结果。Recall@10、Recall@50 和 Recall@100 分别衡量在返回的前 10、50 和 100 个结果中，出现了多少真实的相关项。召回率的范围是从 0 到 1（或从 0% 到 100%）。这很重要，因为我们讨论的是近似 KNN（ANN）而不是精确 KNN，在精确 KNN 中召回率总是 1（100%）。

对于每个 k 值，我们还指定了 n，表示在最终排序之前所考虑的候选项数量。这意味着在计算 Recall@10、Recall@50 和 Recall@100 时，系统首先通过二进值量化算法检索 n 个候选项，再对其排序，判断前 k 个结果中是否包含预期的相关项。

通过控制 n，我们可以分析效率与准确率之间的权衡。较高的 n 通常会提升召回率，因为有更多候选项可供排序，但也会增加延迟并降低吞吐量。相反，较低的 n 虽能加快检索速度，但若候选项太少，可能会降低召回率。

在本次对比中，Elasticsearch 在相同配置下展现出比 OpenSearch 更低的延迟和更高的吞吐量。

方法论

完整的配置、Terraform 脚本、Kubernetes 配置文件以及使用的特定 Rally track 均可在此仓库中的 openai_vector_bq 路径下找到。

与以往的基准测试一样，我们使用了一个 Kubernetes 集群，包含以下节点池配置：

• 1 个用于 Elasticsearch 9.0 的节点池，包含 3 台 e2-standard-32 机器（128GB 内存，32 核 CPU）

• 1 个用于 OpenSearch 2.19 的节点池，包含 3 台 e2-standard-32 机器（128GB 内存，32 核 CPU）

• 1 个用于 Rally 的节点池，包含 2 台 e2-standard-4 机器（16GB 内存，4 核 CPU）

我们分别搭建了一个 Elasticsearch 9.0 集群和一个 OpenSearch 2.19 集群。

Elasticsearch 和 OpenSearch 都在完全相同的配置下进行测试：我们使用经过一些修改的 openai_vector Rally track，该 track 使用了来自 NQ 数据集的 250 万个文档，并附加了使用 OpenAI 的 text-embedding-ada-002 模型生成的向量嵌入。

{
  "source-file": "open_ai_corpus-initial-indexing.json.bz2",
  "document-count": 2580961,
  "compressed-bytes": 32076749416,
  "uncompressed-bytes": 90263571686
}

测试结果报告了在不同召回率水平（recall@10、recall@50 和 recall@100）下的延迟和吞吐量表现，搜索操作由 8 个并发客户端执行。我们使用了单个分片，且未设置副本。

我们运行了以下 k-n-rescore 的组合，例如 10-2000-2000，意思是：k 为 10，n 为 2000，rescore 也为 2000，表示从 2000 个候选中选出 top k（10 个）结果，并对这 2000 个候选进行重排序（相当于“过采样因子”为 1）。每次搜索运行了 10,000 次，其中前 1,000 次作为预热。

Recall@10

• 10-40-40
• 10-50-50
• 10-100-100
• 10-200-200
• 10-500-500
• 10-750-750
• 10-1000-1000
• 10-1500-1500
• 10-2000-2000

Recall@50

• 50-150-150
• 50-200-200
• 50-250-250
• 50-500-500
• 50-750-750
• 50-1000-1000
• 50-1200-1200
• 50-1500-1500
• 50-2000-2000

Recall@100

• 100-200-200
• 100-250-250
• 100-300-300
• 100-500-500
• 100-750-750
• 100-1000-1000
• 100-1200-1200
• 100-1500-1500
• 100-2000-2000

要复现该基准测试，rally-elasticsearch 和 rally-opensearch 的 Kubernetes 配置清单中，所有相关变量都已外部化到 ConfigMap 中，分别可在此处获取（ES）和此处获取（OS）。其中的 search_ops 参数可以自定义，用于测试任意组合的 k、n 和 rescore 值。

OpenSearch Rally 配置如下：

/k8s/rally-openai_vector-os-bq.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: rally-params-os
  labels:
    app: rally-opensearch
data:
  user-tags.json: |
    {
      "product": "OpenSearch",
      "product-version": "OpenSearch-2.19.0",
      "product-label": "OpenSearch-2.19-faiss",
      "benchmark-run": "19-feb-recall@100"
    }
  track-params.json: |
    {
      "mapping_type": "vectors-only-mapping-with-docid",
      "standalone_search_clients": 8,
      "standalone_search_iterations": 5000,
      "ann_threshold": 0,
      "vector_mode": "on_disk",
      "compression_level": "32x",
      "vector_method_name": "hnsw",
      "vector_method_engine": "faiss",
      "search_ops": [
        [100, 200, 200],
        [100, 250, 250],
        [100, 300, 300],
        [100, 500, 500],
        [100, 750, 750],
        [100, 1000, 1000],
        [100, 1200, 1200],
        [100, 1500, 1500],
        [100, 2000, 2000]
      ]
    }

OpenSearch 索引配置

ConfigMap 中的变量随后会用于索引配置，其中部分参数保持不变。在 OpenSearch 中，1-bit 量化通过将压缩等级设置为 “32x” 来配置。

index-vectors-only-mapping-with-docid-mapping.json

{
  "settings": {
    {% if preload_pagecache %}
    "index.store.preload": [
      "vec", "vex", "vem", "veq", "veqm", "veb", "vebm"
    ],
    {% endif %}
    "index.number_of_shards": {{ number_of_shards | default(1) }},
    "index.number_of_replicas": {{ number_of_replicas | default(0) }},
    "index.knn": true,
    "index.knn.advanced.approximate_threshold": {{ ann_threshold | default(15000) }}
  },
  "mappings": {
    "dynamic": false,
    "properties": {
      "docid": {
        "type": "keyword"
      },
      "emb": {
        "type": "knn_vector",
        "dimension": 1536,
        "space_type": "innerproduct",
        "data_type": "float",
        "mode": {{ vector_mode | default("in_memory") | tojson }},
        "compression_level": {{ compression_level | default("32x") | tojson }},
        "method": {
          "name": {{ vector_method_name | default("hnsw") | tojson }},
          "engine": {{ vector_method_engine | default("faiss") | tojson }},
          "parameters": {
            "ef_construction": 100,
            "m": 16
          }
        }
      }
    }
  }
}

Elasticsearch Rally 配置

/k8s/rally-openai_vector-es-bq.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: rally-params-es
  labels:
    app: rally-elasticsearch
data:
  user-tags.json: |
    {
      "product": "Elasticsearch",
      "product-version": "Elasticsearch-9.0.0-ade01164",
      "product-label": "Elasticsearch-9.0-BBQ",
      "benchmark-run": "19-feb-recall@100"
    }
  track-params.json: |
    {
      "mapping_type": "vectors-only-mapping-with-docid",
      "standalone_search_clients": 8,
      "standalone_search_iterations": 5000,
      "vector_index_type": "bbq_hnsw",
      "search_ops": [
        [100, 200, 200],
        [100, 250, 250],
        [100, 300, 300],
        [100, 500, 500],
        [100, 750, 750],
        [100, 1000, 1000],
        [100, 1200, 1200],
        [100, 1500, 1500],
        [100, 2000, 2000]
      ]
    }

Elasticsearch 索引配置

index-vectors-only-mapping-with-docid-mapping.json

{
  "settings": {
    {# non-serverless-index-settings-marker-start #}
    {%- if build_flavor != "serverless" or serverless_operator == true -%}
    {% if preload_pagecache %}
    "index.store.preload": [ "vec", "vex", "vem", "veq", "veqm", "veb", "vebm" ],
    {% endif %}
    "index.number_of_shards": {{ number_of_shards | default(1) }},
    "index.number_of_replicas": {{ number_of_replicas | default(0) }}
    {%- endif -%}
    {# non-serverless-index-settings-marker-end #}
  },
  "mappings": {
    "dynamic": false,
    "properties": {
      "docid": {
        "type": "keyword"
      },
      "emb": {
        "type": "dense_vector",
        "element_type": "float",
        "dims": 1536,
        "index": true,
        "similarity": "dot_product",
        "index_options": {
          "type": {{ vector_index_type | default("bbq_hnsw") | tojson }},
          "ef_construction": 100,
          "m": 16
        }
      }
    }
  }
}

结果

有多种方式来解读结果。对于延迟和吞吐量，我们分别在每个召回率水平绘制了简化图表和详细图表。如果我们将“更高更好”作为每个指标的标准，那么很容易看到差异。然而，延迟是负向指标（更低更好），而吞吐量是正向指标。对于简化图表，我们使用了 (recall / latency) * 10000（简称 “速度”）和 recall * throughput，因此这两个指标意味着更高的速度和更高的吞吐量更好。接下来我们来看看。

Recall @ 10 - 简化图表

在该召回率水平下，Elasticsearch BBQ 的速度是 OpenSearch FAISS 的最多 5 倍（平均快 3.9 倍），且吞吐量平均是 OpenSearch FAISS 的 3.2 倍。

Recall @ 10 - 详细图表

Recall @ 50 - 简化图表

在该召回率水平下，Elasticsearch BBQ 的速度是 OpenSearch FAISS 的最多 5 倍（平均快 4.2 倍），且吞吐量平均是 OpenSearch FAISS 的 3.9 倍。

Recall @ 50 - 详细结果

Recall @ 100

在该召回率水平下，Elasticsearch BBQ 的速度是 OpenSearch FAISS 的最多 5 倍（平均快 4.6 倍），且吞吐量平均是 OpenSearch FAISS 的 3.9 倍。

Recall @ 100 - 详细结果

BBQ 的改进

自首次发布以来，BBQ 取得了长足的进步。在 Elasticsearch 8.16 版本中，为了进行对比，我们包含了 8.16 的基准测试结果与当前版本的对比，可以看到自那时以来召回率和延迟已经得到了显著改善。

在 Elasticsearch 8.18 和 9.0 中，我们重新编写了向量量化的核心算法。因此，尽管 8.16 版本中的 BBQ 已经表现出色，但最新版本的性能更为强大。你可以在这里和这里阅读相关内容。简而言之，每个向量都通过优化的标量分位数进行单独量化。结果是，用户在向量搜索中可以享受到更高的准确性，同时不影响性能，从而使 Elasticsearch 的向量检索更强大。

结论

在 Elasticsearch BBQ 与 OpenSearch FAISS 的性能对比中，Elasticsearch 在向量搜索上显著优于 OpenSearch，查询速度最多快 5 倍，吞吐量在各个召回率水平上平均高出 3.9 倍。

主要发现包括：

• Recall@10：Elasticsearch BBQ 最多比 OpenSearch FAISS 快 5 倍（平均快 3.9 倍），吞吐量平均是 OpenSearch FAISS 的 3.2 倍。

• Recall@50：Elasticsearch BBQ 最多比 OpenSearch FAISS 快 5 倍（平均快 4.2 倍），吞吐量平均是 OpenSearch FAISS 的 3.9 倍。

• Recall@100：Elasticsearch BBQ 最多比 OpenSearch FAISS 快 5 倍（平均快 4.6 倍），吞吐量平均是 OpenSearch FAISS 的 3.9 倍。

这些结果突出了 Elasticsearch BBQ 在高维向量搜索场景中的高效性和性能优势。Elasticsearch 8.16 中引入的更优二值量化（BBQ）技术提供了显著的内存压缩（约 95%），同时保持了高排名质量，使其成为大规模向量搜索应用的优选方案。

在 Elastic，我们不断创新，致力于提升 Apache Lucene 和 Elasticsearch，以提供最佳的向量数据库，适用于搜索和检索用例，包括 RAG（Retrieval Augmented Generation - 检索增强生成）。我们的最新进展显著提高了性能，使向量搜索比以往更快、更节省空间，基于 Lucene 10 的改进。本文正是这一创新的又一例证。

你可以通过这个自学搜索 AI 的实操教程亲自体验向量搜索。现在，你可以开始免费云试用，或者在本地机器上尝试 Elastic。

原文：Elasticsearch BBQ vs. OpenSearch FAISS: Vector search performance comparison - Elasticsearch Labs