issue: #49831 ## What changed Vendor Milvus design documents into this repository under `docs/design-docs` as regular tracked files. - Keep only the design document content and assets under `docs/design-docs/design_docs/` and `docs/design-docs/assets/`. - Remove standalone repository metadata from the vendored directory, such as `README.md`, `CONTRIBUTING.md`, `MEP-TEMPLATE.md`, `COMMITTERS`, `MAINTAINERS`, `OWNERS`, `OWNERS_ALIASES`, and `.gitignore`. - Document the Milvus design document process in the main `CONTRIBUTING.md`. - Update Mergify and `tools/mgit.py` so feature PRs must provide an in-repo design document path under `docs/design-docs/design_docs/`. ## Why Milvus feature work should have an associated design document. Keeping design docs directly in this repository makes them available from a normal Milvus checkout and lets feature implementations include or link the related design document in the same repository. ## Verification - `git diff --check` - `python3 -m unittest tools/test_mgit_design_doc.py` - `python3 -m py_compile tools/mgit.py tools/test_mgit_design_doc.py` - Parsed `.github/mergify.yml` with Python `yaml.safe_load` - Confirmed `docs/design-docs` only contains `assets/` and `design_docs/` at the top level --------- Signed-off-by: xiaofanluan <xiaofan.luan@zilliz.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
16 KiB
Milvus Search Order By Feature Design Document
Overview
The Order By feature enables users to sort vector search results by scalar fields instead of (or in addition to) the default distance/similarity score ordering. This is useful for scenarios where users want to prioritize results based on business-relevant attributes like price, timestamp, rating, etc.
Motivation
Vector search results are typically sorted by similarity score (distance). However, users often need to:
- Sort results by a business-relevant field (e.g., "sort by price ascending")
- Apply secondary sorting criteria after the primary vector similarity ranking
- Re-order grouped results (from group_by searches) based on scalar attributes
Feature Scope
Supported Operations
- Common Search: Single vector search with
order_by_fields - Hybrid Search: Multi-vector search with
order_by_fieldsin main search params - Search with Group By: Order by applies to groups (sorts groups by first row's value)
Cross-link: Query ORDER BY is documented separately in:
design_docs/20260203-query-orderby.md
Unsupported Combinations
- Search Iterator:
order_byis not supported when using search iterators - Function Score + Order By: Cannot use both simultaneously (conflicting sort criteria)
API Design
User Interface
Users specify order by fields via the order_by_fields search parameter:
# PyMilvus Example
collection.search(
data=[[0.1, 0.2, 0.3, ...]],
anns_field="embedding",
param={"metric_type": "L2", "params": {"nprobe": 10}},
limit=10,
order_by_fields=[
{"field": "price", "order": "asc"}
]
)
Syntax
order_by_fields = [
{
"field": "field_name", # Required: field name or JSON path
"order": "asc" | "desc" # Optional: default is "asc"
},
# ... additional fields for multi-field sorting
]
Field specification formats:
- Simple field:
{"field": "price", "order": "asc"} - Dynamic field:
{"field": "age", "order": "desc"}(automatically resolved from dynamic field storage) - Dynamic field with path:
{"field": "metadata[\"price\"]", "order": "asc"}(nested access in dynamic field) - Nested dynamic field path:
{"field": "user[\"profile\"][\"score\"]", "order": "desc"}
Note: JSON path is only supported for dynamic fields. Regular JSON fields (defined in schema) cannot be used for ordering.
Order options:
"asc"or"ascending": Sort in ascending order (default)"desc"or"descending": Sort in descending order
Supported Field Types
| Field Type | Supported | Notes |
|---|---|---|
| Bool | Yes | false < true |
| Int8/Int16/Int32/Int64 | Yes | Numeric comparison |
| Float/Double | Yes | Numeric comparison (NaN rejected at insert) |
| String/VarChar | Yes | Lexicographic comparison |
| JSON | No | Comparing JSON values on bytes is meaningless |
| Dynamic field subpath | Yes | Access via JSON path (e.g., age or metadata["price"]) |
| Array | No | Not sortable |
| Vector types | No | Not sortable |
Dynamic Field Support
Dynamic fields are fully supported. Access them directly by field name:
# Access dynamic field directly
order_by_fields=[
{"field": "age", "order": "desc"} # age is a dynamic field
]
# Multiple dynamic fields work the same as scalar fields
order_by_fields=[
{"field": "rating", "order": "desc"}, # dynamic field
{"field": "timestamp", "order": "asc"} # mixing with schema-defined scalar fields
]
Note: Dynamic fields are automatically resolved. If a field name is not found in the schema, Milvus will look for it in the dynamic field storage.
JSON Path Support (Dynamic Fields Only)
JSON path is only supported for dynamic fields, not for regular JSON fields. This is because Milvus currently only supports JSON path expressions for dynamic field storage. Ordering by a regular JSON field is not supported as comparing raw JSON bytes is meaningless.
Dynamic field subpaths can be accessed using bracket notation:
# Access dynamic field subpath
order_by_fields=[
{"field": "metadata[\"price\"]", "order": "asc"} # metadata is a dynamic field key
]
# Nested path in dynamic field
order_by_fields=[
{"field": "user[\"profile\"][\"score\"]", "order": "desc"} # user is a dynamic field key
]
# Multiple order by fields (mixing simple and nested dynamic fields)
order_by_fields=[
{"field": "price", "order": "asc"}, # simple dynamic field
{"field": "timestamp", "order": "desc"} # another dynamic field
]
Note: If you have a regular JSON field (defined in schema with JSON type), you cannot use it for ordering. Only dynamic fields support JSON path access for ordering.
Architecture
Data Flow
┌─────────────────────────────────────────────────────────────────────────────┐
│ Proxy (Search Task) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. Parse order_by_fields from search params │
│ 2. Validate field names against schema │
│ 3. Add order_by fields to output_fields for requery │
│ 4. Execute search on QueryNodes │
│ 5. Run search pipeline with order_by operator │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Search Pipeline │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌─────────┐ ┌───────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Reduce │ → │ Requery │ → │ Organize │ → │ Order By │ → │ End │ │
│ └──────────┘ └─────────┘ └───────────┘ └──────────┘ └──────────┘ │
│ │
│ For Hybrid Search: │
│ ┌──────────┐ ┌────────┐ ┌─────────┐ ┌───────────┐ ┌──────────┐ │
│ │ Reduce │ → │ Rerank │ → │ Requery │ → │ Order By │ → │ End │ │
│ └──────────┘ └────────┘ └─────────┘ └───────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Key Components
1. OrderByField Structure
// internal/proxy/search_util.go
type OrderByField struct {
FieldName string // Top-level field name for result lookup
FieldID int64 // Field ID for validation
JSONPath string // JSON Pointer format: "/price" or "/user/age"
Ascending bool // true for ASC, false for DESC
OutputFieldName string // Field name to request in requery
IsDynamicField bool // true if field is resolved from dynamic field storage
}
2. Search Info Extension
// internal/proxy/search_util.go
type SearchInfo struct {
planInfo *planpb.QueryInfo
offset int64
isIterator bool
collectionID int64
orderByFields []OrderByField // NEW: Order by specifications
}
3. Order By Operator
The orderByOperator is a pipeline operator that sorts search results:
// internal/proxy/search_pipeline.go
type orderByOperator struct {
orderByFields []OrderByField
groupByFieldId int64
groupSize int64
}
Implementation Details
Parsing Order By Fields
Location: internal/proxy/search_util.go:parseOrderByFields()
- Extract
order_by_fieldsparameter from search params (list of dictionaries) - For each dictionary in the list:
- Extract
"field"key as field name (required) - Extract
"order"key as direction (optional, default: "asc") - Handle JSON bracket notation in field name (e.g.,
metadata["price"]) - Resolve dynamic field references (fields not in schema are automatically looked up in dynamic field storage)
- Validate field against schema
- Build
OrderByFieldstruct with parsed values
- Extract
Pipeline Integration
Location: internal/proxy/search_pipeline.go
Two new pipeline definitions are added:
searchWithOrderByPipe (for common search):
reduce → merge_ids → requery → gen_ids → organize → pick → order_by
hybridSearchWithOrderByPipe (for hybrid search):
reduce → rerank → pick_ids → requery → organize → result → order_by
Order By Operator Execution
Location: internal/proxy/search_pipeline.go:orderByOperator.run()
- Validation: Verify all order_by fields exist in result
- Per-Query Sorting: For nq > 1, sort each query's results independently
- Group-By Handling: If group_by is active, sort groups by first row's value
- JSON Value Caching: Pre-extract JSON values to avoid repeated parsing
- Stable Sort: Use
sort.SliceStableto maintain original order for equal values - Result Reordering: Reorder all result arrays (IDs, scores, fields) based on sorted indices
Comparison Logic
Regular Fields
- Numeric types: Standard numeric comparison
- String types: Lexicographic comparison
- Bool: false < true
Dynamic Field Subpaths
- Extract value using JSON path from dynamic field storage
- Compare based on JSON value type (Number, String, Bool)
- Mixed types: Fallback to raw JSON string comparison
- NULLS FIRST: Missing or null values sort before non-null
Note: Regular JSON fields (defined in schema) are not supported for ordering because comparing JSON values on raw bytes is meaningless.
Null Handling
The implementation uses NULLS FIRST semantics:
- Null values (from nullable fields) sort before non-null values
- Non-existent JSON paths are treated as null
- Explicit JSON null values are treated as null
Error Handling
| Error Condition | Error Message |
|---|---|
| Missing "field" key | "missing 'field' key in order_by_fields entry" |
| Empty field name | "empty field name in order_by_fields" |
| Invalid direction | "invalid order direction 'X' for field 'Y' (must be 'asc', 'desc', 'ascending', or 'descending')" |
| Field not found | "order_by field 'X' does not exist in collection schema" |
| Unsortable type | "order_by field 'X' has unsortable type Y" |
| Regular JSON field | "order_by is not supported for JSON field 'X', use dynamic field with JSON path instead" |
| Iterator conflict | "order_by is not supported when using search iterator" |
| Function score conflict | "order_by and function_score cannot be used together" |
| Invalid JSON path | "invalid JSON path in order_by field 'X'" |
Performance Considerations
Optimizations Implemented
- JSON Value Caching: Pre-extract JSON values before sorting to avoid O(n log n) extractions
- Sparse Cache for nq > 1: Only cache values for indices being sorted
- Field Data Map: Build O(1) lookup map for field data
- Stable Sort: Maintain original order stability without additional comparison overhead
Complexity Analysis
| Operation | Time Complexity | Space Complexity |
|---|---|---|
| Parsing | O(f * k) | O(f) |
| JSON Extraction | O(n * f) | O(n * f) |
| Sorting | O(n log n * f) | O(n) |
| Reordering | O(n * d) | O(n * d) |
Where:
- n = number of results
- f = number of order_by fields
- k = average JSON path depth
- d = number of output fields
Limitations
- Requery Required: Order by always triggers a requery to fetch field values
- Memory Overhead: All order_by field data must be loaded into memory
- Single Proxy Sorting: Sorting happens entirely at the Proxy level
- No Regular JSON Field Support: Regular JSON fields (defined in schema) cannot be used for ordering because Milvus only supports JSON path for dynamic fields, and comparing raw JSON bytes is meaningless
Testing
Unit Tests
Location: internal/proxy/search_pipeline_test.go
Coverage includes:
- Basic field ordering (ascending/descending)
- Multiple order_by fields
- Dynamic field subpath extraction
- Dynamic field support
- Group-by integration
- Null value handling
- nq > 1 scenarios
- Edge cases (empty results, single result)
- Regular JSON field rejection
Test Categories
- Parsing Tests: Validate order_by_fields parameter parsing
- Comparison Tests: Verify comparison logic for all data types
- Pipeline Tests: End-to-end pipeline execution with order_by
- Error Tests: Verify error conditions are properly handled
Files Modified
| File | Changes |
|---|---|
internal/proxy/search_util.go |
OrderByField struct, parseOrderByFields() for parsing dictionary entries |
internal/proxy/search_pipeline.go |
orderByOperator, pipeline definitions, comparison functions |
internal/proxy/task_search.go |
orderByFields field, pipeline integration |
internal/proxy/task.go |
OrderByFieldsKey constant |
internal/proxy/search_pipeline_test.go |
Unit tests for dictionary-based order_by_fields |
Query ORDER BY (Moved)
The Query ORDER BY design has been separated into:
design_docs/20260203-query-orderby.md
Future Improvements
- Push-down Optimization: Push order_by to QueryNode for early sorting
- Index-based Sorting: Leverage scalar indexes for efficient sorting
- Pagination Support: Combine with offset/limit for efficient pagination
- Expression-based Ordering: Support computed expressions (e.g.,
price * quantity)
Appendix
Dynamic Field JSON Path Conversion
For dynamic fields, JSON Pointer (RFC 6901) is converted to gjson path format:
JSON Pointer uses / as separator:
/user/name→user.name~0→~(escaped tilde)~1→/(escaped slash)
gjson uses . as separator:
- Dots in keys escaped with
\.
Example: /key~1with~1slash → key\/with\/slash (single key with slashes)
Note: This conversion only applies to dynamic fields. Regular JSON fields (defined in schema) are not supported for ordering.
Requery Field Selection
The requeryOperator unions order_by fields with output fields:
for _, orderByField := range t.orderByFields {
outputFieldNames.Insert(orderByField.OutputFieldName)
}
This ensures order_by field data is fetched even if not explicitly requested.