Manage Aliases-Vector Retrieval Service for Milvus(Milvus)-阿里云帮助中心

In Milvus, an alias serves as a logical address for a collection, allowing application code to access data through a fixed alias, such as product_embeddings. This enables Operations and Maintenance (O&M) engineers to seamlessly switch the underlying collection that the alias points to in the background without requiring any code changes. In simple terms, an alias is a movable tag for a collection that is recognized by applications. When you switch data, you only need to change the tag, and users will remain unaware of the change. This process decouples applications from the physical data.

Scenarios

This feature is crucial for achieving high availability and agile O&M in production environments. It is particularly useful for the following scenarios:

Zero-downtime data updates: You can smoothly switch to a new collection with updated data without interrupting online services.
A/B testing: You can easily implement traffic splitting and compare results by assigning aliases that point to different collections for different user groups or requests. For example, the collections can have different index or model versions.
Blue-green deployment: Aliases are the foundation for atomic operations that enable blue-green deployment strategies for the Vector Retrieval Service.

Constraints of Aliases

A collection can be associated with multiple aliases.
An alias can only point to one unique collection at any given time.

Prerequisites

The PyMilvus library is installed on your local client and is updated to the latest version.
To install or update the PyMilvus library, run the following command.
```
pip install --upgrade pymilvus
```
A Milvus instance has been created. For more information, see Create a Milvus instance.

Alias Management API

Create an Alias

from pymilvus import MilvusClient

client = MilvusClient(
    uri="http://localhost:19530",
    token="root:xxx"
)

client.create_alias(
    collection_name="milvus_collection",
    alias="bob"
)

client.create_alias(
    collection_name="milvus_collection",
    alias="alice"
)

List Aliases

res = client.list_aliases(
    collection_name="milvus_collection"
)
print(res)

The following result is returned upon successful execution:

{
  "aliases": ["bob", "alice"],
  "collection_name": "milvus_collection",
  "db_name": "default"
}

Describe an Alias

res = client.describe_alias(
    alias="bob"
)
print(res)

The following result is returned upon successful execution:

{
  "alias": "bob",
  "collection_name": "milvus_collection",
  "db_name": "default"
}

Alter an Alias

# Create Collection2 named milvus_collection2.
client.create_collection(
    collection_name="milvus_collection2",
    dimension=5
)
# Change alice to an alias for collection milvus_collection2.
client.alter_alias(
    collection_name="milvus_collection2",
    alias="alice"
)
res = client.describe_alias(
    alias="alice"
)
print(res)

The following result is returned upon successful execution:

{
  "alias": "alice",
  "collection_name": "milvus_collection2",
  "db_name": "default"
}

Delete an Alias

client.drop_alias(
    alias="bob"
)

Alias Use Case: Seamless Online Index Switching

Background

Suppose you have created an incorrect index configuration, such as an incorrect index type or parameters, in a production environment. The business system is currently using this configuration online, and the goal is to minimize the impact on online services.

Core objective: Re-index a collection in Milvus with minimal or no impact on business operations.

Key strategy: Use a dual-write, dual-collection, and alias-switching strategy. This strategy ensures that you can perform a quick rollback at any stage.

Implementation Steps

Phase 1: Preparation and Dual-Write Transformation

Create a new collection, for example, collection_new_v2, based on the new index requirements. The schema of the new collection must be consistent with the old collection, collection_old.
Modify the business code to write data to both the old collection (collection_old) and the new collection (collection_new_v2) when performing insert, delete, or update operations.

Phase 2: Data Synchronization and Index Building

Use the data migration feature to perform a full synchronization of historical data from the old collection (collection_old) to the new collection (collection_new_v2). You can use a timestamp column to synchronize data created before a specific time.
Write a validation script to randomly sample or fully compare the data volume and key field consistency between the two collections. This ensures the accuracy of both the dual-writes and the historical data synchronization.
After data synchronization and successful validation, execute the index creation operation on the new collection (collection_new_v2).

Phase 3: Preloading and Resource Preparation

Scale out the QueryNode to allow the cluster to load both the old and new collections simultaneously. Reserve a memory buffer, for example, 20%, to handle traffic fluctuations.
Load the new collection (collection_new_v2).
After the new collection is loaded, use a dedicated test interface or a small amount of read traffic to verify that the query function is normal and that its performance meets expectations.

Phase 4: Alias Switching

Perform the switch during an off-peak business period.
Rename the old collection (collection_old) to a different name, such as collection_service_backup.
Add the new collection collection_new_v2 to the service alias, such as collection_service.
Monitor business operations after the switch.
To roll back, add the old collection (collection_old) to the business alias (collection_service) and remove the new collection (collection_new_v2) from the business alias (collection_service).

Phase 5: Cleanup and Cost Optimization

After the switch, monitor business operations. If everything is normal, you can release the old collection, collection_old.
Releasing the old collection reduces cluster memory usage. You can then safely unpublish the extra QueryNode that was scaled out in the previous steps. This restores the cluster to its original cost level.
After you confirm that all data and applications are running stably and the old collection is no longer needed, you can delete the old collection (collection_old) to free up disk space. Before deleting it, perform a final data backup or snapshot.
Clean up the dual-write code in your business applications. You can disable the dual-write configuration if it is no longer needed.