多模查询的性能基线如何建立

每日一句正能量

“温柔半两，从容一生。”
只需怀揣少许温柔，便足以化解生活锋芒，换来一生的从容不迫。

1. 背景与问题

多模数据库系统中的“查询性能”通常不是一个单一指标。一条真实查询可能同时涉及：

关系条件：租户、状态、类别、权限、时间范围； 文档条件：标签、来源、版本和 JSONB 属性； 时序条件：指定时间窗口内的指标、事件或行为； 向量条件：语义相似度、Top-K、近似索引； 业务排序：相关度、时间新鲜度、热度和优先级。

例如，用户查询：

找出最近 30 分钟数据库连接数异常、且与“连接池耗尽”故障文档相似的案例。

这不是简单的向量检索。它至少需要：

1. 在关系表中筛选租户、系统和事件状态。
2. 在时序表中查询指定窗口的连接数指标。
3. 在向量表中检索语义相似文档块。
4. 通过文档元数据补充版本、负责人和故障等级。
5. 返回可解释的结果。

如果没有性能基线，系统优化会陷入几个误区：

• 只测平均延迟，不看 P95 和 P99。
• 只测纯向量查询，不测关系过滤和时序关联。
• 只测冷缓存或热缓存中的一种情况。
• 只测空闲数据库，不测导入、备份、索引维护并发场景。
• 只看 SQL 是否成功，不看结果数量、召回质量和资源消耗。
• 更换向量模型或索引参数后，没有可比较的历史数据。

性能基线的目标不是寻找一个“永远不变”的数字，而是建立可重复的实验条件：

固定数据集 固定查询集 固定并发度 固定 Top-K 固定向量模型和索引参数 固定缓存条件 固定统计周期 固定指标口径

2. 环境与数据

环境如下：

2.1 文档与向量表

CREATEEXTENSIONIFNOTEXISTSvector;CREATETABLEknowledge_document(document_id UUIDPRIMARYKEY,tenant_idTEXTNOTNULL,titleTEXTNOTNULL,contentTEXTNOTNULL,categoryTEXTNOTNULL,statusTEXTNOTNULLDEFAULT'published',metadata JSONBNOTNULLDEFAULT'{}'::jsonb,created_at TIMESTAMPTZNOTNULLDEFAULTnow());CREATETABLEknowledge_chunk(chunk_id UUIDPRIMARYKEY,document_id UUIDNOTNULLREFERENCESknowledge_document(document_id),tenant_idTEXTNOTNULL,chunk_noINTNOTNULL,contentTEXTNOTNULL,embedding_modelTEXTNOTNULL,embedding VECTOR(768)NOTNULL,statusTEXTNOTNULLDEFAULT'active',metadata JSONBNOTNULLDEFAULT'{}'::jsonb);CREATEINDEXidx_document_filterONknowledge_document(tenant_id,status,category);CREATEINDEXidx_document_metadataONknowledge_documentUSINGGIN(metadata);CREATEINDEXidx_chunk_embedding_hnswONknowledge_chunkUSINGhnsw(embedding vector_cosine_ops);

2.2 时序指标表

CREATETABLEsystem_metric(ts TIMESTAMPTZNOTNULL,tenant_idTEXTNOTNULL,system_nameTEXTNOTNULL,entity_idTEXTNOTNULL,metric_nameTEXTNOTNULL,valueDOUBLEPRECISIONNOTNULL,labels JSONBNOTNULLDEFAULT'{}'::jsonb);SELECTcreate_hypertable('system_metric',by_range('ts'),if_not_exists=>TRUE);CREATEINDEXidx_system_metric_lookupONsystem_metric(tenant_id,system_name,entity_id,metric_name,tsDESC);

2.3 基准指标表

