性能测试报告：基于MSMARCO亿级数据集

集群规格与版本

• 主节点：2核 8GB。

• 只读节点：2核 8GB。

• 搜索节点：32核 256GB * 3。

• 客户端延迟：0.097ms。

• PolarDB向量索引版本：2.19.3。

数据集

创建HNSW索引并写入数据

1. 创建索引：以下配置用于在亿级数据规模下创建索引，以平衡构建速度、内存占用和查询性能。

   1. 定义索引结构和关键参数。

      • number_of_shards：设置为18，以在3个搜索节点（共96个物理核心）间均匀分布数据和计算负载。

      • ef_construction和m：HNSW索引构建时的关键参数，本次测试选择128和8作为构建速度和索引质量的平衡点。

      • refresh_interval和durability：为最大化测试性能进行的特定优化，不建议在生产环境直接使用。 详细说明参见应用于生产环境。

   2. 执行以下命令创建索引。

      curl -X PUT "http://<endpoint>:<port>/msmarco" -H 'Content-Type: application/json' -d'
      {
        "mappings": {
          "properties": {
            "docid": { "type": "keyword" },
            "domain": { "type": "keyword" },
            "emb": {
              "type": "knn_vector",
              "dimension": 1024,
              "method": {
                "engine": "faiss",
                "space_type": "l2",
                "name": "hnsw",
                "parameters": {
                  "ef_construction": 128,
                  "m": 8
                }
              }
            },
            "url": { "type": "text" }
          }
        },
        "settings": {
          "index": {
            "replication": { "type": "DOCUMENT" },
            "refresh_interval": "0s",
            "number_of_shards": "18",
            "translog": {
              "flush_threshold_size": "1gb",
              "sync_interval": "30s",
              "durability": "async"
            },
            "knn.algo_param": { "ef_search": "64" },
            "provided_name": "msmarco",
            "knn": "true",
            "number_of_replicas": "0"
          }
        }
      }
      '

2. 写入数据：将MSMARCO V2.1数据集写入HNSW索引。

执行查询性能测试

测试不同并发度和ef_search参数组合下的查询吞吐量（QPS）、延迟（Latency）和召回率（Recall）。

• concurrency：模拟从1到128个并发查询。

• ef_search：查询时在HNSW图中搜索的邻居节点广度。此值越大，理论上召回率越高，但计算开销也越大，会导致QPS下降和延迟升高。

# 示例命令，请替换为实际脚本
python benchmark.py --concurrency 1/2/4/8/16/32/64/128 --ef-search 32/64/128/256 --max-duration 60

性能结论分析

• 并发扩展性：从QPS曲线可以看出，随着并发数从1增加到64，系统吞吐量（QPS）接近线性增长，表明PolarDB向量引擎具备良好的水平扩展能力。在64并发之后，QPS增长开始放缓，并在128并发时达到峰值，此时系统资源（很可能是CPU）已接近饱和，成为性能瓶颈。

• 延迟与并发关系：平均延迟（Avg）和P99延迟随着并发数的增加而显著升高，这符合系统负载增加的规律。在追求高QPS的场景下，需关注P99延迟是否满足业务要求。

• 召回率表现：在所有测试条件下，召回率均稳定在95.8%以上，表明HNSW索引在当前参数下具有较高的搜索准确性。

关键参数生产建议

以下参数为追求极限测试性能而设置，在生产环境使用时需谨慎评估。

• "refresh_interval": "0s"

  • 测试目的：禁用自动刷新，确保在写入测试期间数据仅写入内存和translog，在查询测试前手动refresh，以获得不受后台任务干扰的查询性能数据。

  • 生产建议：禁止在生产环境设置为0s。应根据业务对数据可见性的要求设置一个合理的值，例如1s，表示新写入的数据最快在1秒后可被查询到。

• "durability": "async"

  • 测试目的：采用异步刷盘（translog），数据先写入内存后即返回成功，由后台线程异步持久化到磁盘，以提升写入吞吐量。

  • 生产建议：在高数据可靠性场景下慎用。async模式在服务器宕机等极端情况下，可能丢失最后几秒钟尚未刷盘的数据。若对数据可靠性要求高，应在生产环境使用默认的request模式。该模式会确保数据写入translog并落盘后才返回成功，但会降低写入性能。

资源利用率评估

了解系统在峰值负载下的资源消耗，对进行准确的容量规划至关重要。

• 写入密集型场景：在8394 docs/sec的峰值写入期间，系统瓶颈主要体现在CPU（用于索引构建）和磁盘I/O（用于translog写入）。

• 查询密集型场景：在128并发、1067 QPS的峰值查询期间，系统瓶颈主要为CPU密集型。