Anti-Caching:一种新型数据库管理系统架构

来源:互联网 发布:血源诅咒saber捏脸数据 编辑:程序博客网 时间:2024/05/04 01:54

1.写在前面

之前的三篇博文主要介绍了NVM(Non-Volatile Memory)和数据库相关的内容。NVM因其读写性能接近DRAM、可字节寻址、非易失、大容量等特点,在计算机科学的许多领域都具有非常身后的发掘潜力。而我目前研究的数据库方向只是NVM所应用的一个小小的领域分支而已。

上一篇博客介绍了两篇论文,它们都是将已有的数据库系统(或者是将该系统的某种机制)重新实现在NVM架构上,进行一番讨论,给出未来的数据库结合NVM的可能方向。

从启发性上来讲,CMU、BROWN大学和Intel实验室合作的工作成果具有非常深远的意义和十分现实的研究价值。

今天,给大家介绍的就是他们三者合力做出的另一个研究,这一研究于2013年发表于数据库顶会VLDB上,论文链接如下:

Anti-caching:A New Approach to Database Management System Architecture,VLDB,2013

2.本周回顾

在深入介绍Anti-caching这篇论文之前,我先来总结下前一周看得相对比较有启发价值的论文(当然,我并不是只在读论文)。

第一篇论文是发表于IEEE Computer Society的Survey:How Persistent Memory Will Change Software Systems,它高屋建瓴地总结了Persistent Memory的特性,指出这种内存在诸如File system,Database, virtual memory management等领域的可能应用。对于刚刚了解NVM(或者说成是SCM,PM也罢)的研究者来说,是一个具有提纲挈领作用的启发式论文。
当然,它有一个缺点,就是在每个方向上展开都不丰富也不严密,看完之后可能会有走马观花的感觉,但是如果你想要了解NVM可能在哪些场景发挥作用的话,建议读一读,之后更加细节具体的研究就需要再去查阅更多相关文献了。

第二篇论文是FPTree: A Hybrid SCM-DRAM Persistent and Concurrent B-Tree for Storage Class Memory,SIGMOD,2016,是一个非常新颖的研究。之前我几乎没有看到研究者只针对数据库中的B+ Tree做持久性方面的优化,但这篇文章就匠心独运地提出来通过将索引数做成Persistent,concurrent B+ Tree,可以将数据持久化而且与那些易失性树结构相比,没有明显的开销。它是在传统的Hardware Transactional Memory基础上,利用了SCM-DRAM混合架构,引入fingerprinting技术,达到的研究效果。
然而,遗憾的是,对于目前的我来说,这篇论文仍然显得太过复杂了,主要是它的base knowledge我学习地还不够。所以也只是大概看了一下的他的工作,技术细节没法讲得清楚。如果哪位研究者对此新成果有兴趣且有这方面的知识基础,相信阅读这篇论文会有很大的裨益。

第三篇论文就是今天要着重介绍的Anti-caching了,有趣的是Anti-caching本身并没有跟NVM结合,它是对现有的面向内存的数据库系统的一种改进(关于memory-oriented的含义待会会进一步介绍)。因此,如果能够在Anti-Caching的基础之上,针对NVM的优势做优化,使之性能更高,也是一个非常有趣且值得一做的尝试。

3.论文介绍

(1)问题背景

数据库发展的历程是以高性能1为目标的,而基于disk的数据库系统将磁盘作为数据的主要存储设备,只在DRAM上做buffer pool,缓存一小部分热数据。当transaction来临时,若数据不在内存中,就必须读取磁盘,因此磁盘IO成为了disk-oriented database system2的性能瓶颈。除此之外,面向磁盘的数据库系统一般采用并发机制来加快transaction执行的速度(多线程访问),因此在操作过程中可能会有锁冲突3发生。

随着DRAM的存储空间增大,数据库系统设计者们想到可以将数据迁移到内存中进行,而不再将磁盘作为数据库的存储设备。这就是memory-oriented database system4的基本思想。面向内存的数据库系统大大提升了transaction执行的速度,也省去了复杂的并发控制开销与繁重的数据logging。但是面向内存的数据库系统存在一个不可避免的问题,它的性能只有在数据库数据量小于可用内存空间大小的时候才好。一旦内存装不下整个数据库,就会发生page fault,当前transaction任务的执行就会终止。
因此一旦数据大小超出内存容量时,作为任务执行者和操作者就只有两个选择:第一是换一个更大容量的物理内存;第二是什么都不做,看着它的性能跌落会disk-oriented database system。

由于以上两种数据库系统各有各的弊端,Anti-caching的研究者试图构思出一种良好的方案,解决大容量数据与有限空间内存之间的矛盾,从而提升整个数据库系统的性能。

(2)Anti-Caching系统设计

