Rate This Document
Findability
Accuracy
Completeness
Readability

Open Source Milvus Reference Architectures

Scenarios

Milvus is built on popular vector search libraries such as Faiss, HNSW, DiskANN, and ScaNN. It is designed for similarity search on dense vector datasets that contain millions, billions, or even trillions of vectors.

Working Mechanism

Milvus can run in two modes: standalone and cluster. The two modes have the same functions.

Milvus Standalone

Milvus standalone consists of the following components:

  • Milvus: The core functional component.
  • Meta Store: The metadata engine is used to access and store metadata of internal components (including proxies and index nodes) of Milvus.
  • Object Storage: The storage engine, which is responsible for data persistence for Milvus.
Figure 1 Architecture of Milvus Standalone

Milvus Cluster

Milvus cluster consists of seven microservice components and three third-party dependencies. All microservices can be independently deployed on Kubernetes.

The seven microservice components are the root coordinator, proxy, query coordinator, query node, data coordinator, index node, and data node.

The three third-party dependencies are as follows:

  • Meta Store: Store metadata of various components in a cluster, such as etcd.
  • Object Storage: Implement data persistence of large files such as indexes and binary log files in a cluster, for example, S3 and MinIO.
  • Log Broker: Manage logs of recent sudden changes, output streaming logs, and provide log publishing and subscription services, such as Kafka and Pulsar.
Figure 2 Architecture of Milvus Cluster

Architectures and Principles

Figure 3 Milvus architecture

Milvus divides the overall architecture into four layers, which are independent of each other in terms of scalability and disaster recovery.

  • Access layer

    Access layer consists of a group of stateless proxies. It is the front layer of the system and the endpoint to the user. Access layer validates client requests and reduces the number of returned results. It uses a series of load balancing components to provide a unified service address. In addition, Milvus employs the massively parallel processing (MPP) architecture, which enables Milvus to aggregate and process the intermediate results of queries and return the final results to the client.

  • Coordinator services

    The coordinator service layer assigns tasks to worker nodes, functioning as the brain of the system. It manages cluster topologies, load balancing, timestamp generation, data, and data declarations. This layer consists of the root coordinator, data coordinator, and query coordinator.

  • Worker nodes

    A worker node is a dumb executor that follows the instructions of the coordinator service and executes data manipulation language (DML) commands from the proxy. Due to the separation of storage and computation, the worker node is stateless. It consists of query nodes, data nodes, and index nodes.

  • Object storage

    The object storage layer is responsible for data persistence. It includes metadata storage, log broker, and object storage.