详解新硬件环境下日志模块的设计与演进
|
【技术】本文根据朱阅岸老师于第九届中国数据库技术大会(DTCC 2018)的现场演讲《新硬件环境下日志模块的设计与演进》内容整理而成。 讲师介绍：
朱阅岸，中国人民大学博士，现供职于YY Research LAB。研究方向主要为数据库系统理论与实现、新硬件平台下的数据库系统以及TP+AP型混合系统。 分享提纲： 1、现代处理器及新型存储的发展 2、传统的数据库系统日志模块设计 3、面向新型硬件的日志子系统设计 4、总结 演讲内容： 大家好，我今天带来的主题是“新硬件环境下日志模块的设计与演进”。该topic对近些年来工业界与学术界在日志子系统的优化进行总结，尤其是新硬件环境下的工作。分享由四部分组成，首先介绍一下新硬件和信息存储的一些发展，题目中的新硬件主要是指现代处理器和新型存储这两种。我会简要回顾一下数据库系统经典日志模块设计的原理和不足，然后是面向新硬件的一些日志子系统设计的方法，最后是总结。 一、现代处理器及新型存储的发展 我们首先简要回顾一下处理器的发展趋势。由于能耗与制造工艺的原因使得处理器制造商不再追求高频率，而是转向片上多处理器技术，也就是多核技术。现在服务器配备几十个CPU处理已经很常见了，一些厂商甚至推出了成百上千个处理核心的处理器，“众核”的概念开始流行起来。 另一方面大家可能没有注意到，非易失性内存开始从实验室走向工业界，例如Intel傲腾，这类存储具有磁盘的持久存储特性与接近内存的访问速度，可以实现字节寻址，也就是使用CPU的load与store指令直接寻址。总体来说，它的主要特性是非易失、低延迟、高密度和读写不对称。可以看到，非易失性内存的存储容量比较大，可以达到内存的2到4倍左右，但是也有读写不对称的一些问题。 目前实现非易失性内存的主流技术有四种：这里简要介绍一下非易失性内存的实现原理，可以分为四类。第一类是采用相变存储。相变存储器主要由相变材料、加热体、存取设备组成。通过加热体对相变材料进行加热材料会出现结晶与非结晶两种状态，呈现低电阻与高电阻，这对应与1和0;第二类是使用自旋磁力矩。自旋磁力矩的一个单元由固定层，自由层以及隔离层组成。对磁性材料施加电流会改变自由层的磁性方向从而使得存储单元具有低电阻与高电阻的二元状态;第三类是使用铁电材料：铁晶体管在电场的作用下会使得中心原子出现高极化电荷与低极化电荷。这种铁电材料的二元稳定状态使得它可以作为存储介质;最后是采用忆阻器技术。简单说，忆阻器是一种有记忆功能的非线性电阻。它可以记忆流经它的电荷数量，控制电流的变化可改变其阻值。如果把高阻值定义为“1”，低阻值定义为“0”，则这种电阻就可以实现存储数据的功能。非易失性内存是忆阻器的最简单应用。它的最大用途还是构造类大脑的硬件，为AI实现质的突破。 我们来看一下非易失性内存、闪存以及内存之间的对比参数。由于PCM(Phase Change Memory)最具市场前景，我们将基于相变存储的非易失性内存与flash与DRAM进行比较。
相比flash，PCM可以实现字节寻址，在读写速度上快2-3个数量级左右，同时读写寿命与能耗也有大幅改进。相比DRAM，PCM的读写延迟与带宽稍微逊色，但是在闲时能耗以及密度令人眼前一亮。在闲时能耗方面，PCM是DRAM的1/100。这主要是DRAM需要不断刷新电容来保持存储单元的内容，而PCM并不需要这样子的操作。能耗是数据中心最关心的一个问题，非易失性内存在大型数据中心的具有非常大的优势。 回到软件设计，其实在我们的观念里在非易失性内存出现之前，内存与外设存在着巨大的性能差距。为了弥补这个差距，软件系统都会加上一层buffer，减少与外设打交道的频率。数据库系统有数据buffer和日志buffer，一般使用的steal与no force策略。也就是说，事务提交时刻无需刷脏页，直接将日志写出即可。这个模式是针对磁盘时代而设计的，在某些工作负载下，日志模块容易成为系统瓶颈。 09年的时候，CMU的研究人员对几款流行的开源数据库系统进行了详尽的研究，验证了上述的观点，这几款开源的数据库系统都不能很好地利用底层硬件设施。随着并发线程的增加，上述系统性能都遭受了不同程度的下降。尤其是，事务真正花费在实际工作上的时间只占12%左右。缓冲区管理/锁管理器/日志模块耗费了大部分的事务执行用时。其主要原因是关系数据库系统的研发。时至今日，MYSQL的日志管理/锁管理以及Pg的缓冲区管理与日志管理都是一个大问题。他们的研究论文具有里程碑的意义，拉开了开源系统在多核处理器时代优化的序幕。 总体来看，现在硬件发展就是CPU向多核、众核发展，非易失性内存开始从实验室走向工业界。非易失性内存的出现弥补了DRAM和持久性存储设备性能差距的鸿沟。有了非易失性内存以后，系统开发人员可以认为内存与外设之间的一个性能差距问题不复存在。在新硬件环境下，上层软件必须去适配底层硬件的发展，才能获得硬件上的红利。 二、传统的数据库系统日志模块设计 接下来我们简要回顾一下日志模块的设计和不足。其实现在来看，InnoDB的性能瓶颈目前主要集中在锁管理器与日志模块，PostgreSQL的性能瓶颈体现在缓冲区管理模块与日志模块。日志模块有一个通病，数据库通常采用集中的WAL方法实现，经常会引发热点问题。
传统的日志提交主要有三个步骤，首先要获取写日志缓冲区上的排他锁，然后递增LSN, 代理线程将事务日志记录拷贝到日志缓冲区相应位置，最后释放缓冲区上的锁。当然在两三年前(至少开源数据库系统)数据库系统都是这么干的，现在大家都已经发现这个问题了。 我们先看看MySQL 8.0版本之前，InnoDB是怎么提交日志的。当提交一个mini transaction时，需要将记录数据的更改日志提交到公共buffer中，并将对应的脏页加到flush list上。入口函数为mtr_t::commit，执行过程如下： 1. mtr_t::Command::prepare_write 获取log_sys->mutex 2. mtr_t::Command::finish_write 将日志从mtr中拷贝到公共log buffer。这里需要考虑block空间不足的情况(持有log_sys->mutex) 3. 若本次事务产生脏页，申请flush list mutex随后释放log_sys->mutex。 这三个步骤完全遵循上述的日志提交方法。 PostgreSQL也有相同的问题，9.4版本之前日志提交的临界区设计的相当粗糙，事务执行的关键路径的代码长度大概有300行左右。 （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
