存储/计算分解

Milvus 遵循数据平面和控制平面分解的原则，由四层组成，在可扩展性和灾难恢复方面相互独立。

接入层

访问层由一组无状态代理组成，是系统的前端层，也是用户的终端。它验证客户端请求并减少返回结果：

• 代理本身是无状态的。它使用 Nginx、Kubernetes Ingress、NodePort 和 LVS 等负载均衡组件提供统一的服务地址。
• 由于 Milvus 采用的是大规模并行处理（MPP）架构，代理会汇总并后处理中间结果，然后将最终结果返回给客户端。

协调服务

协调器服务将任务分配给工作节点，起到系统大脑的作用。它承担的任务包括集群拓扑管理、负载平衡、时间戳生成、数据声明和数据管理。

协调器有三种类型：根协调器（root coordinator）、数据协调器（data coordinator）和查询协调器（query coordinator）。

根协调器（根协调器）

根协调器处理数据定义语言（DDL）和数据控制语言（DCL）请求，如创建或删除集合、分区或索引，以及管理 TSO（时间戳 Oracle）和时间刻度签发。

查询协调器（查询协调器）

查询协调器负责管理查询节点的拓扑结构和负载平衡，以及从增长网段到封存网段的切换。

数据协调器（数据协调器）

数据协调器管理数据节点和索引节点的拓扑结构，维护元数据，并触发刷新、压缩和索引构建以及其他后台数据操作。

工作节点

手臂和腿。工作节点是哑执行器，它们遵从协调器服务的指令，执行来自代理的数据操作语言（DML）命令。由于存储和计算分离，工作节点是无状态的，部署在 Kubernetes 上时可促进系统扩展和灾难恢复。工作节点有三种类型：

查询节点

查询节点通过订阅日志代理检索增量日志数据并将其转化为不断增长的片段，从对象存储中加载历史数据，并在向量和标量数据之间运行混合搜索。

数据节点

数据节点通过订阅日志代理检索增量日志数据，处理突变请求，将日志数据打包成日志快照并存储在对象存储中。

索引节点

索引节点构建索引。 索引节点不需要常驻内存，可以使用无服务器框架来实现。

存储

存储是系统的骨骼，负责数据持久性。它包括元存储、日志代理和对象存储。

元存储

元存储存储元数据的快照，如收集模式和消息消耗检查点。元数据的存储要求极高的可用性、强一致性和事务支持，因此 Milvus 选择 etcd 作为元存储。Milvus 还使用 etcd 进行服务注册和健康检查。

对象存储

对象存储用于存储日志快照文件、标量和向量数据的索引文件以及中间查询结果。Milvus 使用 MinIO 作为对象存储，可随时部署在 AWS S3 和 Azure Blob 上，这是世界上最流行、最具成本效益的两种存储服务。然而，对象存储的访问延迟较高，并按查询次数收费。为了提高性能并降低成本，Milvus 计划在基于内存或固态硬盘的缓存池上实现冷热数据分离。

日志代理

日志代理是一个支持回放的发布子系统。它负责流数据持久化和事件通知。当工作节点从系统故障中恢复时，它还能确保增量数据的完整性。Milvus 集群使用 Pulsar 作为日志代理；Milvus 单机版使用 RocksDB 作为日志代理。此外，日志代理可以随时替换为 Kafka 等流式数据存储平台。

Milvus 围绕日志代理构建，遵循 "日志即数据 "原则，因此 Milvus 不维护物理表，而是通过日志持久化和快照日志来保证数据的可靠性。

日志机制

日志代理是 Milvus 的支柱。它负责数据持久性和读写分解，这要归功于其与生俱来的发布-子机制。上图是对该机制的简化描述，其中系统分为两个角色：日志代理（负责维护日志序列）和日志订阅者。前者记录所有改变收集状态的操作；后者订阅日志序列以更新本地数据，并以只读副本的形式提供服务。在变更数据捕获（CDC）和全局分布式部署方面，pub-sub 机制还为系统的可扩展性留出了空间。

下一步

• 阅读 "主要组件"，了解有关 Milvus 架构的更多详情。