Part 1 摘要

MatrixOne是一款云原生数据库，不仅反对超大规模数据集上的高性能剖析查问，同时具备高吞吐,低提早的事务读写能力。本文介绍了MatrixOne数据库的存储引擎TAE（Transctional Analytical Engine）的架构。前文介绍了单机TAE的相干设计，本文将重点介绍云原生和存算拆散相干的几个要害组件。

点击查看前文对于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在执行一些写操作后的状态——上面的是内存状态机，两头的是日志，最上面的是对象存储：

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

  • 第三个事务将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的状态由以下三局部组成:

  • 快照 [0,100]，该快照蕴含6个数据块 [“block-1”, “block-2”, “block-3”, “block-4”, “block-5”, “block-6”]
  • 长久化的数据块 “block-7“ [115, 140]
  • 内存数据块 “block-8” [120, 150]
    此时新退出的CN状态可形容为 [0, 0]

    CN接管到查问申请，假如该申请的工夫戳为118：
  • CN查看以后状态机的状态为[0, 0], 最大工夫戳小于118；
  • CN会向DN 收回一条读申请，申请0到118之间的LogTail；
  • CN收到DN的响应，将LogTail利用到本地的状态机；
  • 更新CN状态机的状态为 [1, 118]；
  • 开始查问。

    CN承受到工夫戳为130的查问申请：
  • CN查看以后状态机的状态为[1, 118], 最大工夫戳小于130；
  • CN会向DN收回一条读申请，申请118到130之间的LogTail；
  • CN收到DN的响应，将LogTail利用到本地的状态机；
  • 更新CN状态机的状态为[1, 130]；

  • 开始查问。

    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后，只会与事务起始工夫戳到以后最新工夫戳内产生的增量数据做检测。
    举例说明

  • CN处理事务Txn-[t1]的写申请时，会做一次基于工夫戳t1的冲突检测

  • CN将Txn-[t1]提交给DN, DN会用Txn-[t1]的writeset和[t1,now]产生的writeset做一次冲突检测
    增量冲突检测机制，能够进步DN处理事务的吞吐能力，不会随着表数据的增长而逐步降落

    Part 7 大事务

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

  • CN在提交事务前，将事务的数据建好相干索引，并写入到对象存储中，提交至DN的只有相干元数据；
  • DN在提交事务时，利用相干的索引减速检测；
  • DN在提交事务时，只更新元数据。

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