关于数据库:Milvus-20-数据插入与持久化

编者按：本文具体介绍了 Milvus2.0 数据插入流程以及长久化计划

Milvus 2.0 整体架构介绍
数据写入相干的组件介绍

• Proxy
• Data coord
• Data node
• Root coord & Time tick

Data allocation 数据调配

• 数据组织构造

文件构造及数据长久化

Milvus 2.0 整体架构介绍

上图是 Milvus 2.0 的一个整体架构图，从最右边 SDK 作为入口，通过 Load Balancer 把申请发到 Proxy 这一层。接着 Proxy 会和最下面的 Coordinator Service（包含 Root Coord、Root Query、Data 和 Index）通过和他们进行交互，而后把 DDL 和 DML 写到咱们的 Message Storage 里。

在下方的 Worker Node：包含 Query Node、Data Node 和 Index Node，会从 Message Storage 去生产这些申请数据。query node 负责查问，data node 负责写入和长久化，index node 负责建索引和减速查问。

最上面这一层是数据存储层（Object Storage），应用的对象存储次要是 MinIO、S3 和 AzureBlob，用来贮存 Log、Delta 和 Index file。

数据写入相干的组件介绍

Proxy

Proxy 作为一个数据申请的入口，它的作用从一开始承受 SDK 的插入申请，而后把这些申请收到的数据哈希到多个桶里，而后向 DataCoord（data coordinator）去申请调配 segment 的空间。（Segment 是 Milvus 数据存储的一个最小的单元，后文会具体介绍）接下来的一步就是把申请到的空间的这一部分数据插入到 message storage 外面。插入到 message storage 之后，这些数据就不会再失落了。

接下来咱们看数据流的一些细节：

• Proxy 能够有多个
• Collection 下有 V1、V2、V3、V4 的 VChannel
• C1、C2、C3、C4 就是一些 PChannel，咱们叫它物理 channel
• 多个 V channel 能够对应到同一个 PChannel
• 每一个 proxy 都会对应所有的 VChannel：对于一个 collection 不同的 proxy 也须要负责这个 collection 里边的所有的 channel。
• 为了防止 VChannel 太多导致资源耗费太大，多个 VChannel 能够对应一个 PChannel

DataCoord

DataCoord 有几个性能：

• 调配 Segment 数据
  把 Segment 空间调配到 proxy 后，proxy 能够应用这部分空间来插入数据。
• 记录调配空间及其过期工夫
  每一个调配都不是永恒的，都会有一个过期工夫。
• Segment flush 逻辑
  如果这个 Segment 写满，就会落盘。
• Channel 调配订阅
  一个 collection 能够有很多 channel。哪些 channel 被哪些 Data Node 生产则须要 DataCoord 来做一个整体的调配。

Data Node

Data Node 有几个性能：

• 生产来自这个数据流的数据，以及进行这个数据的序列化。
• 在内存外面缓存写入的数据，而后达到定量之后把它主动 flush 到磁盘下面。

总结：
DataCoord 治理 channel 与 segment 的调配；Data Node 次要负责生产和长久化。

DataNode 与 Channel 的关系

如果一个 collection 有四个 channel 的话，可能的分配关系就是两个 Data Node 各生产两个 VChannel。这是由 DataCoord 来调配的。那为什么一个 VChannel 不能分到多个 Data Node 上？因为这样的话就会导致会这个数据被生产屡次，进而导致一个 segment 数据的反复。

RootCoord & Time Tick

Time Tick（工夫戳）在 Milvus 2.0 中算是一个十分重要的概念，它是整个零碎推动的一个要害的概念；RootCoord 是一个 TSO 服务的作用，它负责的是全局时钟的调配，每个申请都会对应一个工夫戳。Time Tick 是递增的，示意零碎推动到哪个工夫点，与写入和查问都有很大关系；RootCoord 负责调配工夫戳，默认 0.2 秒。

Proxy 写入数据的时候，每一个申请都会带一个工夫戳。Data Node 每次以工夫戳为区间进行生产。以上图为例，箭头方向就是这个数据写入的一个过程，126578 这些数字就是工夫戳的一个大小。Written by 这一行代表 proxy 写入，P1 就是 proxy 1。如果以 Time Tick 为区间来进行生产的话，在 5 这个区间之前，咱们第一次读的话是只会读到 1、2 这两个音讯。因为 6 比 5 大，所以他们在下一次 5 到 9 这个区间被生产到。

Data Allocation 数据调配

数据组织构造

Collection，Partition，Channel 和 Segment 的关系：

