Milvus的存储/计算分离

前言

根据数据面与控制面相隔离的原则，从可扩展性和灾难恢复来看，Milvus由4个相互独立的层组成

访问层

由一系列无状态的代理组成，访问层是系统和用户之间的第一层，它主要是验证客户端请求和规整返回的结果

• 代理是无状态的，它使用负载均衡组件例如Nginx, Kubernetes Ingress, NodePort和LVS提供统一的服务地址
• 因为Milvus采用大规模并行处理架构，代理需要在返回给客户端最终结果之前合并和后置处理中间结果

协调服务

协调服务将任务分配给工作节点，它起到系统大脑的作用。它处理的任务包括：集群拓扑图管理，负载均衡，时间戳生成，数据申报和数据管理。

有三种类型的协调者：根协调者，数据协调者，查询协调者

根协调者

根协调者处理DDL和DML请求，比如创建和删除集合，分区或者索引，也会像管理TSO(oracle时间戳)和发布时间心跳

查询协调者

查询协调者管理查询节点的拓扑图和负载均衡，从不断增长的段切换到封闭的段。

数据协调者

数据协调者管理数据节点和索引节点的拓扑图，维护元数据，触发刷新，压缩和索引构建以及其他数据底层操作。

工作节点

类似于人的胳膊和腿，工作节点无脑的执行协调服务的指令和执行代理的DML命令。得益于存储和计算的分离，工作节点是无状态的，当部署在kubernates时，它促进了系统的扩展性和灾难恢复。有三种类型的工作节点

查询节点

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

数据节点

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

索引节点

索引节点构建索引，索引节点不需要驻留在内存中，并可以被serverless 框架实现

存储

存储是系统的骨干，负责数据的持久化。它由元数据存储，日志代理和对象存储组成

元数据存储

元数据存储存储元数据的快照，比如集合schema,消息消费的checkpoint。存储元数据要求极高的可用性，强一致性和事务支持。所以milvus选择etcd作为元数据存储。milvus也使用etcd作为服务注册和健康检测。

对象存储

对象存储存储日志文件的快照、标量和向量数据的索引文件，中间查询结果。milvus使用minIO作为中间存储，能非常方便的部署在AWS S3和 Azure Blob，二者都是世界受欢迎的，性价比非常高的存储服务。然后对象存储具有很高的访问延迟，并按查询次数收费。为了提高它的性能和降低费用，milvus计划在内存或者基于SSD的缓存池实现冷热数据分离

日志代理

日志代理是一个发布订阅系统，并支持回放。它负责流式数据的持久化和事件通知。当工作节点从系统崩溃中恢复的时候它也需要确保增量数据的完整性。milvus集群使用pulsar作为日志代理；milvus独立部署使用rocksDB作为日志代理。此外，日志代理可以很容易地被诸如Kafka之类的流数据存储平台所取代。

milvus围绕着日志代理建设，并秉承日志就是数据的理念，所以milvus没有使用物理表而是通过日志持久化和日志快照来保证数据可靠性。

日志代理是milvus的骨干。由于其天生的发布订阅机制，它负责数据持久化和读写分离。上面的图例简单描绘了该机制，该系统分为两个角色，日志代理（维护log sequence）和日志订阅者。前者记录所有改变集合状态的操作，后者订阅订阅log sequence来更新本地数据，并以只读副本的形式提供服务。发布订阅机制还在变更数据捕获（CDC）和全球分布式部署方面为系统的可扩展性腾出了空间。