Milvus 2.0 重新定义向量数据库

2018 年 10 月，我们为 Milvus 写下第一行代码，这一切恍如昨日。2021 年 3 月，在经过全球 1000 多位用户测试的 19 次迭代后，我们推出了 Milvus 1.0，这是我们第一个获得长期支持的正式版本。作为全球最受欢迎的开源向量数据库，Milvus 1.0 成功解决了向量管理中的一些基本问题，如 CRUD 操作和数据持久性。然而，随着新场景和新需求的出现，我们开始意识到还有很多问题有待解决。本文回顾了我们在过去三年中的观察结果、Milvus 2.0 预计要解决的挑战，以及 Milvus 2.0 被认为是解决这些挑战的更好方案的原因。 要了解有关 Milvus 2.0 的更多信息，请查阅 Milvus 2.0 发行说明。

Milvus 1.x 面临的挑战

数据孤岛：Milvus 1.0 只能处理非结构化数据生成的向量嵌入，对标量查询几乎不提供支持。其设计中对数据存储的分解导致数据重复，增加了应用程序开发的复杂性，而向量和标量数据之间的混合搜索由于缺乏统一的优化器，效果并不理想。

及时性与效率之间的两难选择：Milvus 1.0 是一个接近实时的系统，它依靠定期或强制刷新来保证数据的可见性。这种方法在多个层面上增加了流数据处理的复杂性和不确定性。此外，虽然这种批量插入的方法据说可以提高处理效率，但仍然会消耗大量资源。因此，需要采用批量加载方法。

缺乏可扩展性和弹性：Milvus 1.0 依赖分片中间件解决方案 Mishards 实现可扩展性，并依赖网络附加存储（NAS）实现数据持久性。这种建立在共享存储基础上的经典架构对整体可扩展性贡献不大，原因如下：

1. Mishards 只支持一个写节点，无法扩展。
2. Mishards 中读取节点的扩展是通过基于哈希的一致路由来实现的。虽然一致散列很容易实现，也有助于解决数据分布均匀性的问题，但它在数据调度方面不够灵活，无法解决数据大小与计算能力不匹配的问题。
3. Milvus 1.0 依赖 MySQL 来管理元数据，但 Standalone MySQL 服务器能够处理的查询和数据集大小相当有限。

缺乏高可用性：我们的一个观察结果是，Milvus 的大多数用户都倾向于可用性而非一致性，而 Milvus 1.x 缺乏内存复制和灾难恢复等能力，在高可用性方面不太达标。因此，我们正在探索牺牲一定程度的准确性来实现更高可用性的可能性。

成本过高：Milvus 1.0 依赖 NAS 进行数据持久化，其成本通常是本地存储或对象存储的十倍。由于向量搜索严重依赖计算资源和内存，其高昂的成本很可能成为进一步探索大规模数据集或复杂业务场景的障碍。

不直观的用户体验：

1. 复杂的分布式部署会产生高昂的操作符。
2. 没有精心设计的图形用户界面（GUI）。
3. 不直观的应用程序接口已成为开发应用程序的阻力。

是继续使用补丁，还是从头开始，这是一个大问题。Milvus 之父 Charles Xie 认为，正如许多传统汽车制造商永远无法逐步转向特斯拉一样，Milvus 要想蓬勃发展，就必须成为非结构化数据处理和分析领域的游戏规则改变者。正是这种信念促使我们启动了Milvus 2.0，一个经过重构的云原生向量数据库。

Milvus 2.0 的制作过程

设计原则

作为我们的下一代云原生向量数据库，Milvus 2.0 围绕以下三个原则构建：

云原生优先：我们认为，只有支持存储和计算分离的架构才能按需扩展，并充分利用云的弹性优势。我们还想提请大家注意 Milvus 2.0 的微服务设计，其特点是读写分离，增量数据和历史数据分离，CPU 密集型、内存密集型和 IO 密集型任务分离。微服务有助于为不断变化的异构工作负载优化资源分配。

日志即数据：在 Milvus 2.0 中，日志代理是系统的主干：所有数据插入和更新操作都必须通过日志代理，工作节点通过订阅和消费日志来执行 CRUD 操作。这种设计将数据持久性和闪回等核心功能下移到存储层，从而降低了系统的复杂性，而日志发布子（log pub-sub）则使系统更加灵活，更适合未来的扩展。

统一的批处理和流处理：Milvus 2.0 实现了统一的 Lambda 架构，整合了增量数据和历史数据的处理。与 Kappa 架构相比，Milvus 2.0 引入了日志回填功能，将日志快照和索引存储在对象存储中，提高了故障恢复效率和查询性能。为了将无界（流）数据分解为有界窗口，Milvus 采用了新的水印机制，按照写入时间或事件时间将流数据切分成多个消息包，并维护时间轴供用户按时间查询。

2.0 图片 1.png

系统架构

如上所述，Milvus 2.0 的设计严格遵循存储与计算分离、控制面与数据面分离的原则。系统分为四层：访问层、协调者服务、工作节点和存储。

访问层：接口：访问层是系统的前端层，也是用户的终端。它负责转发请求和收集结果。

协调器服务：协调器服务为工作节点分配任务，是系统的大脑。协调器有四种类型：根协调器（root coordinator）、数据协调器（data coordinator）、查询协调器（query coordinator）和索引协调器（index coordinator）。

工作节点：手臂和腿。工作节点是哑执行器，它们遵从协调器服务的指令，并响应访问层的读/写请求。有三种类型的工作节点：数据节点、查询节点和索引节点。

存储：骨架。存储有三种类型：元存储、日志代理和对象存储。