• Collection：最外层是一个 collection（相当于表的概念），collection 外面会分多个 partition。
• Partition：每个 partition 以工夫为单位去划分；partition 和 channel 是一个正交的关系，就是每一个 partition 和每一个 channel 会定义一个 segment 的地位。
  （备注：Channel 和 shard 是一样的概念：咱们文档里可能有些中央写的是 shard，shard 这个概念和 channel 是等价的。为了前后对立，咱们这里统称为 channel。）
• Segment：
  Segment 是由 collection+partition+channel 这三者一起来定义的。Segment 是数据调配的一个最小的单元。索引以 Segment 为单位创立，查问也会以 Segment 为单位在不同的 QueryNode 上做 load balance。在 Segment 外部会有一些 Binlog，就是当咱们生产数据之后，会造成一个 Binlog 文件。

Segment 在内存中的状态有 3 种，别离是 Growing、Sealed 和 Flushed。
Growing：当新建了一个 segment 时就是 growing 的状态，它在一个可调配的状态。
Sealed：Segment 曾经被敞开了，它的空间不能够再往外调配。
Flushed：Segment 曾经被写入磁盘

Growing segment 外部的空间能够分为三部份：

• Used（曾经应用的空间）：曾经被 Data Node 生产掉。
• Allocated：Proxy 向 DataCoord deletor 去申请 segment 调配出的空间。
• Free：还没有用到的空间。

• Channel：

  • Channel 的调配逻辑为何？
    每一个 collection 它会分为多个 channel，而后每一个 channel 都会给到一个 Data Node 去生产这外面的数据，而后咱们会有比拟多的策略去做这个调配。Milvus 外部目前实现了 2 种调配策略：

    1. 一致性哈希
       当初零碎外部的一个默认的策略是通过一致性哈希来做调配。就是每个 channel 先做一个哈希，而后在这个环上找一个地位，而后通过顺时针找到离它最近的一个节点，把这个 channel 调配给这个 DataNode，比如说 Channel 1 分给 Data Node 2，Channel 2 分给 Data Node 3。
    2. 尽量将同一个 collection 的 channel 散布到不同的 DataNode 上，且不同 DataNode 上 channel 数量尽量相等，以达到负载平衡。
       如果 DataCoord 通过一致性希这种计划来做的话，DataNode 的增减，也就是它上线或者下线都会导致一个 channel 的重新分配。而后咱们是怎么做的呢？DataCoord 通过 etcd 来 watch DataNode 状态，如果 DataNode 高低线的话会告诉到 DataCoord，而后 DataCoord 会决定这个 channel 之后调配到哪里。

  • 那什么时候调配 Channel？

    • DataNode 启动 / 下线
    • Proxy 申请调配 segment 空间时

什么时候进行数据调配？

这个流程首先从 client 开始（如上图所示）

1. 插入申请，而后产生一个工夫戳 - t1。
2. Proxy 向 DataCoord 发送一个调配 segment 的申请。
3. DataCoord 进行调配，并且把这个调配的空间存到 meta server 外面去做长久化。
4. DataCoord 再把调配的空间返回给 proxy，proxy 就能够用这部分空间来存储数据。从图中咱们能够看到有一个 t1 的插入申请，而咱们返回的那个 segment 外面有一个过期工夫是 t2。从这里就能够看到，其实咱们的 t1 肯定是小于 t2。这一点在前面的文章将具体解释。

如何调配 segment？

当咱们 DataCoord 在收到调配的申请之后，如何来做调配？

首先咱们来理解 InsertRequest 蕴含了什么？它蕴含了 CollectionID、PartitionID、Channel 和 NumOfRows。

Milvus 目前有多个策略：

默认的策略：如果目前有足够空间来存这些 rows，就优先应用已创立的 segment 空间；如果没有，则新建 segment。如何判断空间足够？前文咱们讲到 segment 有三局部，一个是曾经应用的局部，一个是曾经调配的局部，还有空余的局部，所以，空间 = 总大小 - 曾经应用 - 已调配的，后果可能比拟小，调配空间随着工夫会过期，Free 局部也就会变大。

1 个申请能够返回 1 或多个 segment 空间，咱们 segment 最大的大小是在 data_coord.yaml 这个文件里有分明定义。

数据过期的逻辑

1. 每一次调配进来的空间都会带一个过期工夫（Time Tick 可比拟）
2. 数据 insert 时会调配一个 time tick，而后再申请 DataCoord 调配 segment，所以这个 time tick 肯定小于 T。
3. 过期的工夫默认是 2000 毫秒，这个是通过这 data_coord.yaml 里的 segment.assignmentExpiration 这个参数来定义的。

何时 seal segment?

下面提到的调配肯定是针对对 growing 这个状态的 segment，那什么时候状态会变成 sealed？

Sealed segment 示意这个 segment 的空间不能够再进行调配。有几种条件能够 seal 一个 segment：

