新硬件的舞台—2018 SIGMOD论文之硬件发展下的数据库系统

小蚂蚁说:前面的两周时间里,为大家带来了三篇2018SIGMOD 的论文解读。今天是SIGMOD系列的最后一篇文章,我们将一起畅聊新硬件领域,与你共同探讨硬件发展下的数据库。

SIGMOD论文系列收官之作!7月24日晚8点,蚂蚁金服资深技术专家虞舜将带来《OceanBase在蚂蚁金服的智能运维实践之路》的技术直播!感兴趣的朋友可移步到文末查看参与方式。

本文作者:颜然

蚂蚁金服 OceanBase 团队资深技术专家,OceanBase 初创成员之一,目前负责事务引擎以及性能优化相关的研发工作。

前不久我和蚂蚁金服的几位同事一起参加了在休斯顿举行的 SIGMOD 会议,见到了数据库领域学术界最优秀的老师和学生,也了解了学术领域现在主要的研究课题。几天的会议中,有很多机会和参会的学生当面交流,除了探讨数据库的议题,也结识了这些优秀的学生。

一个让人欣喜的状况是 OceanBase 在华人学生中知名度颇高,大家或多或少都了解蚂蚁金服的 OceanBase 数据库已经在支撑很多重要的金融业务场景。不少学生还饶有兴致得向我了解一些技术细节和应用场景,以及未来的发展计划。

这篇文章我将探讨新硬件的发展对于数据库系统的影响。数据库系统是硬件和用户需求之间的桥梁,数据库通过巧妙的架构和精细的实现把硬件的能力和特性更好发挥出来,解决用户存储和检索数据的问题。任何硬件的革新都会推动软件发生变化,并将长久影响软件的架构。所以,了解硬件的发展,对于数据库系统非常重要。

下面将要描述三个方向的新硬件,首先是NVM,这是存储介质的变化;其次是 RDMA,这是网络连接技术的发展;最后是GPU,这是计算能力的革新。每个方向选择一篇今年 SIGMOD 的论文详细解读。

NVM方向

非易失性内存(NVM)是现在很火的方向,作为一种存储设备,NVM可以与固态硬盘一样持久保存数据,又与内存一样通过内存通道进行读写。而且NVM支持字节寻址,相比较传统硬盘只能以块(Block)为单位进行读写,字节寻址可以为数据结构设计提供更多的选择。

一直以来大家对NVM设备讨论的火热,但是量产的可靠产品少,真能用上的人很少。但是今年,Intel发布了基于3D XPoint技术的Optane Persistent Memory,是对NVM的发展一次很重要的推动。期待越来越多的硬件大厂推出丰富的产品,让NVM产品走进更多的场景。

去年 SIGMOD 专门为 NVM 准备了两个 Tutorial 来介绍 NVM 特点、对数据库系统的影响、新科研的方向等,可谓极其重视。今年,来自 TUM 的团队又贡献了一篇论文,探讨了 NVM 上数据存储的一个新思路。

Managing Non-Volatile Memory in Database Systems

TUM 的硬件方向很强,是数据库新硬件研究方向的领跑者。去年 SIGMOD 有一篇来自 TUM 研究 GPU 上做排序的文章,今年这一篇是关于如何更好的使用非易失性内存(NVM)存储数据。NVM 是个好东西,但也有其自然的属性。放在整个存储体系里看,NVM 可以持久存储数据但是比磁盘和固态盘价格都贵,NVM 可以字节寻址但是比内存的访问延迟要大。所以,如何在数据库里发挥 NVM 的能力是一个很挑战的问题。

之前的解决方案里,一种是用 NVM 直接替换内存,NVM 支持字节访问,所以内存的数据结构不用改动,但是因为 NVM 延迟大,整体存储的性能会有很大下降;另外一种是用 NVM 替换磁盘或者 SSD,数据的访问和修改还是以页面(Page)的方式先加载到内存中。这是经典数据库的结构,没有改造的负担,但是却不能充分利用 NVM 支持字节寻址的能力。这两种方案分别对应下图中 (a) 和 (b)。

这篇文章提出了一种新的数据管理方式,目的是既发挥 NVM 字节寻址能力,又发挥 NVM 访问速度比 SSD 快的特性,利用内存、NVM、SSD 的三层结构来更好的支持数据存储,也就是上图中 (c) 所表示的结构。文章的思路是数据存储在SSD 中,NVM 使用传统的以 Page 为单位的接口从 SSD 中读写数据。那么如何发挥 NVM 的字节寻址能力呢?内存不再需要从 NVM 中读取完整的 Page,而是以 cache line 的粒度来加载数据。

如上图所示,在内存中 Page 的头部维护的一个 header 数据结构用来表示哪些cache line 已经加载到内存中,不访问的数据不加载,大大减小了以 Page 粒度读写数据造成的放大问题。

同时,文章还提出了一种减小内存占用的Mini Page 数据结构。之前的方案利用了 NVM 随机访问快的特点减小了传输的数据量,如果没加载的数据在内存中也不用白白占用空间就更好了。

如上图所示的 Mini Page 结构,header 中添加 slots 信息,表示行位置的间接引用关系。从 NVM 中加载到内存中的数据不需要按照 Page 原始的行排列顺序存储,转而用 slots 表示其在内存中实际存储的位置,那么内存中的Page 也就不需要准备整个页面大小的内存了。

感兴趣的读者可以阅读论文原文了解更详细的内容。

RDMA方向

远程直接内存访问(RDMA)是一种跨机器直接进行内存访问的技术,不需要 CPU 和操作系统介入,能做到高吞吐量和很低的延迟。这种网络互联技术出现了很长时间,也在一些数据库中得到过运用。但是因为其网络基础设施的特殊要求,RDMA 的使用场景一直受限制。