CREATETABLEbenchmark_run(run_id UUIDPRIMARYKEY,run_nameTEXTNOTNULL,database_versionTEXTNOTNULL,vector_modelTEXTNOTNULL,index_typeTEXTNOTNULL,index_params JSONBNOTNULLDEFAULT'{}'::jsonb,dataset_versionTEXTNOTNULL,cache_modeTEXTNOTNULL,concurrencyINTNOTNULL,started_at TIMESTAMPTZNOTNULL,finished_at TIMESTAMPTZ,statusTEXTNOTNULLDEFAULT'running',notesTEXT);CREATETABLEbenchmark_metric(run_id UUIDNOTNULLREFERENCESbenchmark_run(run_id),query_nameTEXTNOTNULL,metric_nameTEXTNOTNULL,metric_valueDOUBLEPRECISIONNOTNULL,sample_countBIGINTNOTNULLDEFAULT1,labels JSONBNOTNULLDEFAULT'{}'::jsonb,recorded_at TIMESTAMPTZNOTNULLDEFAULTnow());

3. 复现过程

3.1 只测平均延迟的问题

假设执行 1000 次查询，结果如下：

平均延迟：80 ms P95：160 ms P99：850 ms

如果只记录平均值，系统会被判断为“性能正常”。但真实用户中有 5% 的查询超过 160 ms，最慢的 1% 已经接近秒级。对于交互式问答或搜索页面，这种长尾延迟往往直接影响体验。

因此至少记录：

P50：典型请求； P90：较常见慢请求； P95：服务等级的重要指标； P99：长尾和资源争抢； 最大值：用于发现异常任务或锁等待。

3.2 只测纯向量查询的问题

纯向量查询：

SELECTchunk_id,1-(embedding<=>$1::vector)ASsimilarityFROMknowledge_chunkORDERBYembedding<=>$1::vectorLIMIT10;

它无法代表真实业务。生产查询通常还会加入：

WHEREtenant_id=$2ANDstatus='active'ANDmetadata @>$3::jsonb

还可能关联文档表和时序表。如果基准只覆盖纯向量查询，优化后的结果可能在真实条件下完全不同。

3.3 真实多模查询

查询最近 30 分钟发生过连接数异常的案例：

WITHrecent_incidentAS(SELECTDISTINCTentity_idFROMsystem_metricWHEREtenant_id=$2ANDsystem_name='postgresql'ANDmetric_name='active_connections'ANDts>=now()-interval'30 minutes'ANDvalue>$3),vector_candidatesAS(SELECTc.chunk_id,c.document_id,1-(c.embedding<=>$1::vector)ASsemantic_scoreFROMknowledge_chunk cJOINknowledge_document dONd.document_id=c.document_idJOINrecent_incident iONi.entity_id=d.metadata->>'incident_id'WHEREc.tenant_id=$2ANDc.status='active'ANDd.status='published'ANDd.category='incident'ORDERBYc.embedding<=>$1::vectorLIMIT100)SELECTv.chunk_id,d.title,d.metadata,v.semantic_scoreFROMvector_candidates vJOINknowledge_document dONd.document_id=v.document_idORDERBYv.semantic_scoreDESCLIMIT10;

这条查询同时验证：

时序过滤是否有效； JSONB 元数据关联是否有效； 关系状态过滤是否有效； 向量索引是否有效； 多阶段查询延迟是否可控。

4. 方案实施

4.1 建立基准集

基准集要包含不同类型的查询，而不是随机拼接 SQL：

基准集中的每条查询应保存：

query_name SQL 模板 参数范围 预期结果数量 目标 P95 目标 P99 是否允许空结果 是否需要校验召回质量

4.2 固定实验变量

建立性能基线时，必须固定：

数据库版本； 表结构和索引； 数据集版本； 向量模型； 向量维度； HNSW ef_search； 查询 Top-K； 并发度； 缓存模式； 事务隔离级别； 连接池大小； 压测持续时间。

记录一次基准任务：

INSERTINTObenchmark_run(run_id,run_name,database_version,vector_model,index_type,index_params,dataset_version,cache_mode,concurrency,started_at)VALUES($1,'baseline-2026-01','PostgreSQL-15','embedding-model-v2','hnsw','{"m":16,"ef_search":80}','dataset-v3','warm',16,now());

如果只改变一个变量，才能解释性能变化。例如对比ef_search=40和ef_search=120时，其他条件应保持一致。

4.3 设计冷热缓存两套基线

热缓存：

连续执行同一批查询； 让 PostgreSQL shared_buffers 和操作系统缓存充分命中； 观察稳定运行时的延迟。

冷缓存：

切换数据集或清理缓存； 随机访问不同数据区域； 观察首次访问和大范围 IO。