1. 空间应用了达到下限（75%）。
2. 收到 Flush collection 要把这个 collection 外面所有的数据都长久化，这个 segment 就不能再调配空间了。
3. Segment 存活工夫太长。
4. 太多 Growing segment 会导致 DataNode 内存应用较多，进而强制敞开存活工夫最久的那一部分 segment。

何时落盘？

Flush 是把 segment 的数据长久化到对象存储。

咱们须要期待它所被调配到的空间过期，而后咱们能力去执行 flush 操作。Flush 完了之后，这个 segment 就是一个 flushed segment。

那这个期待具体的操作为何？

DataNode 上报生产到的 time tick，接着与调配进来空间的 time tick 做比拟，如果 time tick 较大，阐明这部分空间曾经能够开释了。如果比最初一次调配的工夫戳大，阐明调配进来空间都开释了，不会再有新的数据写入到这个 segment，能够 Flush。

常见的问题和细节

1. 咱们怎么保障所有的数据都被生产了之后，这个 segment 才被 flush？
   Data Node 会通知 DataCoord 目前 channel 生产到那个工夫戳，time tick 示意之前的数据都曾经生产完了，这时候敞开是平安的。
2. 在 segment flush 之后，如何保障没有数据再写入？
   因为 flush 和 sealed 的这个状态的 segment 都不会再去调配空间了，所以它就不会再有数据写入。
3. Segment 大小是严格限度在 max size 这个空间吗？
   无严格限度，因为 segment 能够包容多少条数据是估算失去的。
4. 怎么估算的呢？
   通过 schema 来估算。
5. 如果用户频繁的调用 Flush 会产生什么事？
   会生成很多小的 segment，导致查问效率受影响。
6. DataNode 在重启之后，如何防止数据被生产屡次？
   DataCoord 会记录最新 segment 的数据在 message channel 中的地位，下次调配 channel 时，通知 Data Node segment 曾经生产的地位，Data Node 再进行过滤。（不是全量过滤）
7. 什么时候来创立索引？
8. 用户手动调用 SDK 申请
9. Segment flush 结束后会主动触发

文件构造及数据长久化

DataNode Flush

DataNode 会订阅 message store，因为咱们的插入申请都是在 message store 外面。通过订阅它就能够一直地去生产这个 insert message，接着咱们会把这个插入申请放到一个内存的 buffer 外面。在积攒到肯定的大小后，它会被 flush 到一个对象存储外面。（对象存储外面存储的就是 Binlog。）

因为这个 buffer 的大小是无限的，所以不会等到 segment 全副生产完了之后再往下写，这样的话容易造成内存缓和。

文件构造

Binlog 文件的构造和 MySQL 类似。

Binlog 次要有两个作用，第一个就是通过 Binlog 来复原数据，第二个就是索引创立。

Binlog 外面分成了很多 event，每个 event 都会有两局部，一个是 event header 和 event data。Event header 存的就是一些元信息，比如说创立工夫、写入节点 ID、event length 和 NextPosition（下个 event 的偏移量）

Event data 分成两局部，一个是 fixed part（固定长度局部的大小）；另一个是 variable part（可变局部的大小），是为咱们之后做扩大来保留的一部分。

INSERT_EVENT 的 event data 固定的局部次要有三个，StartTimestamp、EndTimestamp 和 reserved。Reserved 也就是保留了一部分空间来扩大这个 fixed part。
Variable part 存的就是理论的插入数据。咱们把这个数据序列化成一个 Parquet 的模式存到这个文件里。

Binlog 长久化

如果 schema 里有 12345 多列，Milvus 会以列存的模式来存 Binlog。

从上图来看，第一个是 primary key 的 Binlog，再来是 Time Stamp 这个 column，再往后是 schema 外面定义的 12345 每一个 column，它存在 MinIO 里的个门路是这样定义的：首先是一个租户的 ID，之后是一个 insert log，而后再往后是 collection、partition、segment ID、field ID 和 log index。log index 是一个 unique ID。反序列化时把多个 Binlog merge 起来。

最近公布的版本中，有用户反馈说须要指定 ID 进行删除，于是咱们实现了细粒度删除（delete by ID）的性能，自此咱们能够高效的来删除指定的内容了，而不必进行期待啥的；同时咱们减少了 compaction 性能，它能够把 delete 曾经开释了的一部分空间做开释，同时把小的 segment 合并起来，进步查问效率。

目前，为了解决用户在数据量较大且数据是逐条插入的状况下的低效问题，咱们正在做一个 Bulk load 的性能，让用户把数据组织成肯定模式之后，能够将它一次加载到咱们的零碎外面。

如果你在应用的过程中，对 milvus 有任何改良或倡议，欢送在 GitHub 或者各种官网渠道和咱们保持联系～