Milvus 1.0 所面临的挑战
写节点是一个单点，无法横向扩展。
读节点的扩展基于一致性 hash 进行路由。一致性哈希尽管实现简单，但数据调度不够灵活，仅仅解决了数据分布均匀性的问题，不能很好地解决数据和算力不匹配的问题。
依赖 MySQL 管理元数据——单机 MySQL 能支持的查询量和数据量都有限。
Milvus 2.0 版本的诞生
架构设计理念
围绕以下三个理念，我们重新定义下一代云原生向量数据库：
云原生优先：我们认为，只有存储计算分离的架构才能发挥云的弹性，实现按需扩容的模式。另一个值得注意是 Milvus 2.0 采取了读写分离、实时离线分离、计算瓶颈/内存瓶颈/IO瓶颈分离的微服务化设计模式，这有助于我们面对复杂的工作负载选择最佳的资源配比。
日志即数据：Milvus 引入消息存储作为系统的骨架，数据的插入修改只通过消息存储交互，执行节点通过订阅消息流来执行数据库的增删改查操作。这一设计的优势在于降低了系统的复杂度，将数据库关键的持久化和闪回等能力都下钻到存储层；另一方面，日志订阅机制提供了极大的灵活性，为系统未来的拓展奠定了基础。
批流一体：Milvus 2.0 实现了 unified Lambda 流式处理架构，增量数据和离线数据一体化处理。相比 Kappa 架构，Milvus 引入对日志流的批量计算将日志快照和构建索引存入对象存储，这大大提高了故障恢复速度和查询效率。为了将无界的流式数据拆分成有界的窗口，Milvus 采用 watermark 机制，通过写入时间（也可以是事件发生时间）将数据切分为多个小的处理单元，并维护了一条时间轴便于用户基于某个时间点进行查询。
系统组件
系统框架图
接入层：系统的门面，包含了一组对等的 proxy 节点。接入层是暴露给用户的统一 endpoint，负责转发请求并收集执行结果。
协调服务：系统的大脑。总共有四类协调者角色，分别为 root coord、data coord、query coord 和 index coord。
执行节点：系统的四肢。执行节点只负责被动执行协调服务发起的命令，响应接入层发起的读写请求。目前有三类执行节点，即 data node、query node 和 index node。
存储服务：系统的骨骼。Milvus 依赖三类存储：元数据存储、消息存储和对象存储。元数据存储便于协调服务存储 collection schema、数据消费位点等元信息，基于 etcd 实现。消息存储主要用于存储系统增量日志数据，实现可靠的异步通知机制，目前基于 Pulsar 实现。对象存储主要用于存储日志快照和索引数据，目前基于 MinIO 或 S3 实现。
功能亮点
Milvus 2.0 作为一款开源分布式向量数据库产品，始终将产品的易用性放在系统设计的第一优先级。一款数据库的使用成本不仅包含了运行态的资源消耗成本，也包含了运维成本和接入学习成本。Milvus 新版本支持了大量降低用户使用成本的功能。
实现数据的可靠存储和可持续的服务是对数据库产品的基本要求。我们的理念是 Fail cheap, fail small, fail often。Fail cheap 指的是 Milvus 采取的存储计算分离架构，节点失败恢复的处理十分简单，且代价很低。Fail small 指的是 Milvus 采取分而治之的思想，每个协调服务仅处理读/写/增量/历史数据中的一个部分，设计被大大简化。Fail often 指的是混沌测试的引入，通过故障注入模拟硬件异常、依赖失效等场景，加速问题在测试环境被发现的概率。
为了解决结构化数据和非结构化数据的割裂问题，Milvus 2.0 支持标量存储和向量标量混合查询。混合查询帮助用户找出符合过滤表达式的近似邻，目前 Milvus 支持等于、大于、小于等关系运算以及 NOT、AND、OR 、IN 等逻辑运算。
Milvus 2.0 是基于消息存储构建的分布式数据库，遵循 PACELC 定理所定义的，必须在一致性和可用性/延迟之间进行取舍。绝大多数 Milvus 场景在生产中不应过分关注数据一致性的问题，原因是接受少量数据不可见对整体召回率的影响极小，但对于性能的提升帮助很大。尽管如此，我们认为强一致性、有界一致性、会话一致性等一致性保障语义依然有其独特的应用场景。比如，在功能测试场景下，用户可能期待使用强一致语义保证测试结果的正确性，因此 Milvus 支持请求级别的可调一致性级别。
数据工程师经常会因为脏数据、代码逻辑等问题需要回滚数据。传统的数据库通常通过快照方式来实现数据回滚，有时甚至需要重新训练，带来高昂的额外开销和维护成本。Milvus 对所有数据增删操作维护了一条时间轴，用户查询时可以指定时间戳以获取某个时间点之前的数据视图。基于 Time Travel，Milvus 还可以很轻量地实现备份和数据克隆功能。
对象关系映射（Object Relational Mapping）技术使用户更加关注于业务模型而非底层的数据模型，便于开发者维护表、字段与程序之间的关联关系。为了弥补 AI 算法概念验证（Proof of concept）到实际生产部署之间的缺口，我们设计了 Milvus ORM API，而其背后的实现可以是通过嵌入式的 Library、单机部署、分布式集群，也可能是云服务。通过统一的 API 提供一致的使用体验，避免云端两侧重复开发、测试与上线效果不一致等问题。
1. 图形化管理界面：Milvus Insight 是 Milvus 图形化管理界面，包含了集群状态可视化、元数据管理、数据查询等实用功能。Milvus Insight 源码也会作为独立项目开源，期待有更多感兴趣的人加入共同建设。
2. 支持基于 helm 和 docker-compose 的一键部署。
3. 性能监控：Milvus 2.0 使用开源时序数据库 Prometheus 存储性能和监控数据，同时依赖 Grafana 进行指标展示。
关于未来
回顾 Milvus 的发展历程，我们认为基于大数据 + AI 的应用架构依然过于复杂，简化非结构化数据处理一直是 Milvus 社区努力的方向。接下来的 Milvus 项目会重点关注以下几个方向：
DB for AI：作为一款数据库，除了基本的 CRUD 功能之外，Milvus 必然还需要更强大的数据查询能力、更智能的查询优化器、更全的数据管理功能等。下一阶段我们将重点补齐 Milvus 2.0 目前还不支持的 DML 功能和数据类型，比如删除、更新操作和支持 string 数据类型。
AI for DB：向量索引类型、索引参数、用户工作负载、硬件类型、成本性能等的约束构成了一个非常庞大的 tradeoff，尽可能避免手动调优有助于降低使用复杂度。我们已经着手分析系统负载，收集访问热度的数据，后续将引入自动参数调优工作以降低用户的理解成本。
成本优化：向量召回的最大挑战是需要在限定时间内处理海量数据，这项工作既是计算密集型，也是访存密集型。在物理执行层引入 GPU、FPGA 等异构硬件加速可以大幅降低 CPU 开销。我们正在开发磁盘内存混合的 ANN 索引算法，可以在有限的内存下实现海量向量的高性能查询。于此同时，我们也在评估开源的 ScaNN、NGT 等向量索引算法的性能。
易用性：Milvus 易用性的提升体现在集群管理工具、多语言 SDK、部署工具、运维工具等许多方面，能够让大家快速上手使用是我们最有成就感的工作。
🚀 Milvus Roadmap
🙏❤️ Thank you contributors！
Github @Milvus-io|CSDN @Zilliz Planet|Bilibili @Zilliz-Planet
文章转载自Zilliz。点击这里阅读原文了解更多。
Linux基金会诚意邀您参与：
联系关于Linux基金会
Linux基金会是非营利性组织，是技术生态系统的重要组成部分。
Linux基金会通过提供财务和智力资源、基础设施、服务、活动以及培训来支持创建永续开源生态系统。在共享技术的创建中，Linux基金会及其项目通过共同努力形成了非凡成功的投资。请长按以下二维码进行关注。
本文分享自微信公众号 - LFAPAC（gh_8442c14fe49e）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
