Storage-Optimized Disk Index (DiskANN)

Vamana graph

The Vamana graph is the core structure of DiskANN's disk-based strategy. Unlike HNSW's multi-layer structure, Vamana uses a single-layer sparse graph and builds it through two rounds of pruning. This approach maintains graph connectivity while introducing more long-range edges, reducing the number of hops needed for search convergence.

The construction process is as follows:

• Initial random connections: Each vector serves as a node in the graph. Nodes are initially connected randomly to form a dense network, typically with approximately 500 edges per node, to ensure connectivity.

• Two-round pruning optimization: Redundant edges are removed and low-quality connections are pruned based on node distance, prioritizing high-quality edges. The maximum number of edges per node is controlled by MaxDegree. Long-range edges are introduced, connecting distant data points in the vector space to create navigation shortcuts that speed up graph traversal. The breadth of neighbor search during graph construction is determined by SearchListSize.

In the open-source DiskANN implementation, each node's neighbor list and its full-precision vector are stored in the same disk sector. During search, a single disk read retrieves both the neighbor relationships and the original vector, enabling implicit reranking, but the entire search process involves extensive sequential disk I/O. Alibaba Cloud Milvus reorganizes the Vamana graph index in memory, eliminating disk I/O during the search process and only reading original vectors from disk during the final reranking phase.

RaBitQ quantization

RaBitQ (Random Bit Quantization) normalizes vectors and maps them to vertices of a hypercube, requiring only 1 bit per dimension. This compresses storage overhead and accelerates approximate distance computation between vectors.

In high-dimensional spaces, the angles between random vectors are highly concentrated. The quantization error when mapping to hypercube vertices converges at a rate of O(1/√d), meaning higher dimensions yield smaller quantization errors. In 768-dimensional space, the error from 1-bit quantization is already very small. Alibaba Cloud Milvus extends the standard 1-bit RaBitQ with a 4-bit extension mode, using 4 bits per dimension to encode residual information, balancing the compression ratio and accuracy.

Step 1: Plan memory and instance types

Use the following formulas to calculate the theoretical minimum memory required. Actual memory usage is slightly higher than the theoretical value. Reserve resources at 1.5x the theoretical value.

Performance mode:

Memory = Number of vectors × (Dimension / 2 + 228) bytes

Disk mode:

Memory = Number of vectors × (Dimension / 2) bytes

Taking 100 million 768-dimensional vectors as an example:

Step 2: Create a storage-optimized cluster

When creating an Alibaba Cloud Milvus instance, set the Compute NodeCU Type to Storage-optimized. After the cluster is created, no additional configuration is required — the DiskANN RaBitQ index type is used by default. When you create a collection with the index type set to AUTOINDEX, the system automatically selects DiskANN as the underlying index implementation.

For detailed instructions on creating an instance, see Quick start: Create a Milvus instance.

When using AUTOINDEX, describe_index returns the index type as AUTOINDEX and does not display the automatically matched underlying index. To verify the actual index type in effect, query segment-level information. If index_name is DISKANN, it indicates that DiskANN has been matched:

from pymilvus import connections, utility

connections.connect(uri="http://<endpoint>:19530", token="<user>:<password>")
for seg in utility.get_query_segment_info("<collection_name>"):
    print(seg.segmentID, seg.num_rows, seg.index_name)

Step 3: Switch deployment mode (optional)

The same DiskANN RaBitQ index supports two deployment modes. Choose the loading and search approach based on your business requirements:

If you have no specific cost reduction requirements, keep the default performance mode. Switch to disk mode only when memory cost is the primary constraint and your business can tolerate reduced query performance. Disk mode requires cluster version 2.6.18 or later.

Performance mode is used by default. Switching the deployment mode does not require rebuilding the index. The mode switch is completed during the load phase by releasing the collection, modifying collection properties, and reloading.

During the switch, the collection is released and reloaded. Query capability for the collection is briefly unavailable during this period. Perform this operation during off-peak hours.

Use the following Python script to complete the switch:

from pymilvus import MilvusClient

CLUSTER_ENDPOINT = "http://xxx-internal.milvus.aliyuncs.com:19530"
TOKEN = "<user>:<password>"
COLLECTION_NAME = "<collection_name>"

def set_diskann_mode(mode: str):
    client = MilvusClient(uri=CLUSTER_ENDPOINT, token=TOKEN, timeout=7200)
    # 1. Release collection
    client.release_collection(COLLECTION_NAME)
    # 2. Change deployment mode
    client.alter_collection_properties(
        COLLECTION_NAME,
        properties={"diskann.rabitq_mode": mode},
    )
    # 3. Reload
    client.load_collection(COLLECTION_NAME, timeout=7200)
    client.close()

if __name__ == '__main__':
    set_diskann_mode("disk")   # Switch to disk mode
    # set_diskann_mode("perf")  # Switch back to performance mode

Parameter description:

After the switch is complete, verify the current mode by checking the diskann.rabitq_mode field in the properties returned by describe_collection.

Index building parameters

The following parameters affect how the index is built. Adjusting them impacts index size, build time, and search quality.

Search parameters

The following parameters affect search behavior. Adjusting them impacts search speed, latency, and resource consumption.

The search parameters above only take effect when the data volume is sufficiently large. Collections with a small data volume perform exact search directly without going through the ANN index. In such cases, adjusting search_list, use_refine, or early_termination_threshold has no observable impact on recall or returned Distance values. Parameter tuning should be validated on datasets close to production scale.

Having too many segments in a collection noticeably affects query performance. Periodically trigger compaction through the management console or client API to reduce the number of segments.