基于弹性云的向量型数据库Milvus的演进历程

译者 | 陈林

审校 | 孙淑娟 梁策

Milvus向量型数据库的目的

当咱们第一次性出现Milvus向量型数据库的想法时，咱们宿愿构建的是一个数据基础设备，从而减速人工智能在人们组织架构中的经常使用。

为了成功这一使命，咱们为Milvus名目设定了两个关键目的。

易用性

人工智能/机器学习是一个新兴畛域，新技术不时涌现。大少数开发人员关于高速开展的AI技术和工具并不相熟。开发人员破费了少量的精神来寻觅、训练和调整模型，基本没有额外的精神来处置模型生成的少量嵌入向量，更不用说处置海量数据不时都是一项相当有应战的义务。

因此，咱们给“易用性”定了相当高的优先级，由于它可以清楚地降落开发老本。

低运转老本

Milvus 2.0的设计准则

咱们在 Milvus 1.0 中朝着这些目的迈出了第一步，但这还远远不够，尤其是在可裁减性和可用性方面。而后咱们开局研发Milvus2.0来完善这些点。咱们为2.0新版本制订的准则包括：

也就是说，咱们想让Milvus数据库集群成为云原生。

Milvus数据库集群的演进

向量数据库是一种新型数据库，由于它处置的向量数据是一种新的数据类型。它面临与其余数据库相反的应战，但也具有自身的一些场景和需求。在本文剩下的局部，我将重点引见咱们从现有的数据库集群成功中能学到什么，以及咱们在设计新的MilvusGroup架构时的思索旅程。

假设你对Milvus Group组件的成功细节感兴味，请继续关注 Milvus文档。咱们将在MilvusGitHub仓库、Milvus官方和Milvus博客上继续颁布技术文章。

现实的数据库集群

让咱们首先列举出一个现实的数据库集群应该具有的关键才干。

说真实的，现有数据库是无法同时提供和保证这些才干的。在现代数据库集群的成功中，人们不得不对其中的局部性能斗争。咱们并不希冀一个完美的数据库集群，只需能够适用和满足用户的业务场景就行了。但是，共享“一切” 的集群一度十分凑近现实的数据库集群。假设咱们想学习一些阅历，咱们应该以它为基础开局。

数据库集群的关键思索要素

与其余数据库成功相比，shared-everything的数据库集群具有更久远的历史。DB2数据共享组和OracleRAC是典型的shared-everything集群。许多人以为shared-everything象征着共享磁盘，其实远不止于此。

shared-everything的数据库集群在组中只要一种数据库成员。用户可以衔接到这些平等成员中的任何一个实例来访问任何数据。成功这项操作须要共享的“一切” 是什么?

组内事情序列

首先，组内事情序列关于处置不同组成员由于并发访问惹起的潜在抵触至关关键。咱们通经常常使用数据库日志记载序号来示意事情的顺序。同时，日志记载序号普通是由期间戳生成的。

因此，对组内事情顺序的要求等价于对全局定时器的须要。假设咱们可以为组装备一个原子钟，那就太棒了。但是，Milvus是一个开源软件名目，这象征着咱们应该依赖罕用的资源。迄今为止，原子钟依然是大公司的首选。

咱们在Milvus 2.0数据库集群中成功了期间同步组件。您可以在附录中找到链接。

全局锁

数据库有一个锁定机制来处置并发访问抵触，无论是失望锁还是失望锁。雷同，咱们须要经常使用全局锁定来处置不同组成员之间同时访问的抵触。

全局锁定象征着不同的组成员必定相互交谈以协商锁定恳求。 影响这个全局锁定协商环节的效率关键有几个关键的要素：

通常的组大小不超越100。例如，DB2 DSG为32;OracleRAC为100。这些组成员将被搁置在一个经过光纤衔接的主机机房中，以最大限制地缩小传输提前。这就是为什么它有时被称为集中式集群。由于组大小的限制，人们会选用上流主机(大型机或小型机，在 CPU、内存、I/O 通道等方面具有更多容量)来组成共享一切集群。

