Polardb X-engine 如何服务巨量数据情况下的业务 （翻译）- 4

这开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请微信联系 liuaustin3 ，（共2150人左右 1 + 2 + 3 + 4 +5）新入群的将默认分配达到5群）,另欢迎 OpenGauss 的技术人员加入。

接上期---写入路径，写路径是我们优化接受每个子表LSM-TREE的记录的内存表结构开始，接下来我们介绍如何设计写入任务队列和多阶段管道，这些队列和管道被X-ENGINE中所有子表的LSM-TREE共享，我们先来介绍多版本内存表，将内标实现为一种无锁跳表，类似于其他许多系统，以实现良好得查找和插入性能，然而基于调表的内存表的最新实现在查询热点记录时存在性能问题，对单个记录的频繁生成许多新版本，如果一个热点记录与一个只对最新版本的查询感兴趣的查询匹配，查询可能需要扫描许多旧版本才能定位到所请求的版本，当客户在热门商品上下订单是，电子商务平台上的在线推广会放大这些冗余访问。

在X-Engine中我们将相同记录的新版本追加到原始几点的下方，垂直形成一个新的链表，下图展示了结构，蓝色的节点存储具有不同的键的记录，黄色节点存储同一记录的多个版本，不同的键以跳表的方式组织，而每个键的多个版本则存储在一个链表中，绿色的为版本号，图中99为最新的版本。

事务中的异步写入，在像innodb这样的存储引擎中，传统的线程和事务一一对应的写入效率，存在有明显的缺点，这种方法中，用户线程从开始到结束执行一个事务，虽然这种方法使得实现写入的执行和事务的并发变得容易，但线程必须等待写入日志的场延迟磁盘操作完成，在X-Engine中，我们选择了另一种方法，将写入的提交与其对应的事务解耦，并将他们分组进行批量处理，如下图我们首先将写入任务分布在多个无所写入任务队列之间，然后，大多数线程可以异步返回处理其他的事务，只有一个线程与提交写入的任务多接单管道交互，通过这样的方式事务中的希尔变得异步，在高并发的工作负载下，这样可以允许更多的线程处理来自并非事务的写入任务，队列的优化数量首先与机器上可用的I/O带宽，以及多个线程之间的对线程蓄力来自并非事务的写入任务，队列的优化数量首先于机器上可用的I/O带宽以及多个线程之间对每个无所队列头部的竞争，我们发现在32核心的机器上，每个队列的八个线程可以饱和I/O带宽，为每个队列分配更多的线程倒是会导致性能下降。

在这个解耦的过程后，我们将相同的队列中的写任务进行分组，并批量处理，和单个事务提交相比，批量提交可以显著的提高I/O，从而提高吞吐量，这里的每个阶段交替访问主内存和硬盘，在第一阶段中，日志缓冲线程将每个写请求的雨鞋日志从事务缓冲区手机到内存中的日志缓冲区，并计算他们对应的CRC32错误检测吗，这里涉及大量的计算，和内存的访问，后面就是日志的刷新，线程将缓冲区中的日志刷新到硬盘上，日志被刷新后，日志文件中的日志序列号会增加，然后，这些线程将已经记录的写人物推入下一个阶段，写内存表，这个阶段多个线程并行将往活动的内存表中追加记录，这个阶段只涉及，主内存访问，所有这些写操作可以在故障后从WAL中恢复，最后是提交阶段，所有任务都完成后，事务由多个线程并行提交，释放他们所使用的资源，比如锁定。

在这个流水线中，我们根据各个阶段的需求分别调度线程，使得每个阶段的吞吐量与其他阶段匹配，从而最大化总的吞吐量，虽然前三个阶段都需要大量的内存参与，但前两个阶段访问的主内存中的不同数据结构，而第二个阶段是将数据写入到硬盘，因此可以将他们进行重叠，提高主内存和硬盘的使用率。

这里我们限制了每个阶段的线程数量，前两个阶段存在强依赖，我们只为每个阶段分配一个线程，对于其他的阶段，我们分配多个线程进行并行处理，所有线程拉去任务进行处理，从前两个阶段拉去任务的方式是抢占式的，只允许先到达的线程处理该阶段，其他阶段是并行的，允许多个线程处理。

刷新与压缩，在level0中，我们通过加快舒心避免X-Engine 运行时内存不足，与错误，这种错误在事务量激增的时候，常见。在X-Engine中，每个刷新操作将其补课表的内存表转换，并将其附加到level0中并在捕鱼现有记录合并的情况下离开，然而这个过程会留下一组无需的extent，并将其附加到level0中，并在捕鱼现有记录合并的情况下离开，这个过程会留下一组无序的extent，查询必须访问所有的extent，找到匹配潜在的匹配项，这个过程设计的磁盘IO是昂贵的，虽然level0 的大小可能只占整个存储的1%，但他包含的记录与内存表中最近插入的记录只相差很小，由于电子商务工作负载中存在强雷的时间局部性，进入查询很可能需要这些记录，因此我们将level0 中的extent称为热的extent。我们引入了level0 内部压缩来主动合并level0中的热extent ，而不是将合并后的extent推到下一个level1， 这种方法将热记录保留在lsm树的第一层，放置查询深入树结构以检索这些记录，另一个方面，由于level0的大小相对较小，与其他层次相比，level0 的大小相对较小，与其他的层级相比，LEVEL0内部的一哈所只需要访问一个下部分的extent ,和其他的压缩需要在更深层次进行合并是不同的，由于cpu和i/o都是轻量级的消耗，因此level0内部压缩可以频繁的执行。