两者都重要：

• 热缓存接近重复查询和高频业务。
• 冷缓存接近新租户、新时间窗口和低频文档查询。
• 只测热缓存会低估磁盘和索引压力。
• 只测冷缓存会高估常态延迟。

4.4 使用 EXPLAIN 验证执行路径

关系查询：

EXPLAIN(ANALYZE,BUFFERS,SETTINGS)SELECTdocument_id,titleFROMknowledge_documentWHEREtenant_id='tenant_a'ANDstatus='published'ANDcategory='incident';

向量查询：

EXPLAIN(ANALYZE,BUFFERS,SETTINGS)SELECTchunk_id,document_id,1-(embedding<=>$1::vector)ASsimilarityFROMknowledge_chunkWHEREtenant_id='tenant_a'ANDstatus='active'ORDERBYembedding<=>$1::vectorLIMIT10;

时序查询：

EXPLAIN(ANALYZE,BUFFERS,SETTINGS)SELECTtime_bucket('1 minute',ts)ASbucket,metric_name,avg(value)FROMsystem_metricWHEREtenant_id='tenant_a'ANDsystem_name='postgresql'ANDts>=now()-interval'1 hour'GROUPBYbucket,metric_nameORDERBYbucket;

重点观察：

是否使用预期索引； 扫描行数和返回行数； Rows Removed by Filter； 共享缓存命中和磁盘读取； 排序是否落盘； 临时文件大小； JIT 是否带来收益； 向量索引候选是否过多。

4.5 统一指标口径

每次查询记录：

query_name run_id request_id start_time duration_ms status rows_returned bytes_read shared_hit_blocks shared_read_blocks cpu_time error_type

应用层计时示例：

importtimedefexecute_benchmark(conn,sql,params):start=time.perf_counter()try:withconn.cursor()ascur:cur.execute(sql,params)rows=cur.fetchall()status="success"error_type=NoneexceptExceptionasexc:rows=[]status="failed"error_type=type(exc).__name__ duration_ms=(time.perf_counter()-start)*1000return{"duration_ms":duration_ms,"rows_returned":len(rows),"status":status,"error_type":error_type,}

不要把连接建立时间、Embedding 生成时间和数据库执行时间混在一个指标中。建议拆分：

query_parse_ms embedding_generation_ms database_execution_ms rerank_ms serialization_ms total_request_ms

4.6 指标写入

INSERTINTObenchmark_metric(run_id,query_name,metric_name,metric_value,sample_count,labels)VALUES($1,'hybrid_incident_search','p95_latency_ms',132.5,10000,'{"cache":"warm","concurrency":16}'),($1,'hybrid_incident_search','rows_returned',10,10000,'{"cache":"warm","concurrency":16}'),($1,'hybrid_incident_search','error_rate',0.001,10000,'{"cache":"warm","concurrency":16}');

查询历史基线：

SELECTrun_id,query_name,metric_name,metric_value,labels,recorded_atFROMbenchmark_metricWHEREquery_name='hybrid_incident_search'ORDERBYrecorded_atDESC;

4.7 并发和阶梯压测

建议使用阶梯并发：

并发 1：单请求能力； 并发 4：低并发稳定性； 并发 16：常态业务； 并发 32：高峰业务； 并发 64：容量边界； 并发 128：故障和降级验证。

每一档至少持续 5 至 15 分钟，避免只采集预热阶段数据。

压测期间同时记录：

数据库 CPU； 内存和连接数； 磁盘吞吐； IO 等待； WAL 生成速度； 锁等待； 缓存命中率； 向量查询 P95/P99； 时序查询耗时； 错误率。

4.8 混合负载压测

综合检索不应只测试查询。推荐负载比例：

向量检索：40% 关系和文档过滤：25% 时序窗口查询：15% 文档增量写入：10% 向量批量写入：5% 后台维护和审计：5%

真实联合 SQL：

