关于milvus:前所未有的-Milvus-源码架构解析

作者：栾小凡

编者按：

Deep Dive 是由 Milvus 社区发动的代码解析系列直播，针对开源数据库 Milvus 整体架构开放式解读，与社区交换与分享 Milvus 最外围的设计理念。通过本期分享，你能够理解到云原生数据库背地的设计理念，了解 Milvus 相干组件与依赖，理解 Milvus 多种利用场景。
讲师简介：

栾小凡，Zilliz 合伙人、工程总监，LF AI & Data 基金会技术咨询委员成员。他先后任职于 Oracle 美国总部、软件定义存储守业公司 Hedvig、阿里云数据库团队，曾负责阿里云开源 HBase 和自研 NoSQL 数据库 Lindorm 的研发工作。栾小凡领有康奈尔大学计算机工程硕士学位。

视频版解说请戳 👇

https://www.bilibili.com/vide…

本期分享分为四个局部：

1. 咱们为什么须要 Milvus？为什么它被称为下一代人工智能基础设施？
2. Milvus 2.0 的设计理念
3. Milvus 2.0 的概览与模块划分
4. Milvus 代码浏览注意事项

咱们为什么须要 Milvus？

非结构化数据处理流程

Milvus 为解决非结构化数据的检索问题而生：海量的非结构化数据个别会存储在分布式文件系统或对象存储上，之后通过深度学习网络实现推理，将这些非构造数据转化成 embedding 向量，并在向量空间内实现近似性检索，从而发现数据背地的一些特色。

整个数据处理流程如下图所示。比方，有很多原始的食物图片，通过卷积神经网络做训练和推理，为每一幅照片得出一组向量，再把这些向量依照空间中的近似维度做排序，最初失去这样的后果：最下面一排是一些长得像薯条的货色，两头都是一些长得像拉面的货色，底下都是长得像寿司的货色。也就是说，图片这种非结构化数据，通过深度学习解决之后，转化成了 embedding 向量，并通过在向量空间的近似度比对来表征其相似性，这在很大水平上能跟人类了解的近似度是高度一致的。

向量与标量

传统的标量数据和 Milvus 面向的向量数据之间，到底有哪些不同呢？

从基本操作上来讲，对于标量数据，针对数值类数据个别会做加减乘除的操作；对字符串类型的数据个别会做一些 term 的匹配，或者一些相似 like 的近似匹配，抑或一些前缀匹配。

而针对向量数据而言，很少进行这种 100% 的齐全匹配，更多是看近似度，也就是高维空间下的间隔。较常见的间隔示意有余弦间隔、欧式间隔等。空间中向量之间的间隔，很大水平上能示意非结构化数据之间的类似度。

除了对数据的操作会有很大不同以外，数据的组织形式也会有很大不同。如，传统数据很容易比拟大小，无论是数值类，还是字符串，都能够通过二叉树或者 skip list 的形式排列组合，而后做二分查找。对于向量数据来讲，则更加简单，因为它维度较高，很难像传统的数值类数据一样通过排序的形式做减速，往往须要一些非凡的索引构造和存储形式。

常见的向量索引形式

常见的向量的索引形式有哪些呢？

1）FLAT file，也就是大家常说的暴力搜寻，这种形式是典型的就义性能和老本换取准确性，是惟一能够实现 100% 召回率的形式，同时能够较好地应用显卡等异构硬件加速。

2）Hash based，基于 locality sensitive hashing 将数据分到不同的哈希桶中。这种形式实现简略，性能较高，然而召回率不够现实。

3）Tree based，代表是 KDTree 或者 BallTree，通过将高维空间进行宰割，并在检索时通过剪枝来缩小搜寻的数据量，这种形式性能不高，尤其是在维度较高时性能不现实。

4）基于聚类的倒排，通过 k-means 算法找到数据的一组中心点，并在查问时利用查问向量和中心点间隔抉择局部桶进行查问。倒排这一类又领有很多的变种，比方能够通过 PCA 将数据进行降维，进行标量量化，或者通过乘积量化 PQ 将数据降精度，这些都有助于缩小零碎的内存应用和单次数据计算量。