这种配件假定在现代云环境中出现了渺小变动。现如今，云数据中心都是由高密度主机机房组成，集群性能了(数千台) TCP/IP 网络连通的商用 X86主机。假设咱们依托这些 X86主机来构建数据库集群，那么组大小应该会参与到数百(甚至数千)台机器。而在一些业务场景中，咱们宿愿这数百台X86机器散布在不同的区域。因此成功全局锁定的价值和意义就不大了，由于全局锁定性能不够好。

在Milvus2.0中，咱们不会成功全局锁定性能。一方面，向量数据不会有更新(用户偏差于删除后拔出而不是更新)。所以咱们不须要担忧基于分片编排的Milvus组内的同一条数据的由于屡次写入形成抵触。同时，咱们可以经常使用MVCC(多版本并发控制，一种防止锁的并发控制方法)来处置读写抵触。

另一方面，向量数据处置比结构化数据处置消耗更多的内存占用。 人们不时在寻觅具有高裁减性的向量数据库。

共享内存数据缓存

咱们可以繁难地将数据库引擎分为两局部，即存储引擎和计算引擎。存储引擎担任两项关键义务：

在数据库集群场景中，假设成员A更新了成员B中缓存的数据怎样办?成员B如何知道其内存数据已过时?关于经典的shared-everything集群，有一种缓冲区交叉失效机制来处置这个疑问。假设咱们在组成员之间维持强分歧性，则缓冲区交叉失效机制将相似于全局锁。如上所述，它在现有的云环境中并不适用。所以咱们选择将Milvus弹性云分组的分歧性级别降落为最终分歧性的形式。这样，Milvus2.0中的缓冲区交叉失效机制就可以是一个异步环节。

共享存储

共享存储或许是人们在讨论数据库集群时会想到的第一件事。

近年来，随着云存储的开展，存储可选项也出现了清楚的变动。 存储衔接网络 (SAN)不时是shared-everything的存储基础。但是在云环境中并没有SAN，数据库必定经常使用本地磁盘衔接到云虚构机。经常使用本地磁盘关于跨组成员的数据分歧性带来了新的应战，而且咱们还不得不思索组成员的高可用。

Snowflake数据仓库为计划经常使用云共享存储(S3存储)的云数据库树立了一个很好的楷模，它也启示了Milvus2.0。如上所述，咱们计划基于成熟的云基础设备成功Milvus 2.0，但在咱们能够应用云共享存储之前，咱们必定思索以下疑问。

首先，S3存储廉价且牢靠，但它不是为像数据库那样的实时读写的场景而设计的。咱们须要创立数据组件(咱们在Milvus2.0中称为数据节点)来桥接本地内存/磁盘和S3存储。市面上有一些示例可以参考，如Alluxio、JuiceFS等。无法间接集成这些名目的要素是咱们思索到不同的数据粒度。Alluxio和JuiceFS是为数据集或POSIX文件设计的，而咱们专一于数据记载(向量)级别。

当向量数据在S3存储的疑问被处置时，元数据的存储很繁难：将它们存储在etcd。那么日志数据呢?在传统的成功中，日志存储也是基于SAN。一个数据库组成员的日志文件在数据库集群内共享，用于缺点复原。在进入云环境之前这不是疑问。

在Spanner论文中，Google展现了他们是如何经常使用Paxos共识算法成功全局散布式数据库(组)的。你须要基于形态机复制组成功数据库集群，重做日志(redolog)通常就是用于整个组复制的那个“形态”。

共识算法的重做日志(redolog)复制是一种弱小的工具，在某些业务场景中具有相当大的长处。但是，关于Milvus向量数据库，咱们没有找到足够的措施创立一个完整的形态机复制组。咱们选择经常使用云信息队列/平台(ApachePulsar、Apache Kafka等)用于日志存储，作为共享云存储的代替品。经过将日志存储委托给信息传递平台，咱们取得了以下好处：

咱们将在前面的局部从新讨论这个话题。

