TechPrufer
Get started
Milvus
Milvus logoMilvus · Feature trail

Milvus Cloud-Native Architecture

2 posts · Jul 2021 – May 2022

What this trail covers

Milvus 2.0 introduces a cloud-native architecture with storage and computing separation, microservices, and a log-centric design. It unifies batch and stream processing using a Lambda architecture, supports hybrid search between scalar and vector data, offers tunable consistency, and implements time travel for data rollback. Key features include enhanced reliability through "fail cheap, fail small, fail often" principles, an ORM Python SDK, and supporting tools like Milvus Insight and Prometheus. This post discusses the limitations of consensus-based replication like Raft and proposes a log replication strategy for cloud-native and distributed databases, emphasizing replication as a service and the Russian doll principle. Milvus's tunable consistency is similar to follower reads in consensus-based replication, enhancing cluster throughput and reducing leader load.

All Milvus trails
  1. Raft or not? The Best Solution to Data Consistency in Cloud-native DatabasesThis post analyzes the limitations of consensus-based replication algorithms like Raft and Paxos in cloud-native databases, particularly concerning availability, complexity, and performance in shared storage environments. It proposes a log replication strategy that decouples synchronization from storage (replication as a service) and leverages third-party services for leader election (Russian doll principle). The post highlights Milvus's tunable consistency as a feature similar to follower reads, which improves throughput and reduces leader load, aligning with the proposed principles by avoiding strict consensus for all operations.
  2. Evolution of Milvus Cloud-scalable Vector DatabaseThis post details the design principles and considerations for Milvus 2.0's cloud-native cluster architecture. It contrasts with traditional shared-everything clusters, highlighting the challenges of global locking and buffer cross-invalidation in cloud environments. The post explains the decision to adopt eventual consistency for the in-memory data cache and the use of cloud messaging queues (like Pulsar/Kafka) for log storage instead of SAN, enabling asynchronous operations, loose coupling, and easier rolling upgrades. It also touches upon data management with segments and partitions.
  3. Milvus 2.0 Redefining Vector DatabaseThis post details the architectural shift to Milvus 2.0, emphasizing cloud-native principles, storage/computing separation, microservices, and a log-centric design. It introduces a Lambda architecture for unified batch/stream processing, hybrid search capabilities, tunable consistency, and time travel. The system architecture is broken down into access, coordinator, worker, and storage layers, with specific implementations for meta storage (etcd), log broker (Pulsar), and object storage (MinIO/S3). It also highlights the ORM Python SDK and supporting tools like Milvus Insight.