5）NSW（Navigable Small World）图是一种基于图存储的数据结构，这种索引基于一种奢侈的假如，通过在构建图连贯相邻的友点，而后在查问时一直寻找间隔更近的节点实现部分最优。在 NSW 的根底上，HNSW（Navigable Small World）图借鉴了跳表的机制，通过层状构造构建了快速通道，晋升了查问效率。

Milvus：为 AI 而生的数据库

Milvus 是专为 AI 而生的数据库，下图就是典型的 Milvus 在非结构化数据链路中的利用场景。

它反对的数据分为两类，一类就是须要比对的数据，另一类就是须要真正去做查问的数据。这些数据通过 Encoder 生成最终的 embedding 向量，向量通过 Milvus 做查问。所有的写入会转化成文件，并最终存储在对象存储下面。查问的过程中，search 基本上是纯内存的操作，利用一些内存的索引找到间隔比拟近的向量，而后再对这些向量会做一些读盘操作，拿到数据。

除了实现根本的向量搜寻性能，Milvus 也是一个数据库，能够实现动静的增删改查。将来，社区也打算去做像 Snapshot、备份、多租户之类更加常见的数据库性能。

其次，绝对于传统的向量检索库，Milvus 反对标量和向量数据的混合查问。传统向量搜寻的 Index 通常只针对向量数据，然而咱们发现很多用户心愿同时应用标量和向量，给一些标量的限度条件做过滤，再在这个根底上针对向量数据做查问。

此外，借助云基础设施，Milvus 实现了高度可扩展性和健壮性，并具备很高的弹性，前面咱们将具体探讨 Milvus 是如何实现这一能力的。

Milvus“不是”什么？Milvus 首先不是一个关系型数据库，不会反对特地简单的 JOIN 之类的查问，也不会反对 ACID 的事务。Milvus 次要是做向量域的近似查问。同时，Milvus 也不是一个搜索引擎，跟传统的 Elasticsearch、Solr 之间也有很大区别。Milvus 针对的是 embedding 向量数据，而不是传统的文本格式的数据。对于文本来说，Milvus 做的是基于语义的检索，而不是基于关键词的检索。

2.0 Tradeoffs

Milvus 2.0 在 1.0 版本做了大幅的重构，为什么会有这样大的降级？社区在做 Milvus 1.0 版本的过程中，遇到了一些比拟大的 Tradeoffs。

在设计一个分布式系统的过程中，肯定会面临一些取舍。比拟经典的数据库的取舍办法是 CAP，也就是一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。通常状况下，网络 Partation 不能解决的状况下，用户往往就只能在一致性和可用性之间 tradeoff。比方传统的 TP 数据库往往会抉择一致性，一些 AP 数据库或者 NoSQL 数据库可能会抉择更高的可用性。

对于 Milvus 来讲，绝大多数用户更多偏差可用性，对数据的实时可见没有那么高的要求。在 CAP 这个实践根底上，微软提出了更新的实践“PACELC”：在网络隔离性的根底上，一致性和可用性之间存在 Tradeoff；如果网络不产生隔离的话，就还有另一层 Tradeoff，叫做一致性和 Latency 之间的一个 Tradeoff。也就是说，如果网络都是失常的，为了维持一致性，肯定要就义可用性。比如说跨城服务的状况下，如果要保障一致性的话，那肯定须要做跨城读写。这个状况下，Latency 绝对来讲肯定是比拟高的。自身 Milvus 就是一个更加看重 Latency 的零碎，因而在大部分状况下，咱们会抉择去就义肯定的 一致性，也来实现可用性和 Latency。

除了传统的 CAP 的实践之外，还有另一个 CAP 的 Tradeoff，就是 Cost、Accuracy 和 Performance。通常状况下，一个零碎的实现老本基本上是恒定的。在这种状况下，更多水平上取决于所需查问的精度和性能。目前看下来，这两类用户各有各的抉择，有些用户会偏向更准确，为此宁愿多花一点老本保障查问是准确的。因而 Milvus 也提供了很多种索引的类型，大家能够依据本人在 CAP 方面不同的取舍，抉择更好的索引类型和零碎参数。

