TAE-MatrixOne 云原生事务与分析引擎

Part 1 摘要

MatrixOne 是一款云原生数据库，不仅支持超大规模数据集上的高性能分析查询，同时具备高吞吐,低延迟的事务读写能力。本文介绍了 MatrixOne 数据库的存储引擎 TAE（Transctional Analytical Engine）的架构。前文介绍了单机 TAE 的相关设计，本文将重点介绍云原生和存算分离相关的几个关键组件。

href="https://zhuanlan.zhihu.com/p/556616209">关于 TAE(Transactional Analytical Engine)的那些事

↑↑↑点击查看前文

很多数据库在使用对象存储时，要么作为冷备使用，要么以牺牲延迟为代价在提交事务时同步写入到对象存储中。TAE 有效的利用云存储资源，将新写入的数据先保存到日志服务的本地磁盘中，随后异步的将日志中的数据转存至对象存储中。这样 TAE 既保留了存算分离的可能性，又避免了过高的写入延迟。

比如说：

• TAE 可以管理远大于本地存储容量的数据。本地内存和磁盘都可以作为缓存，只保存最新被访问到的数据；

• TAE 可以以很小的代价，在一个新结点上装载出完整的数据副本。这对于服务的 HA 还有计算资源的隔离非常的重要。

Part 2 LogService

为了减少写入延迟，TAE 先将最新的数据持久化到日志中，随后异步的转存到对象存储里。所以 TAE 是通过协同日志和对象存储，以保证提交事务的持久性。TAE 抽象出了日志层，可以以很小的代价接入任何日志服务。默认接入的是我们自研的 LogService 日志服务。

日志服务的核心需求有以下几点：

• 高吞吐

• 低延迟

• 高可靠

• 高可用

日志中存储的是最新提交事务的数据，当这些数据被异步转存到对象存储后，相关日志也会被删除。可以把日志看成一个在时间轴上的滑动窗口，TAE 推动这个窗口不断的往前滑动，窗口以外的数据会被清除，并且 TAE 会确保落在窗口内的数据量不会非常大。因此没有必要为日志服务配置大容量的磁盘。

Part 3 DN（Data Node）

在写流程中，TAE 会将提交事务写入日志，并且异步的转存至对象存储。这些都发生在 DN（Data Node）结点。

上图展示了 DN 在执行一些写操作后的状态——上面的是内存状态机，中间的是日志，最下面的是对象存储：

1. 第一个事务添加元数据 Block-1, 并且插入 A、B 两行至 Block-1。事务提交的日志是 LSN=1；

2. 第二个事务插入一行 C 至 Block-1。事务提交日志是 LSN=2；

3. 第三个事务将 Block-1 持久化至对象存储上，修改 Block-1 元数据添加 location=“1”, 产生该 Block 的第二个版本。事务提交日志是 LSN=3。

DN 状态机致力于将日志里的数据转存到对象存储上，但是转存顺序不完全依赖事务日志的单调性，如下图：

LSN[11-17]的已经转存，但是 LSN[3-4,7-10]还在内存状态机内（原因已在单机TAE的文章中解释）。这只是一个临时状态，DN 会根据特定的策略推动日志的窗口不断向前移动。

DN 会在适当的时机选择一个事务作为快照候选点，并等待这个候选点之前的所有事务被转存后，以这个候选点的时间戳作为快照的时间戳保存成快照。当快照生成后，该事务之前所有的日志都可以被清理:

这里我们将快照后所有的日志称为 LogTail。比如上图中“ckp-1” 没有生成前，LSN[1-17]都是 LogTail。DN 出现故障后，只需要从对象存储上读取最新的快照，并且从日志服务中读取 LogTail，便可恢复出完整的状态机。

Part 4 CN（Compute Node）

分布式 TAE 不仅包括 DN, 也包括负责协调所有查询负载的 CN（Compute Node）。当集群加入一个新的 CN, 它会从 DN 获取快照和 LogTail 信息，并且维护一个内存状态机。数据文件会按需从对象存储中拉取，并根据需要保存在缓存中。这种设计不需要在查询之前就拉取大量的数据文件，满足了高弹性 CN 的需求。

>>>举例说明

加入一个 CN 到集群，此时 DN 的状态可以按照事务时间戳描述为[1,150]，表示拥有从时间戳 1 到 150 之间所有事务的数据。

DN 的状态由以下三部分组成:

1. 快照 [0,100]，该快照包含 6 个数据块 [“block-1”, “block-2”, “block-3”, “block-4”, “block-5”, “block-6”]

2. 持久化的数据块 “block-7“ [115, 140]

3. 内存数据块 “block-8” [120, 150]

此时新加入的 CN 状态可描述为 [0, 0]

CN 接收到查询请求，假设该请求的时间戳为 118：

1. CN 检查当前状态机的状态为[0, 0], 最大时间戳小于 118；

2. CN 会向 DN 发出一条读请求，请求 0 到 118 之间的 LogTail；

3. CN 收到 DN 的响应，将 LogTail 应用到本地的状态机；

4. 更新 CN 状态机的状态为 [1, 118]；

5. 开始查询。

CN 接受到时间戳为 130 的查询请求：

1. CN 检查当前状态机的状态为[1, 118], 最大时间戳小于 130；

2. CN 会向 DN 发出一条读请求，请求 118 到 130 之间的 LogTail；

3. CN 收到 DN 的响应，将 LogTail 应用到本地的状态机；

4. 更新 CN 状态机的状态为[1, 130]；

5. 开始查询。

Part 5 协同工作

MatrixOne 支持 CN 的动态扩容以及多个 DN（动态扩容暂时没有支持）。

定义表结构时，可以指定分区键，将表数据分布在多个 DN 上。每个 CN 表数据包含了多个 DN 分区的数据，这有利于一些跨分区的查询。

纵观 DN 的职责，主要有以下三点：

1.提交事务

a.冲突检测

b.写日志

c.应用事务到状态机

2.为 CN 提供 LogTail 服务

3.转存最新的事务数据至对象存储中，并且推动日志窗口

用户的计算负载不会被调度到 DN, 我们认为当前架构下 DN 的数量可以控制在有限个数量，甚至单个 DN 就可以满足大多数的需求。通过扩容 CN 的数量，提高系统的性能。

Part 6 冲突检测

事务被提交到 DN 前，会在 CN 的工作区内做一次基于事务起始时间戳的冲突检测，在被提交到 DN 后，只会与事务起始时间戳到当前最新时间戳内产生的增量数据做检测。

>>>举例说明

1. CN 处理事务 Txn-[t1]的写请求时，会做一次基于时间戳 t1 的冲突检测

2. CN 将 Txn-[t1]提交给 DN, DN 会用 Txn-[t1]的 writeset 和[t1,now]产生的 writeset 做一次冲突检测

增量冲突检测机制，可以提高 DN 处理事务的吞吐能力，不会随着表数据的增长而逐渐下降

Part 7 大事务

大事务通常会占用大量的内存，并且很可能导致冲突检测不够高效。提交大事务和同步大事务的 LogTail 也容易使 DN 成为瓶颈。

这里通过三种方式支持大事务:

1. CN 在提交事务前，将事务的数据建好相关索引，并写入到对象存储中，提交至 DN 的只有相关元数据；

2. DN 在提交事务时，利用相关的索引加速检测；

3. DN 在提交事务时，只更新元数据。

当前 MatrixOne 已经发布 0.6 版本，也是新架构下的第一个版本，还有很多不足。我们会在之后 0.7 和 0.8 的版本重点攻克性能和稳定性相关的问题。本文没有深入探讨一些技术细节，后续将会一一分享