Does Milvus Optimize to Reduce the Number of TopK Queries at Runtime?

[zetta-cai]

Dear milvus developers,

I came across the file milvus/internal/util/searchutil/optimizers/query_hook.go in the Milvus source code and was wondering if Milvus supports specific optimization strategies for search parameters.

Is there any existing optimization to reduce the number of lookups at runtime? I am aware of the segment pruning optimization in internal/querynodev2/delegator/segment_pruner.go, but I’m curious if additional strategies are implemented for this purpose.

Looking forward to any insights—thanks!

[yhmo]

In milvus, data is organized by segments. Each segment has an independent index.
To process a search request:

1. each segment is searched to output a topk result
2. each query node compute N segments to putput N * topk results, and reduce them to a topk result
3. each shard leader manages M query nodes, and receive M * topk results, and reduce them to a topk result
4. each collection has K shards, so there will be K shard leaders, proxy node will receive K * topk results, and reduce them to a final topk result

[zetta-cai]

Thanks for your detailed explanation!

My main point is to explore whether we can optimize the number of topK computations at different segments to improve search efficiency.

segment_pruner is used to reduce n → n' (fewer segments searched).
query_hook is used to reduce k → k' (fewer candidates per segment).
However, I found that query_hook.go only provides a hook interface and does not provide any specific optimization strategies.

Would love to hear your thoughts on whether such an optimization exists or could be implemented efficiently!

[yhmo]

• The PruneSegments() in segment_pruner.go only takes effect when there is a clustering key in collection schema.
  

  milvus/internal/querynodev2/delegator/segment_pruner.go

  Line 50 in be4d095

  clusteringKeyField := clustering.GetClusteringKeyField(schema)

  
  With clustering key, all data is organized into segments with a certain sequence, so that PruneSegments() can quickly know which segment can be skipped for search.

• The OptimizeSearchParams() in query_hook.go accepts a QueryHook interface. QueryHook is a plugin which is loaded in querynode initialization:

  milvus/internal/querynodev2/server.go

  Line 556 in be4d095

  h, err := p.Lookup("QueryNodePlugin")

  
  The main purpose of OptimizeSearchParams() is for optimization of "AUTOINDEX" in zilliz cloud instances, to determine better parameters for search requests with "AUTOINDEX". For open-source milvus , the QueryHook is always null and OptimizeSearchParams() doesn't take effect.
  

  milvus/internal/util/searchutil/optimizers/query_hook.go

  Line 29 in be4d095

  if queryHook == nil || !paramtable.Get().AutoIndexConfig.Enable.GetAsBool() {

[zetta-cai]

Your answer helped me a lot, thank you very much!