从引擎到数据库

Milvus 2.0 要解决的第二个问题，是从一个引擎变成一个弱小的数据库。

大家如果理解过 InnoDB 和 MySQL 之间的关系，或者理解过 Lucene 和 ES 之间的关系的话，置信就会很分明个中逻辑。

传统数据库次要解决性能问题，比方 Milvus 自身也会依赖 Faiss、HNSW、Annoy 之类的开源的库。这些库更关注查问的性能和性能。而 Milvus 除了要关注这些内容之外，还须要关注很多其余的货色，比方如何做数据分片，如何保证数据的高可靠性，如何保障分布式系统有节点出现异常时如何复原，如何在一个大规模集群中实现负载平衡，如何查问语句，如何做 Parse 和 Optimize。又如，零碎做长久化存储，须要考量不同的数据存储格局，而通常规范的库是不会去思考这些的。从用户的角度登程，须要一个更加易用、性能更加弱小的组件，而不仅仅是一个更快的库。

为云而生

Milvus 2.0 的第三个考量是拥抱云原生。

过来十几年，传统数据库根本采纳 share nothing 的架构。随着 Snowflake 的呈现，很多数据库采纳了 shared storage，越来越多的数据库开始做存储计算拆散。Snowflake 给予业界很大启发，利用云上的基础设施去做数据长久化，而后基于本地存储做缓存，这种模这种模式被称为 share something，取得了很多产品的共识。

另一个层面，利用 Kubernetes 治理执行引擎，利用微服务的模式分拆读、写和其余服务，也有利于各个组件别离弹性扩大。Milvus 所有的数据库执行引擎目前与 Docker 和 Kubernetes 适配，包含匹配目前支流的微服务的设计模式。

另一个很重要的趋势是 Database as a Service。在做 Database 的过程中，咱们发现很多用户不仅关注数据库的性能，还越来越多地关注数据库如何做治理、计费、可视化，数据迁徙。数据库不仅要提供传统的增删改查能力，还提供数据转换、迁徙、多租户加密治理、计费、限流、可视化、备份快找等更加多样的服务。

第三个重要的趋势是协同一体化。Milvus 自身是一个负责零碎，咱们也会依赖一些开源零碎作为 Milvus 的组件，比方应用 etcd 做元信息的存储，能应用 Message Queue 作为 Milvus 的数据，或者说把咱们的增量数据导出。同时也心愿能够跟一些 AI 的 Infra 联合，比方与 Spark 或者 Tensorflow 建设一种上下游的依赖关系；与一些流计算引擎联合，实现流批联合的形式，心愿咱们的用户能够依据本人对实时性和效率的不同要求，有更多的抉择。

Milvus 2.0 的设计理念

日志即数据

什么是日志呢？日志是一种只能追加、依照工夫齐全有序的记录序列。以下图为例，从左到右，右边的数据是老的数据，左边的数据是新数据，日志是依照工夫维度排列的。在 Milvus 中，咱们有一个全局的核心授时逻辑，发配全局惟一且自增的工夫戳。

这个工夫戳有哪些性能？工夫戳对事物隔离会有很大的益处，同时，工夫戳也可能会用来给数据做定序，比如说一条删除和一条写入的数据，到底哪个工夫大，实际上是通过全局惟一的工夫戳来定义的。

有了这个日志序列后能做什么事件？

实践上讲，如果有两个完全相同的确定性的过程，从同一个状态开始，以雷同的程序去取得雷同的输出，那么两个过程最终会生成雷同的输入并完结在雷同的状态。所谓后果，无论是内存中的状态，还是磁盘上的状态，最终都是完全一致的。它的用处十分宽泛，最广为人知的一个用处就是基于状态机的复制算法，证实了“日志即数据”是很好的工作形式。

表与日志的二象性

