云原生数据库 PolarDB：MySQL协议：基于MSMARCO亿级数据集

集群规格与版本

• 主节点：4核 16GB。

• 只读节点：4核 16GB。

• 列存索引只读节点：88核 710 GB。

• 客户端延迟：0.201毫秒。

• 内核版本：MySQL 8.0.2。

数据集

创建向量索引并写入数据

1. 创建用于存储向量数据的表，并定义向量索引的类型和关键参数。执行以下DDL语句创建doc_embeddings表。

   CREATE TABLE doc_embeddings (
       id INT(11) NOT NULL AUTO_INCREMENT,
       docid VARCHAR(45) NOT NULL,
       emb VECTOR(1024) DEFAULT NULL COMMENT 'imci_vector_index=FAISS_HNSW_SQ(metric=INNER_PRODUCT,max_degree=16,ef_construction=200,sq_type=fp16)',
       PRIMARY KEY (id)
   ) ENGINE = InnoDB COMMENT 'columnar=1'
   PARTITION BY HASH (id) PARTITIONS 8;

   参数说明

   • COMMENT 'columnar=1'：此注释用于为该表创建列存索引，是使用向量索引的前提。

   • COMMENT 'imci_vector_index=...'：通过注释方式定义向量索引。

     • FAISS_HNSW_SQ：表示使用基于FAISS库实现的HNSW算法，并结合标量量化（Scalar Quantization）进行压缩。

     • sq_type=fp16：指定量化类型为16位浮点数（FP16），可在保证较高精度的同时，将内存占用和原始数据大小减半。

     • max_degree=16、ef_construction=200：HNSW索引的构建参数。详情请参见创建向量索引。

   • PARTITION BY HASH (id) PARTITIONS 8：利用自增主键将表和索引数据哈希打散到8个分区。此策略旨在利用多核并行处理能力，平衡高并发下的查询延迟和吞吐量。分区数通常建议与CPU核数相关或根据压测结果调整。

2. 写入数据：将MSMARCO V2.1数据集写入doc_embeddings表。PolarDB会自动在列存索引只读节点后台构建FAISS_HNSW_SQ向量索引。

执行查询性能测试

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

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

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

# 示例命令
python perf_test_parallel.py

性能结论分析

• 高吞吐与良好的扩展性：

  • 随着并发度从1增加到128，系统整体QPS持续增长，表明PolarDB的并行计算框架能够有效利用多核资源处理并发请求。

  • 在ef_search=120时，QPS从单并发的370增长至128并发下的6,753，展现了优异的水平扩展能力。

• 低延迟与稳定的长尾表现：

  • 在单并发的理想情况下，平均延迟低至2.69ms，P99延迟控制在3.67ms，响应速度快。

  • 即使在128高并发、ef_search=200的重度负载下，P99延迟仍能控制在60ms以内，保障了高负载下服务的可用性。

• 性能与精度的权衡关系：

  • 对比ef_search为120、160、200三组数据可见：随着ef_search的增加，召回率（Recall@10）从约0.952提升至0.966，获得了约1.4%的精度提升。

  • 为此付出的代价是，在128并发下，QPS从6753下降至4879（降低约28%），平均延迟从18.94ms上升至26.22ms（增加约38%）。

• 高并发下的性能瓶颈：

  • 在并发度从64增至128时，QPS的增长速度开始放缓，而P99延迟则出现较大幅度的上升。这表明系统资源（如CPU）已接近饱和，开始出现资源竞争，这是高并发系统的正常现象。