WITHvalid_docsAS(SELECTd.document_id,d.title,d.metadataFROMknowledge_document dWHEREd.tenant_id=$2ANDd.status='published'ANDd.metadata @>'{"domain":"database"}'),recent_metricsAS(SELECTDISTINCTentity_idFROMsystem_metricWHEREtenant_id=$2ANDsystem_name='postgresql'ANDmetric_name='active_connections'ANDts>=now()-interval'15 minutes'ANDvalue>$3),candidateAS(SELECTc.chunk_id,c.document_id,1-(c.embedding<=>$1::vector)ASsimilarityFROMknowledge_chunk cJOINvalid_docs dONd.document_id=c.document_idJOINrecent_metrics mONm.entity_id=d.metadata->>'incident_id'WHEREc.status='active'ORDERBYc.embedding<=>$1::vectorLIMIT100)SELECTc.chunk_id,d.title,d.metadata,c.similarityFROMcandidate cJOINvalid_docs dONd.document_id=c.document_idORDERBYc.similarityDESCLIMIT10;

这条查询更接近真实生产链路，因为它同时使用关系、文档、时序和向量能力。

4.9 基线门禁

示例门禁：

查询成功率 >= 99.9% 向量查询 P95 <= 150 ms 联合查询 P95 <= 250 ms 联合查询 P99 <= 500 ms 错误率 <= 0.1% 缓存命中率 >= 90% 无明显临时文件暴增 导入期间在线查询 P95 增幅 <= 20%

对于召回型查询，还应增加业务质量指标：

Top-K 结果数量； 空结果率； 相关文档命中率； 重复文档率； 过期文档返回率； 权限过滤后的候选不足率。

5. 结果对比

以下为示例基线数据，数据集包含 200 万知识块、5000 万条时序事件，向量维度为 768。

阶梯压测示例：

优化前后对比：

这些示例结果不能替代生产压测。正式基线必须保存：

数据集版本； 查询集版本； 机器规格； 数据库参数； 索引参数； 并发度； 缓存模式； 压测脚本版本； 原始结果文件； 异常说明。

6. 风险与复盘

6.1 常见风险

6.2 上线检查清单

[ ] 已建立关系、文档、时序、向量四类查询基准集 [ ] 查询集包含 SQL、参数、预期结果和业务类型 [ ] 已固定数据集、数据库版本和索引参数 [ ] 已分别测试冷热缓存 [ ] 已记录 P50、P95、P99、错误率和结果数量 [ ] 已执行并发阶梯和混合负载压测 [ ] 已保存 EXPLAIN、BUFFERS 和资源指标 [ ] 已验证真实关系、文档、时序、向量联合查询 [ ] 已记录向量召回质量和空结果率 [ ] 已设置性能门禁和回滚规则 [ ] 基线结果已写入指标表并可长期趋势查询 [ ] 已完成压测环境与生产环境差异说明

6.3 复盘结论

多模查询性能基线的本质，是把“系统快不快”拆解为一组可重复的工程问题：

关系过滤是否使用正确索引； 文档 JSONB 条件是否造成大量扫描； 时序窗口是否触发过大范围聚合； 向量索引是否覆盖真实候选集合； 联合查询是否出现排序、回表或临时文件瓶颈； 导入、备份和维护是否影响在线查询； 结果数量和召回质量是否满足业务要求。

推荐的建设流程是：

采集真实查询 -> 建立分类基准集 -> 固定数据和运行参数 -> 执行冷热缓存测试 -> 执行阶梯并发测试 -> 执行混合负载测试 -> 记录延迟、资源和业务质量 -> 建立性能门禁 -> 持续对比版本变化

四类数据的职责可以概括为：

关系数据：精确过滤和业务状态； 文档数据：内容、标签和可解释信息； 时序数据：窗口、趋势和实时上下文； 向量数据：语义相关性和 Top-K 召回。

一个合格的性能基线必须能够说明：

1. 哪一类查询慢。
2. 慢在过滤、排序、聚合还是资源争抢。
3. 延迟在什么并发下开始恶化。
4. 模型、索引和切分策略变化带来什么影响。
5. 性能下降时是否伴随召回质量下降。
6. 数据库如何降级、限流和恢复。

当基准集、指标表、执行计划、资源监控和真实业务查询形成闭环后，性能基线就不再是一次性压测报告，而会成为综合数据库持续演进的判断依据。

转载自：https://blog.csdn.net/u014727709/article/details/165122969
欢迎 👍点赞✍评论⭐收藏，欢迎指正