日志和数据之间能够互相转换的，它到底有什么作用呢？咱们提出，表与日志之间存在二象性。表数据和日志数据是数据的两面，表代表的是有界数据，日志代表的是无界数据。日志能够被转换为表数据，Milvus 通过 TimeTick 拆散出解决窗口，并依据解决窗口聚合日志。

日志的数据能够转换成表的数据，那么咱们如何实现这个转化呢？通过日志序列，咱们把数据划分成一个个窗口，依据这些窗口聚合成表的一个小文件，叫做 Log Snapshot。这些大件聚合起来叫做 Segment，造成一个能够去独自做 Load Balance 或者扩大的单元。

日志长久化

另一个充斥挑战的问题是日志长久化。分布式数据库日志的存储往往依赖一些复制算法，比方：

Aurora 就实现了底层的基于 Quorum 的一个长久化的日志零碎。这个 Quorum 算法逻辑也比较简单，只等两个后果，读的时候也只等两个后果。只有读和写的正本数目大于总的正本数目，就肯定能读到一致性的后果。

HBase 是依赖于底层的 distrubuted file system 的三正本的一个 pipeline，Cockroach DB、TiDB 等数据库都是依赖 Paxos 和 Raft 之类的复制算法来实现数据的一致性。

Milvus 2.0 抉择了一条翻新路线，依赖 Pub/sub 零碎来做日志的存储和长久化。Pub/sub 零碎是相似 Kafka 或者 Pulsar 的音讯队列，有这么一套零碎后，其余零碎的角色就变成了日志的消费者。这套零碎的存在将日志和服务器齐全解耦，保障 Milvus 自身是没有状态的，这样能够晋升故障复原速度。

除此之外，咱们依赖 Kafka 或者 Pulsar 来做数据的可靠性，保障大家的数据在应用过程中是不丢的。Pub/sub 零碎的引入能够保证系统的扩展性，Milvus 也能够与更多的零碎做集成。

集市架构

有了这套日志零碎当前，能够大大简化零碎的设计。咱们在写 Milvus 代码的时候，关注点绝对来讲就会少一些，保障这个零碎能够疾速迭代为大家提供服务。

基于这套日志零碎，咱们就设计了“集市架构”，外围解决的问题是如何高效地扩大一个零碎。那么“集市架构”为什么叫集市呢？它是一种涣散的耦合，大家都处在同一个环境中，然而每个人不太关怀彼此在做什么事件。用户把原始数据通过各种类型的转换，才能够转化成 embedding 数据，也能够转化成 Semi-structured data。比如说一些 text 也能够转化成 Structured data，相似于 relational model。

通常有两种插入方式，一种是流式，一种是批式，更对应的是相似 T + 1 的写入，把它插入到不同的解决引擎里去。比方，向量检索方面，将来可能也会去引入一些第三方的 KV 零碎或 text search 零碎，去做数据关键词检索，所有数据都是从 pub/sub 零碎发给所有订阅者。

数据写入之后，还会有一个混合查问的过程，通过 Query Processor 去实现用户的查问，最终把后果归并。基于日志零碎来做仿佛是一个比拟好的形式，然而也有一些很大的挑战。最重要的挑战就是，如果齐全基于日志零碎回放数据来做查问的话，查问自身是比较慢的。依照 TimeTick 把数据分成一个个窗口，一段窗口的数据就会合并成一个快照，快照通过一段阈值之后就合并，从而构建 vector Index、进步向量搜寻效率。除此之外，咱们也通过批量插入的形式去满足用户对离线数据的高效解决。

在读取门路中，Milvus 是一个典型的 MPP（Massively Parallel Processing）架构。每个 Segment 搜寻是并行进行的，Proxy 聚合 Top-K 后果并返回客户端。

Milvus 2.0 概览与模块划分

Milvus 单机与分布式

Milvus 目前来讲提供两种部署形式，一种是单机版，所有节点部署在一起，也就是说 Milvus 自身就是一个过程。目前单机版依赖 Etcd，也依赖 MinIO。在后续版本中，去掉 MinIO 和 etcd，保障单机版足够简略，能够让大家可能把 Milvus 用起来。