这里写图片描述
Anti-Caching 系统结构图如上图(c)所示,它是基于H-Store5实现的改良版本的内存数据库系统。它的特点是,在执行transaction之前,仍然像传统的面向内存数据库系统那样把所有数据装入DRAM中,随着transaction的执行,数据库会变得越来越庞大。当数据量超过操作者设定的一个阈值以后,就弹出(evict)冷数据组6到磁盘上。此时数据的存放地点是唯一的,即热数据都在内存中,冷数据都在磁盘上,不存在某些数据既在磁盘又在内存中的情况。
那么,我们自然会产生这样一个问题:如果某个transaction想要访问被弹出的冷数据,该怎么办?
这个时候,数据库系统会中断当前的transaction,并开辟一个新线程执行“prepass”过程,来取回冷数据。与此同时,下一个transaction是允许异步执行的。这样就提高了整体的执行速度。具体的prepass流程比较复杂,但是论文在这一点上是有详细描述的,流程图如下所示:
这里写图片描述
如果感兴趣的话,建议阅读该论文的第三部分最后一小节。

整个Anti-Caching的原理概括起来就是这么简单,因为它将冷数据弹出到disk的Block table(也就是Anti-cache)中,这刚好与面向磁盘的数据库将DRAM作为数据Cache完全相反,所以这一系统机制的名称就是Anti-Caching。

(3)性能评测

评测采用的Benchmark依旧是业界标准YCSB与TPC-C。
与Anti-Caching相比较的是另外两个系统:MySQL与用分布式cache优化的SQL。H-Store作为一个面向内存的数据库系统的Baseline而存在。
性能对比图如下所示:
这里写图片描述
从上述的性能对比中,可以得出很多有趣的结论:
第一,随着数据库数据量的增大,所有系统的性能都发生了下降,这是因为disk read和write增加的缘故;
第二,随着skew7的降低,所有的系统性能也都发生了下降,这是因为访问evicted data的频率变高了,需要进行更多的磁盘IO;
第三,对于high skew工作负载,Anti-caching要远远好于MySQL,这是因为一方面H-Store的轻量级并发控制机制(我对此并没有深入研究)比MySQL的更加高效,另一方面Anti-cahing的细粒度管理使得tuples不会在内存和磁盘中反复换入换出,大大减少了抖动现象的发生。
关于aLRU与LRU这两条曲线,其区别在于根据transaction采样,从而维系LRU链表。aLRU是1%采样,LRU是100%采样。从图上可以看出,aLRU要比LRU性能更高,说明采样时一种有效节约空间资源的方法,也避免了每次transaction都要重新整理LRU链表的过程。

4.我的思考

可以肯定的是,这是一篇非常漂亮的论文,每一个部分的设计都很合情合理,也加入了很多研究者自己构思出的新技术以解决Anti-cahcing机制带来的新问题。
但是,如果非要概括一下的话,他们的主要贡献并不是Anti-Caching机制本身,而是“prepass”过程的异步控制transaction执行。因为传统的面向内存数据库系统在内存过载的情况下完全可以直接退化为Anti-Caching模式,组织冷数据,弹出到disk中,以某种形式(块,集合,hashmap)存放。

而对于我来说,该汲取Anti-caching机制的哪些优点/特点,为我所用,并结合NVM的优势,使性能再进一步提高,才是重点。
想解决的问题有:在大数据量database的情况下,如何使系统系能具有非线性下降的特性(比如缓慢的亚线性下降)?或者是在low-skew情况下,如何使得系统不至于因为IO成为性能瓶颈?

试想,如果将NVM作为Anti-cache的存放空间,至少IO问题将得到有效缓解,因为NVM的读写性能是2xDRAM-8xDRAM;另一方面,如果将NVM作为DRAM替代品来使用,Anti-Caching机制也就不再有意义,因为NVM本身就可以保证大数据量存储。

那么是否可以往上一层再考虑一下,如何缓解cache miss的问题?
似乎NVM本身并不能带来多大的性能改善······
那并发控制和数据一致性保证呢?恢复速度?
NVM可以省去breakpoint的工夫,只做logging即可。

目前似乎还没有特别清晰的思路,也是在摸索中前进。哪怕只能在现有的系统上做出一点点的改善,哪怕只改善了某一个负载场景下的性能,对我来说也一定是非常有意义的工作。
加油!


  1. 衡量数据库性能的主要方法是执行OLTP负载,以其每秒钟执行的transaction数量来评判性能是高是低。 ↩
  2. disk-oriented database system,即面向磁盘的数据库系统,是最早出现的数据库系统设计。它将全部数据放在磁盘中,随着transaction的进行,而将热数据缓存到DRAM中。 ↩
  3. 之所以要加锁,是为了防止多线程访问同一数据(比如record)时进行修改造成的数据不一致。 ↩
  4. memory-oriented database system,即面向内存的数据库系统。它在开始执行transaction之前,就将全部数据库数据加载到内存中,只用disk做logging和breakpoint。 ↩
  5. H-Store是一种经典的面向内存的数据库系统,是由Brown大学开发。它的一个商业实现版本是voltDB。 ↩
  6. 冷热数据的区分是由内存中的维持的一个LRU链表来表征的,表头是最近不被访问的数据,表尾是最近最常访问的数据。这里的数据不是按块(block)而是按元组(tuple)来区分的,因此具有细粒度的特点。 ↩
  7. skew指的是transaction是否对某些数据有更高的访问频度,high skew指大部分transaction只对一小部分数据进行操作,low skew指transaction对数据的访问比较均匀。 ↩
1 0