到目前为止，咱们曾经总结了设计一款数据库集群要思索的关键要素。在开局讨论Milvus2.0架构之前，让我先说明一下咱们是如何在Milvus中控制向量的。

数据控制和性能可预测性

Milvus将向量存储在汇合中。“汇合”是一个逻辑概念，相当于SQL数据库中的“表”。一个“汇合”可以有多个物理文件来保留向量，一个物理文件是一个“段”。“段”是一个物理概念，相似于SQL数据库中的表空间文件。当数据量较小时，咱们可以将一切内容保留在单个段/物理文件中。但是，现如今不时面临着海量数据的存储，当有多个段/物理文件时，应该如何将数据扩散到不同的数据分区中?

虽然数据先于索引来到，但咱们必定以更适宜索引算法的形式存储数据，以便在大少数状况下高效地访问数据。SQL数据库中罕用的战略是以分区键值的范围启动分区。通常状况下，就是创立一个汇集索引来强迫分区键。这关于SQL数据库来说是一种不错的方法，一方面数据存储良好，另一方面针对I/O(预取)启动了优化，但依然存在以下缺点：

当越来越多的上班负载流向数据歪斜度高的分区时，咱们须要对各个分区的数据启动从新平衡。

向量的汇集索引

咱们还可以为向量创立汇集索引(倒陈列表索引)，这与SQL数据库的索引不同。给SQL数据库树立索引后，经过索引访问数据十分高效，计算量少，I/O操作少。但是关于向量数据来说，即使有索引，计算和I/O操作也不会因此缩小。因此，在向量数据库集群中，数据歪斜和热点数据集中的影响更为清楚。此外，由于数据量和计算复杂性要素，在不同分段对向量启动从新平衡的老本十分高。

在Milvus中，咱们驳回分区智能增长的战略。当咱们将数据存入向量汇合时，Milvus会将新向量追加到汇合中的最新段。一旦这个段的大小到达某个阈值(阈值可性能)，Milvus将封锁该段并为封锁的段树立索引。同时，它还将创立一个新段来存储新的数据。这种繁难的战略关于向量处置来说平衡性更友好。

向量查问指的是在向量汇合中查问与目的条件婚配度最相近的结果。它是一个典型的MapReduce环节。例如，假构想从蕴含10个分段的向量汇合中搜查前20个相似的结果，咱们可以搜查每个段的前20个，而后将20 *10个查问兼并，挑选出其中20个结果前往。由于每个段具有相反数量的向量和相似的索引，因此每个段的处置期间简直相反。这样的好处是带来了性能可预测性的长处，它在布局数据库集群的规模时至关关键。

Milvus 2.0的新范式

在Milvus1.0中，咱们成功了与大少数SQL数据库一样的读写分别分片组。这种成功对Milvus数据库集群来说是种不错的尝试，但带来的疑问也是显而易见的。

Milvus 1.0：分片集群

在Milvus1.0中，写节点必定全程保养最新的段，其中就包括在未索引的段中追加向量、搜查向量，以及树立索引等操作。由于每个汇合只要一个写节点，假设数据在源源不时地写入系统，写入节点将会成为瓶颈。写节点和其余读节点之间的数据共享性能也是一个疑问。此外，咱们必定依赖NFS(不稳固)或许商用云存储(太贵)来作为共享数据存储。

以上疑问在Milvus 1.0架构中很难处置。 因此，咱们在Milvus 2.0设计中引入了新的范式。

Milvus 2.0：弹性云向量数据库

Actor模型

如今有两种罕用的并发计算的模型编程。

咱们也可以在散布式数据库集群中运行这两种模型。

近年来，基于Redo-log复制的算法不时是最被高估的数据库技术,它存在两个关键疑问。

假定咱们有两个数据库节点，一个是主节点，另一个是从节点。从一开局，两个节点的数据是齐全分歧的。咱们在主节点上有一些修正操作(新增/更新/删除的SQL语句)，咱们宿愿坚持从节点同步更新。咱们应该做什么?最繁难的方法是在从节点上重放更新操作，但这不是最高效的手腕。