另一种是分布式，这个计划绝对来讲比较复杂，合乎微服务化的设计。那么它依赖的除了 etcd 和 MinIO，还有就是 Pulsar。Pulsar 作为咱们整个零碎的 log broker 来实现以日志为主干的设计。

Milvus 的角色

具体到所有角色来看，整个 Milvus 的分布式计划有八个角色和三个不同的依赖。

这八个角色中，下面四个的 Coordinator 局部也叫 Coordinator Service，下方分四种 Worker Node，每个 Worker Node 相似于 Hadoop 里的 Data Node 或者 HBase 里的 Region Server。横向来看，它用于执行用户申请，辨别品种是为了管控节点和下方的 Worker 节点。纵向来看，Query Coord 对应 Query Node，Data Coord 对应 Data Node，Index Coord 对应 Index Node，Root Coord 对应 Proxy Node。

每种角色到底有什么作用呢？

从最前端讲起，Proxy 就是充当零碎门面，所有的 SDK 查问都会通过一个 load balancer，发给 Pulsar Proxy 去解决连贯，做一些动态查看。比方，一个申请，可能 collection 名字基本不存在，Pulsar Proxy 就会间接报错，或者当插入的数据短少了某些列，就会由 SDK 发现。实现了预处理之后，Proxy 就会把数据投递到 Message Broker 里。

整体来讲，Proxy 会解决三类数据：写申请、读申请、管制申请，比方 DDL。Proxy 须要把数据投递到对应的 channel 里，Root Coord 相似于传统零碎中的 Master，次要做一些 DDL 和 DCL 的治理，比方建 Collection、删 Collection。

除此之外，Root Coord 还承当着十分大的责任，就是为零碎调配工夫戳。TimeTick 的机制会保证数据依据工夫戳定序。

很多敌人可能会放心，是不是会有单点的存在？对于 Milvus 而言，第一，性能瓶颈这块是比拟好解决的，不太须要去做过多思考，写入往往都是批量插入的，所以 TPS 自身没有那么高，只有满足吞吐的要求即可。第二，Milvus 在读链路的时候，对核心受权模块没有过多的依赖，因而 Root Coord 节点宕机不会对整个零碎的读入有任何影响。第三，Milvus 依赖云原生的设计，Root Coord 如果宕机，能够疾速被 Kubernetes 拉起来，可用性有保障。

Data 有两种角色，Data Coord 和 Data node。Data Coord 是协调者，会做一些 load balance 的调配、治理 segment、解决 Data Node 故障的复原，比方有些 Data Node 宕机的话，是通过 Data Coord 发现和复原的。Data Node 就做一件事件，把 log 外面的数据转化成 log snapshot，log snapshot 能够了解为 binlog，会生成一块大的 binlog，每个 binlog 通过 parquet 的格局存。Data Node 生成文件后，就会把文件传给 Index Node、生成 Sealed Segment，而后 Index Coord 会对 Sealed Segment 建索引。

有的同学会好奇，为什么建索引还要抽独自的角色去做，间接加一块做完可不可以？其实也是能够的。然而抽独自的角色去做的益处在于，第一，Index 很耗费性能，对弹性的要求更高。它不须要长时间保留的内存，如果有见缝插针的资源，Index 就能够用起来。第二，Index 自身很耗费资源，所以通常状况下用户做一些异构减速，Index Node 能够用 GPU 或专用硬件对索引做减速。Index Node 生成数据之后，就会把数据给到 Query Node 治理。所有的 Segment 都在 Query Node 上提供服务，通过 Query Node 执行查问。Query Node 有很多除了故障复原以外的查问逻辑，同时也是整个 Milvus 里最简单的节点。

Milvus 架构概览

整个零碎的框图如下。从左侧来看，SDK 把数据发到 Load Balancer，进入 Proxy，再依据不同的查问写入 Log Broker 里来，最初由 Log Broker 告诉 Data Node 新增的数据。

