Weaviate 推出查询性能剖析功能，按分片拆解检索延迟来源
A slow query is easy to spot. Explaining 𝘸𝘩𝘺 it's slow is the hard part. The latency could come ...
Weaviate 上线了查询剖析功能，能告诉你慢在 HNSW、过滤还是磁盘读取，示例里 48.2ms 有 36.8ms 花在对象回取，调优前先看这个。
Weaviate 正式发布 Query Profiling 功能，在请求 metadata 中设置 query_profile 即可随响应返回耗时明细，按 shard 和 node 组织。协调节点会汇总所有相关分片的计时数据，分布式查询不再需要手工拼接多个节点的日志。官方示例中一个耗时 48.2ms 的分片，向量搜索仅占 8.4ms、过滤器解析 2.1ms，而对象回取（Object hydration）占 36.8ms，说明瓶颈往往不在 HNSW 图遍历，而在 page-cache 未命中、存储延迟或返回对象过大。
A slow query is easy to spot. Explaining 𝘸𝘩𝘺 it's slow is the hard part. The latency could come ...
A slow query is easy to spot. Explaining 𝘸𝘩𝘺 it's slow is the hard part. The latency could come from HNSW traversal, resolving a filter, BM25 scoring, compression rescoring, or fetching objects from disk. Each points to a completely different fix. 𝗤𝘂𝗲𝗿𝘆 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 𝗶𝗻 𝗪𝗲𝗮𝘃𝗶𝗮𝘁𝗲 makes that breakdown available for each specific search. Set 𝗾𝘂𝗲𝗿𝘆_𝗽𝗿𝗼𝗳𝗶𝗹𝗲 in the request metadata and the profile is returned alongside the response, organized by shard and node. The coordinating node collects timings from every shard involved, so distributed queries no longer require manually piecing together logs from multiple nodes. Consider a shard that takes 48.2ms: • Vector search: 8.4ms • Filter resolution: 2.1ms • Object hydration: 36.8ms HNSW isn't the bottleneck here. Object hydration is. Blindly increasing compute would miss the problem entirely. Page-cache misses, storage latency, a large result limit, or oversized objects are the more useful places to investigate. 𝗤𝘂𝗲𝗿𝘆 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 is generally available weaviate.io/blog/query-pro… rn more about it in our blog: https://t.co/KczBA52Onp 💬 0 🔄 3 ❤️ 5 👀 245 📊 2 ⚡