...
Rejected Alternatives(optional)
The previous proposal of this MEP is let range search return all results with distances better than a "radius".
The project implementation of the previous proposal will be much more complicated than current proposal.
Cons:
- Knowhere will add new API QueryByRange() and parameter legacy check API CheckRangeSearch()
- Because the output format of range search is not unified with search, we need add new structure SubRangeSearchResult for range search
- Because range search returns all result (not topk), we need implement Merge operation for chunk, segment, query node and proxy
- every Merge operation will make the result size more bigger, system memory usage cannot be estimated, the GRPC bandwidth between server and client cannot be estimated
- TOPK is a required parameter in SDK, but not used by range search, it will make user confused
- TOPK is also a required parameter in many search related APIs, in this proposal, we have to change all these APIs to support without TOPK
Current proposal is better than previous one in all respectsIf there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other ways.
References(optional)
Milvus Search Flow
...