这里有个比拟有意思的中央：新增数据除了要进 Data Node 之外，也会进 Query Node。有些用户对数据的实时性有比拟高的要求，因而会通过 Broker 提前告诉 Query Node 有新增数据，保证数据的可见周期更短。当然所有查问也会通过 Log Broker 发到 Query Node 上，Query Node 执行完当前再把后果传回到 Log Broker，告诉 Proxy。

在 Query Node、Data Node 和 Index Node 之下，是基于 S3 构建的云存储。咱们发现云存储自身有很高的可能性，老本也比拟低，非常适合 Milvus 存储长久化的数据。

在 Coordinator Service 局部，除了刚刚说的 Root、Query、Data、Index 以外，还有 Meta Storage，目前是用 etcd 做的。一些比拟小的 etcd 不太适宜存在 S3 上，所以咱们把这些数据存在 etcd 上，etcd 也提供了很好的事务能力，整个零碎的故障复原和服务发现也是基于 etcd 去做的。

Milvus 的数据模型

那么 Milvus 到底提供给用户什么样的数据模型或能力呢？

首先，咱们为用户提供的最大概念叫做 Collection，即能够映射到传统数据库的一个表。每个 Collection 咱们会分多个 Shard，默认状况下是两个 Shard，到底要取多少 Shard 取决于你的写入量有多大、须要把写入分到多少个节点去做解决。如果你的写入比拟少，默认两个 Shard 就能够满足你的需要。

如果你的集群规模是 10 台或 100 台，咱们举荐 Shard 的规模做到 Data Node 的两到三倍。每个 Shard 两头又有很多 Partition，Partition 自带数据的属性，Shard 自身是依据主键的哈希去分的，而 Partition 往往是依据你指定的字段或 Partition 的 tag 去分的。常见的 Partition 形式有依据数据写入的日期划分、依据用户是男女去划分、依据用户的年龄去划分等。Partition 的一个很大劣势是在查问过程中，如果你加上 Partition tag 的话，能够帮你过滤掉很多数据。

Shard 更多是帮你去扩大写的操作，而 Partition 是帮你在读操作的状况上来晋升读的一个性能，每个 Shard 里的每个 partition 又会对应到很多小的 Segment。Segment 就是咱们整个系统调度的最小单元，分为 Growing Segment 和 Sealed Segment。Growing Segment 就是 Query Node 订阅，用户继续写入 Segment，等 Growing Segment 写大了当前，就不容许持续；默认下限是 512MB，写到下限当前，咱们就把它 seal 掉，并对 seal 的 Segment 建一些向量索引。

在读的时候，Growing Segment 和 Sealed Segment 都是须要去被读到的，能够保障用户数据的可见实时性比拟高。每个 Segment 里又分为很多 Entitity，Entity 是传统数据库外面“一行”的概念。Entity 是有 Schema 的，通常一个 Entitity 中必须有一个 Primary Key。一般来讲，咱们会有一个隐式的 ts 字段，Primary Key 如果不是被动指定的话，往往能够自增。除此之外，还有一个列和 Vector，一个 Entitity 会有一个 Vector，Vector 也是整个 Milvus 零碎的外围。

Milvus 数据存储模式

Milvus 在存储数据的过程中，会把数据存成什么样？

首先，存储过程是以 Segment 为单位，用的是列存的形式，每个 Primary Key、Column、Vector 都是独自用一个文件存储。Segment seal 掉之后，咱们会针对性地构建 Vector Index，整个 segment 只构建一个。

Vector Index 目前来讲只能反对建一个索引，咱们很快就会反对一个表建多个索引。比方你想尝试 HNSW 和 IVF-PQ 到底哪个性能好的话，能够建多个索引。后续咱们可能还会再退出一些主动调优的局部，帮用户主动抉择建一些索引。

为什么要抉择存储的过程中去列存呢？第一，列存的压缩率比拟高，通常咱们都是存一些 int 型的数据，或者存一些浓密的 float int 向量，能够通过列存去做比拟好的压缩。第二，做标量过滤可能会通过回盘的形式去做读取，那么列式存储能够用来做减速。

Sealed Segment 一旦写入实现，就不能批改。理论过程中，用户会有删除或者批改数据的需要，因而咱们就在 Segment 加了 Delta Log，每个 Delta Log 蕴含了几行删除或追加的数据。