• 元存储由 etcd 实现，用于存储协调器服务的 Collections 和检查点等元数据。
• 日志代理由 Pulsar 实现，主要用于存储增量日志和实现可靠的异步通知。
• 对象存储由 MinIO 或 S3 实现，主要用于存储日志快照和索引文件。

以下是 Milvus 2.0 的系统架构图： 2.0 image 2.png

主要特点

数据库的运行成本不仅涉及运行时的资源消耗，还包括潜在的学习成本和操作维护成本。实际上，数据库越方便用户使用，就越有可能节省这些潜在成本。从 Milvus 发布日历的第一天起，易用性就一直被放在我们的首要位置，而最新的 Milvus 2.0 在降低这些成本方面也有不少亮点。

始终在线

数据可靠性和服务可持续性是数据库的基本要求，我们的策略是 "低故障、小故障、常故障"。

• "廉价故障 "指的是存储和计算分离，这使得节点故障恢复的处理简单易行、成本低廉。
• "小故障 "指的是 "分而治之 "策略，即让每个协调器服务只处理一小部分读/写/增量/历史数据，从而简化设计的复杂性。
• "经常失败 "指的是引入混沌测试，即在测试环境中使用故障注入来模拟硬件故障和依赖性失效等情况，从而加速错误发现。

标量数据和向量数据之间的混合搜索

为了发挥结构化数据和非结构化数据之间的协同作用，Milvus 2.0 同时支持标量数据和向量数据，并实现了它们之间的混合搜索。混合搜索可帮助用户找到符合筛选条件的近似近邻。目前，Milvus 支持关系操作，如 EQUAL、GREATER THAN 和 LESS THAN，以及逻辑操作，如 NOT、AND、OR 和 IN。

可调整的一致性

作为一个遵守 PACELC 定理的分布式数据库，Milvus 2.0 必须在一致性与可用性和延迟之间进行权衡。在大多数情况下，在生产中过分强调数据一致性可能会矫枉过正，因为允许一小部分数据不可见对整体召回影响不大，但却能显著提高查询性能。尽管如此，我们仍然认为，强、有界僵化和会话等一致性级别都有其独特的应用。因此，Milvus 支持请求级别的可调一致性。以测试为例，用户可能需要强一致性来确保测试结果绝对正确。

时间旅行

数据工程师经常需要进行数据回滚，以修复脏数据和代码错误。传统数据库通常通过快照甚至数据重整来实现数据回滚。这可能会带来过高的开销和维护成本。Milvus 为所有数据插入和删除操作维护时间轴，用户可以在查询中指定时间戳，以检索指定时间点的数据视图。通过时间旅行，Milvus 还能实现轻量级数据备份或数据克隆。

对象关系映射（ORM）Python SDK

对象关系映射（ORM）允许用户更多关注上层业务模型，而不是底层数据模型，使开发人员更容易管理 Collections、字段和程序之间的关系。为了缩小人工智能算法的概念验证（PoC）与生产部署之间的差距，我们设计了 PyMilvus ORM API，它可以与嵌入式库、独立部署、分布式集群甚至云服务协同工作。通过一套统一的 API，我们为用户提供了一致的用户体验，并降低了代码迁移或调整成本。

2.0 图像 3.png

支持工具

• Milvus Insight 是 Milvus 的图形用户界面，提供集群状态管理、元管理和数据查询等实用功能。Milvus Insight 的源代码也将作为独立项目开源。我们正在寻找更多的贡献者加入这一行列。
• 开箱即用的体验（OOBE），更快的部署：Milvus 2.0 可以使用 Helm 或 docker-compose 进行部署。
• Milvus 2.0 使用开源时间序列数据库 Prometheus 来存储性能和监控数据，并使用开放式可观察性平台 Grafana 来实现指标可视化。

展望未来

回顾过去，我们认为基于大数据+人工智能应用的系统架构过于复杂。如何让 Milvus 更好用，一直是 Milvus 社区的首要任务。今后，Milvus 项目将重点关注以下几个方面：

DB for AI：除了基本的 CRUD 功能外，Milvus 作为一个数据库系统，还需要有更智能的查询优化器、更强大的数据查询功能和更全面的数据管理功能。我们下一阶段的工作重点将放在 Milvus 2.0 中尚未提供的数据操作语言（DML）功能和数据类型上，包括增加删除和更新操作、支持字符串数据类型等。

DB 的人工智能：对索引类型、系统配置、用户工作量和硬件类型等参数进行旋钮式调整会使 Milvus 的使用复杂化，应尽量避免。我们已着手分析系统负载和收集数据的访问频率，并计划在未来引入自动调整功能，以降低学习成本。

成本优化：向量检索面临的最大挑战是需要在有限的时间内处理大规模数据集。这既是 CPU 密集型的，也是内存密集型的。在物理层引入 GPU 和 FPGA 异构硬件加速可以大大降低 CPU 的开销。我们还在开发一种磁盘和内存混合 ANN 索引算法，以便在内存有限的情况下实现海量数据集的高性能查询。更重要的是，我们正在评估 ScaNN 和 NGT 等现有开源向量索引算法的性能。

易用性：Milvus 通过提供集群管理工具、多种语言的 SDK、部署工具、操作符工具等，不断提高其易用性。

要了解有关 Milvus 发布计划的更多信息，请查看Milvus 路线图。

感谢所有 Milvus 社区贡献者，没有他们就没有 Milvus 2.0。欢迎向 Milvus 社区提交问题或贡献您的代码！

关于作者

栾晓帆现任 Zilliz 工程总监，负责 Milvus 项目的研发工作。他拥有 7 年的工作经验，专注于构建数据库/存储系统。从康奈尔大学毕业后，他曾先后就职于甲骨文公司、海德维格公司和阿里巴巴云。