最近几年 RoCE(RDMA over Converged Ethernet)和 iWARP(Internet Wide-area RDMA Protocol)等新标准的持续发展,基于以太网的技术使得硬件更标准化、价格更低,RDMA 技术获得了更广泛的关注。OceanBase也一直在关注 RDMA 技术的发展,RDMA 的低延迟特性可以在分布式环境下帮助 OceanBase 给用户更好的数据库使用体验。

今年 SIGMOD,来自 University of Michigan 的实验室完成了一个基于RDMA 技术的分布式锁管理器,挺值得介绍。

Distributed Lock Management with RDMA: Decentralization without Starvation

RDMA 支持原子操作,这是实现锁的基础。CAS (Compare-And-Swap) 原子操作是原子的执行一次比较和一次赋值,CAS 操作需要指定 3 个参数:目标变量、原始值、修改值,执行的过程是将目标变量里当前的内容和原始值进行比较,如果是相等的,则把修改值写入目标变量,如果不相等,则不做操作并返回失败。现有的锁管理器都是基于 CAS 来完成功能的。但是当锁冲突很大的时候,基于CAS 的操作会出现频繁的冲突导致的操作失败,失败后需要进行反复的重试,而且重试的次数不确定,最终可能表现出来的是加锁操作耗时抖动很大。

这篇文章的方案是不依赖 CAS 操作,改成用 RDMA 支持的另一种 FA(Fetch-and-Add) 原子操作。FA 操作需要指定 2 个参数:目标变量、差值,执行的过程是将目标变量内的值读出并加上差值再写入目标位置,同时返回之前的值。FA 与 CAS 最大的不同点是 FA 操作不会失败,也就不用考虑失败后的重试。所以基于 FA 实现的锁也就不会因为冲突大导致加锁操作耗时不稳定。

作者使用的核心算法是 Lamport's Bakery Alogrithm。这个算法类似于餐厅的等位系统,每个需要加锁的操作都先获得一个排号,这个排号是连续递增的一个数字(用 max 表示)。另外一个连续递增的数字表示当前持有锁的排号 (用n 表示),解锁操作就是将 n递增 1,意味着下一个排号的操作获得了锁。放在 RDMA 原子操作一个 64bit 的变量内,并且要支持互斥锁和共享锁,作者将 64bit 的变量分成了 4 个 16bit 的元素,nx、ns 分别表示当前持有互斥锁或共享锁的排号,maxx、maxs 分别表示下一个加锁操作拿到的排号。如下图所示:

加锁操作就是让对应的 max 值执行 FA 原子操作,如下图所示,表示加一个互斥锁:

以上就是文章最核心的算法。关于数值溢出、故障以及死锁等异常情况,文章中都提出了相应的解决方案,具体请继续阅读论文原文。

协处理器方向

GPU 这些年飞速发展,影响力逐渐大过 CPU,在 AI 领域使用 GPU 计算模型已经是标准配置了。在数据库领域使用 GPU 来做 SQL 查询加速,也可以获得数量级的性能提升。下面这篇文章来自 TU Dortmund University,也是一个做硬件方向很强的团队。

Pipelined Query Processing in Coprocessor Environments

GPU 的计算能力越来越强大,用于数据处理时其处理的速度很容易就超过数据传输的速度,所以带宽瓶颈是限制 GPU 处理速度的重要原因。传输带宽又分为 Main Memory 和 GPU Global Memory 之间的传输通道以及 GPU Global Memory 与 Scratchpad Memory 之间的传输通道。

如上图所示,在 Main Memory 中的数据传输到 GPU 中进行计算再传输回 Main Memory 的过程要跨越这两个内存传输通道,任何一处都有可能出现瓶颈。

已有的解决方案中,通过使用批量处理的方式,把每一块传输到 GPU 的数据进行多个算子的处理,大大减少数据中间结果在 Main Memory 和 GPU Global Memory 的传输。在减少 GPU Global Memory 和 Scratchpad Memory 之间传输方面,有向量化处理和编译执行两个方式可以使用,这两种优化方法是传统 DB 在优化 CPU Cache 利用率时常用的方案,转化成 GPU 上的逻辑会引入很多复杂性。

这篇文章使用了 Pipeline 的思想,提出了 Compound Kernel 的概念,其目的是把计算逻辑、算 prefix 和写回逻辑放在一个 Kernel 里,减少了写回 Global Memory 的数据量。仅这一个方案就可以将 Global Memory 操作的数据量减少到之前的 41%。作者还测试了各种业务场景下的优化,有兴趣的读者可以参考论文原文。

今天的讨论就到这里,如果想继续交流新硬件方面的话题,欢迎扫码添加微信交流群。

全网首发!OceanBase开直播啦!

为了给大家带来更好的互动感受,SIGMOD论文系列的收官之作将通过直播的形式为大家奉送。

7月24日晚8点,OceanBase的资深运维专家虞舜将结合SIGMOD大会的优秀论文以及OceanBase自身在智能运维领域的实践,为所有技术爱好者们带来《OceanBase在蚂蚁金服的智能运维实践之路》的技术直播。

▼还等什么,赶紧扫码进群看直播吧!▼

OceanBaseTechTalk · 杭州站

7月29日,OceanBase TechTalk 第一期线下技术交流活动将在杭州启动。届时,OceanBase三大元老级的资深技术专家:柏泽、虞舜、颜然,将跟你聊聊OceanBase最新的技术变化和发展,从SQL引擎,事务引擎,到智能化运维实践。就像很久不见的老朋友一般,希望能坐下来一起分享这些你关心的事。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180723G1JLLE00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券