思索新增/更新/删除语句的运转老本：咱们可以将其分为口头预备和实践口头局部。口头预备局部包括SQL解析器、SQL优化器等上班，不论影响到了多少条数据记载，老本都是固定的。实践口头局部的老本取决于有多少数据记载会遭到影响，它的老本是浮动的。redo-log复制面前的想法是为了浪费从节点上的固定老本，即只在从节点上重放redo-log即可。

老本节俭率和redo-log记载数成正比。假设一次性更新操作只影响一条记载，redo-log复制其实有很大的优化空间。假设是10000条记载呢?当然，咱们还应该关心网络牢靠性。哪个更牢靠，发送一个操作还是10000条redo-log记载?一百万条记载又怎样样?redo-log复制最适宜的场景是支付系统、元数据系统等。在这些场景中，每个数据库新增/更新/删除操作只影响大批的记载(1或2)，它不适用于I/O密集型类的场景，例如义务批处置。

局部供应商总是宣称共识算法可以为数据库集群提供强分歧性。虽然redo-log记载在不同节点上是分歧的，但这并等价于数据视图也是分歧的。没有将redo-log记载兼并到数据库表之前，即使经常使用这种同步处置，咱们也只能在数据上保证最终分歧性。

咱们应该在适宜的场景下经常使用redo-log复制分歧性算法。 Milvus 2.0中经常使用的元数据系统(etcd)和信息两边件平台(例如 ApachePulsar)曾经成功了分歧性算法。但正如我之前所说的，“关于Milvus向量数据库，目前还没有方法让它成为一个完整的形态机复制组。

在Milvus 2.0中，咱们经常使用Actor模型来编排上班节点。上班节点是独自隔离的，它们只与信息两边件平台通讯，失掉命令并发送结果。

Actor模型是异步的，它适用于对裁减性和可用性要求高的场景。由于上班节点之间是相互隔离的，参与或移除局部上班节点对其余上班节点没有影响。

可用性和耐久性的分别

在 Milvus 2.0中，咱们成功的是操作重放而不是日志重放。由于在向量数据库中，操作重放和日志重放没有太大区别。咱们没有更新性能，也没有查问拔出性能，并且经常使用Actor模型启动操作回放要繁难得多。

多个上班节点或许会依据各自的职责从信息两边件平台口头相反的操作。之前提到咱们选择经常使用S3云存储作为Milvus数据库集群的共享存储层。S3存储十分牢靠，那么不同的上班节点能否须要将相反的数据写入共享存储呢?

因此，咱们把上班节点分类为以下三个角色：

这三种类型的节点分担了不同类型的上班负载。它们可以独立裁减。这里的可用性和耐久性分别是从微软Socrates云数据库中学习衍生而来的。

总结和展望

本文回忆了Milvus向量数据库2.0版本的几个设计决策。让咱们在这里极速总结一下这些要点。

到目前为止，Milvus2.0弹性云数据库的骨架曾经定型，目前还有许多来自Milvus社区的需求须要满足。假设您有相反的使命(“构建更多开源基础设备软件，减速AI转型”)，欢迎参与Milvus社区。

Milvus是LF AI &>附录

Milvus设计文档

Raft的C++成功

假设你对共识算法感兴味，倡导你检查eBay的开源名目Gringofts。它是Raft共识算法(Paxos系列的一个变体)的C++成功。它是我的好友Jacky和Elvis(我在摩根士丹利的前共事)为eBay在线支付系统构建的，这也正是它最适宜的场景之一。

译者引见

陈林，社区编辑，某批发银行龙头DevOps继续集成平台技术担任人，主导外围业务计划设计落地，推进产品架构继续演进。担任安保工具接入、扫描中台树立、构建减速、SCM性能优化、镜像控制等模块。介入微服务控制、多活构建调度架构、异构存储集群集成、缓存和散布式限流等架构优化。热爱开源技术和写文章，谋求技术广度和畛域深度。

原文题目：Evolution of Milvus Cloud-Scalable Vector>