用户做删除的时候，咱们会通过路由找到对应的 Segment，在 Segment 外面生成 Delta Log。Delta Log 有点相似于传统的 LSM 树的架构，咱们会先去读原始文件，而后把 Delta Log 依据工夫戳缓缓打到读出来的数据上。如果 Delta Log 的 ts 大于原始数据的 ts，那么原始数据就会被删除。Delta Log 写多了或者删除多了之后，也须要做清理，不然你的读取就会变得越来越慢。因而咱们基于文件格式做 compaction，定时把 Delta Log 整合到原有的文件外面，使得在读的过程中保障不须要往回打太多的数据。

Milvus 代码浏览注意事项

筹备工作

在你真正理解 Milvus 之前，你能够做如下筹备工作：

第一，Milvus 自身是基于 Go 和 C++ 来写的，下层的分布式用的是 Go，上层的外围局部用的是 C++。Go 的局部帮忙咱们更加的云原生，以及帮忙零碎更好地去做拓展。C++ 的局部更多是出于性能和异构硬件的思考。所以你须要对这两种语言都有肯定的理解，咱们倡议初学者先从 Go 来动手。

第二，浏览 Milvus 官网上对于零碎架构的设计文档（https://milvus.io/docs/archit…）。明天讲的内容很大水平上都会在笼罩这个文档里，将来咱们也会补充各种各样的设计文档到 Milvus 官网和咱们的 GitHub 外面。

第三，Milvus 自身依赖 Pulsar、etcd、开源的 MinIO、S3 等。因而，在读 Milvus 代码之前，你能够先理解一下这些货色在做什么。你还能够浏览咱们在 SIGMOD 2021 发表的 paper，你会对 Milvus 这个零碎的初心以及它的一些用处有更深刻的理解。

Milvus: A Purpose-Built Vector Data Management System, SIGMOD’21

地址：https://www.cs.purdue.edu/hom…

最初，你要先实现 Milvus 的 study demo，理解一下 Milvus 到底能帮你做哪些事件。在你开始去相熟一个零碎之前，先成为他的用户，简略地把这个货色玩一玩。

Demo 地址：https://milvus.io/milvus-demos

学习门路

当你做完这些事件当前，接下来的学习内容能够参考如下门路：

第一，Milvus 的一些 API 和 Python SDK 的实现

第二，理解零碎前端的设计、proxy 的性能，以及 Milvus 的增删改查等次要操作的门路和流程

第三，数据文件的生成门路，以及存储的格局

第四，查问门路（数据查问进入到 Milvus 之后会经验哪些组件，每个组件大略实现一些什么样的性能）、故障复原、负载平衡

最初，学习标量执行引擎，和向量执行

DeepDive 系列也将依照以上门路为大家进行解说。

等我相熟了 Milvus，我能够……

相熟了代码之后你应该做什么呢？

首先，欢送大家退出 Contributer 小家庭，心愿大家能够花点工夫浏览咱们的文档，甚至参加批改咱们的文档。文档地址：https://milvus.io/docs

当你相熟的这个零碎之后，我置信你会有很多的 idea，兴许你想理解更多的技术细节以及这个社区想要倒退的方向。咱们的 Tech Meeting 会定期同步到 LF AI & Data 的 Home（地址：https://wiki.lfaidata.foundat…）。欢送大家退出咱们的探讨！

想要第一工夫理解理解社区最新的性能和改良？

GitHub: https://github.com/milvus-io/…

欢送在这里与咱们畅聊新性能！

Slack: https://milvusio.slack.com/

当然最重要的就是为 Milvus 社区奉献代码，你奉献的代码是能够让全世界的工程师都看到都用起来，这也是大家为什么都十分违心退出到 Milvus 社区的重要起因，用咱们本人的力量去帮忙更多的人去应用。当你对这个代码有很深刻的了解当前，欢送你在知乎或者在一些其余中央分享对于 Milvus 代码学习的一些心得体会，让更多的人能不便学习和应用 Milvus！