Resource Groups
Relevant source files
The following files were used as context for generating this wiki page:
Resource Groups in the Milvus Rust SDK provide a mechanism to manage and isolate computing resources for different workloads. They allow administrators to partition query nodes and allocate specific resources to various collections or replicas, ensuring performance isolation and efficient resource utilization within a Milvus cluster.
Sources: src/resource_group.rs:1-6, src/proto/milvus.proto.rg.rs:25-30
Architecture and Components
The Resource Group system is built upon a hierarchical configuration model that defines how nodes are requested, limited, and transferred between groups. At its core, a resource group manages a set of Milvus nodes and tracks their availability and load.
Core Data Structures
The system uses several protobuf-defined messages to manage state and configuration:
- ResourceGroupConfig: The primary configuration object containing requests, limits, and transfer rules.
- ResourceGroupLimit: Defines the number of nodes (capacity) associated with a specific limit or request.
- ResourceGroupTransfer: Defines priority-based lists for transferring nodes from or to other groups.
- ResourceGroup (Response Object): Contains runtime statistics, including available nodes, loaded replicas, and incoming/outgoing node counts.
Sources: src/proto/milvus.proto.rg.rs:1-38, src/proto/milvus.proto.milvus.rs:1072-1100
Resource Group Lifecycle
The following diagram illustrates the lifecycle and management operations of a Resource Group:
Configuration and Options
The SDK provides a builder pattern through CreateRgOptions (aliased as UpdateRgOptions) to configure how a group behaves when it has redundant or insufficient resources.
Configuration Parameters
| Parameter | Type | Description |
|---|---|---|
requests | i32 | Minimum number of nodes allocated to the group. If lower, nodes are transferred in. |
limits | i32 | Maximum number of nodes allowed. If higher, nodes are transferred out. |
transfer_from | Vec<String> | Priority list of source groups to pull nodes from when under capacity. |
transfer_to | Vec<String> | Priority list of target groups to push nodes to when over capacity. |
node_filter | Vec<KeyValuePair> | Labels used to determine which specific nodes can be assigned to the group. |
Sources: src/resource_group.rs:55-170, src/proto/milvus.proto.rg.rs:25-38
API Operations
The Client struct implements several asynchronous methods for managing resource groups. These methods interact with the Milvus proxy via gRPC.
Management Methods
create_resource_group: Initializes a new group. It sends aCreateResourceGroupRequestcontaining the group name and optionalResourceGroupConfig.describe_resource_group: Retrieves aResourceGroupobject containing current status, such asnum_available_nodeandnum_loaded_replica.list_resource_groups: Returns a vector of all existing resource group names.drop_resource_group: Deletes a group and releases its allocated nodes.update_resource_groups: Allows bulk updating multiple configurations using aHashMap.
Sources: src/resource_group.rs:177-380, src/proto/milvus.proto.milvus.rs:1008-1065
Resource Transfer Logic
Nodes and replicas can be moved dynamically between groups to rebalance the cluster.
Usage Example
The following snippet demonstrates creating, updating, and cleaning up a resource group using the SDK.
let options = CreateRgOptions::new()
.limits(10)
.requests(2);
// Create the group
client.create_resource_group("test_rg", Some(options)).await?;
// Update the group (scaling down)
let update_options = UpdateRgOptions::new().limits(5).requests(1);
let mut configs = HashMap::new();
configs.insert("test_rg".to_string(), update_options);
client.update_resource_groups(configs).await?;
// Clean up
client.drop_resource_group("test_rg").await?;
Sources: src/resource_group.rs:205-220, examples/resource_groups.rs:24-51
Conclusion
Resource Groups provide the necessary abstraction for multi-tenancy and workload management in Milvus. By leveraging CreateRgOptions and transfer APIs, developers can ensure that critical search workloads have guaranteed query node capacity while maintaining the flexibility to reallocate resources across the cluster as demand fluctuates.
Sources: src/resource_group.rs:1-10, src/proto/milvus.proto.rg.rs:25-38