火狐体育

Quick guide

学术动态

首页 > 教学科研 > 学术动态

主存数据库分析及主流产品比较(一)

发布日期:2020-10-13    点击:976

8月26日星环邀请来自华东师范大学软件工程学院的博士生导师宫学庆教授带来 《数据库前沿技术系列讲座》 分享数据库业内前沿生长和研究热点。现将宫学庆教授的培训第一讲内容:内存数据库的技术生长分享给大家。

— 基于磁盘的数据库治理系统

现代硬件情况

从1984年到1994年,学术界提出了许多关于内存数据治理的假设,如内存缓冲区可以容纳所有数据,可以接受组提交和快速提交优化技术。同时也提出面向内存的数据会议方法不再像基于磁盘的DBMS那样接受Page ID Offset进行会议,而是直接接受所有数据结构中的内存地址。此外,面向记忆的T树索引结构和系统根据功效分为若干处置惩罚引擎。有的专门做事务处理处罚,有的专门做恢复,相当于有两个内核,一个专门做事务处理处罚,一个专门做日志处理处罚。另外,另一个与Partition相关的主存数据库将数据库划分为多个分区,每个分区对应一个核心(或节点)。流程之间没有竞争。可以看出,在这一时期,数据库技术的发展一直在思考,如果所有的数据都存储在内存中,哪些技术可以被接受。但是受当时硬件条件的限制,这些技术并没有得到大规模的应用。

在基于磁盘的数据库治理系统中处理惩罚查询时,通常将整个索引加载到内存中,而B树索引中一个索引节点的大小通常是一个数据块。每个索引键值在索引叶节点都有对应的索引项,索引项包括键值对应的存储位置(页id偏移量);当一个数据块被加载到内存缓冲区时,数据库管理系统通过页表结构维护页标识偏移地址和内存缓冲区地址之间的转换。当遇到数据时,首先在页表中查找是否有对应的页标识偏移量。如果没有,说明这个记录还在磁盘上。需要先将磁盘上的数据块读入缓冲区,然后维护页表中的地址映射关系。详细的实现过程是,DBMS首先会在缓冲区中寻找一个可用的帧,如果它没有选择一个脏页来替换凭证缓冲区替换算法;如果选择一个脏页进行替换,则有必要在该位置添加一个锁存锁,以确保在替换过程中该位置不会被其他事务占用(它将在锁存之后被容纳)。脏页写回磁盘后,系统可以将目标数据块读入缓冲区中的位置,然后将其在缓冲区中的地址写入页表,以维护地址映射关系;完成这些操作后,松开框架上的闩锁。

缓冲区治理方式

如果给数据库服务器设置足够的内存,是否还能接受原有的架构,通过将所有结构化数据加载到内存缓冲区来解决数据库系统的性能问题?虽然这种方法可以在一定程度上提高数据库系统的性能,但在日志机制和数据更新方面仍然受到磁盘读写速度的限制,远远没有发挥大内存系统的优势。内存数据库治理系统与传统的基于磁盘的数据库治理系统在体系结构设计和内存使用方面存在显著差异。

综上所述,基于磁盘的DBMS和内存数据库的一个重要区别是,当遇到数据时,基于磁盘的DBMS需要通过地址映射将磁盘上数据的地址转换成内存中的地址,而内存数据库是设计成直接使用内存中数据的地址的。

对于内存数据库,CPU和磁盘I/O不再是主要瓶颈,所以优化技术主要从以下角度考虑:

基于磁盘的数据库治理系统中的数据访问示例

主存数据库的成长大致可以分为三个阶段:1984年到1994年的10年;1994-2005年十年;从05年到现在。第一阶段,出现了记忆相关的处置惩罚技术;第二阶段,出现了一些内存数据库系统;第三阶段是我们现在面对的场景。

2.由CMU(卡耐基梅隆大学)的安迪帕夫洛教授讲授的高级数据库系统课程

事务ACID属性保证

数据库治理系统中的日志记录和恢复机制是确保事务的原子性和持久性的日志记录方式。原子性意味着事务中的所有操作必须同时得到满足或被消除。当执行的一半无法完成时,可以根据日志回滚;持久性意味着如果数据丢失,可以使用日志进行恢复。

并发控制

并发控制

随着科技的增长,内存越来越自制,容量越来越大。单台电脑的内存可以设置为几百GB甚至TB。对于数据库应用程序,此内存设置足以将所有业务数据加载到内存中以供使用。虽然大数据处理受到惩罚的数据量可能是PB级的,但这些数据通常是非结构化数据。一般来说,结构化数据的规模不是特别大。比如一家银行10到20年的业务数据可能只有几十TB。这种规模的结构化数据,如果放在基于磁盘的DBMS中,在面对大规模的SQL查询和业务惩罚时,会受到磁盘I/O性能的限制。在很多情况下,数据库系统会成为整个应用系统的性能瓶颈。

因此,如果传统的DBMS对缓冲区中的一个页面进行操作,则需要添加Latch;如果是修改数据库的内容,需要添加Lock,并保存在Lock Table中进行维护和治理。下图是锁和闩锁之间的简单比较。

从1994年到2005年,出现了一些商用内存数据库系统,比如贝尔实验室开发的Dali和甲骨文Timeten的前身Smallbase。与此同时,一些面向多核的优化系统如P*-Time(现在的SAP-HANA事务处理惩罚引擎)也应运而生。当时内存数据库系统应用了一些无锁实现技术,即无锁编程技术和数据结构。

在目前的情况下,硬件条件基本上有三个特点:1。内存大,自制;2.多核CPU(从主频增加到核数增加);3.多Socket,即多核多CPU,意味着处置惩罚的并发级别可以越来越高。这些是目前数据库系统研发面临的情况。

大数据开放实验室由星环信息技术(上海)有限公司运营,致力于大数据技术的研究和传播。

基于日志记录和恢复的传统数据库管理系统内存地址映射

传统数据库管理系统的日志记录和恢复中最重要的一点是WAL(预写日志)——预写日志。WAL是指系统中的所有更新操作都有相应的日志,在日志被删除之前不允许删除数据修改。系统中的每个日志都有一个LSN数,所有的LSN数都是单调递增的。将日志放到磁盘的过程是一系列写入(顺序写入)。但是,如果严格按照一个操作日志对应一个日志的方式,在系统丢弃磁盘后,立即丢弃操作对数据的更新效果,那么系统性能会受到很大影响。因此,大多数数据库管理系统将接受Steal + No Force's缓冲区管理策略。窃取意味着DBMS可以将未提交事务的更新刷到磁盘上,而不用等待事务提交,提高了系统的灵活性和性能。如果在事务未提交时发生崩溃,它可能由于更新而被写入磁盘,因此需要通过撤消日志来回滚。无强制意味着事务提交后,数据更新仍可存储在内存缓冲区中,而无需写入磁盘,合并其他事务的更新后,可以一次性写入磁盘,为系统提供优化的空间。但是,No Force可能带来的风险是,如果事务已经成功提交,但更新没有写入磁盘,则仍然在内存中的数据更新将丢失,并且其凭据已经写入磁盘的日志将丢失(事务成功提交的前提是其所有日志必须已被删除)以进行重做操作。

通过WAL和无强制窃取机制,它可以为基于磁盘的数据库管理系统提供最大的灵活性来优化磁盘输入/输出.但是对于内存数据库,如果所有数据都存储在内存中,还需要这个机制吗?很明显,内存数据库仍然需要日志记录,但它不同于基于磁盘的数据库管理系统。日志中只记录重做操作所需的信息,不记录撤销操作所需的信息。另一方面,在大家可以想一下这是为什么?,在日志记录过程中,内存数据库不记录索引的更新,只记录基本表的更新,所以日志记录过程中写入磁盘的内容要少得多。当内存数据库出现故障,需要恢复时,首先从磁盘上现有的检查点数据和日志中恢复基本表,然后在内存中重新构建索引。

面向磁盘的DBMS性能开销

磁盘数据库系统性能开销

1.2016年VLDB现代主存数据库系统教程

那么,可以去掉费用较大的部门来增加业务逻辑中的资源比例吗?如果数据库是单用户的,并且没有并发的竞争冲突,可以节省锁定和闩锁的开销。历史上也有一些单线程的解决方案,比如把数据库分成多个分区,每个分区用一个线程来惩罚。然而,这种方案有明显的缺点:每个分区是一个串行处理惩罚。如果有一个长事务执行串行处置惩罚,所有后续事务将被阻止,直到事务完成。而且,面向磁盘系统的瓶颈是磁盘I/O,如果单线程执行,那么从磁盘读取数据时CPU就会空闲。但是对于内存数据库来说,所有的数据都存储在内存磁盘中,I/O不是系统的主要瓶颈,所以使用的技术与以前有很大的不同。虽然技术在其成长过程中经历了各种实验,但有些技术的成长并不适合现实,逐渐被遗忘。

内存数据库在遇到数据时也需要锁定,但是和基于磁盘的DBMS不同。锁和数据一起存储在内存中,锁信息通常存在于数据记录头中。为什么基于磁盘的DBMS要把锁信息单独放在锁表中,而内存数据库可以把锁信息和数据存储在一起?因为在基于磁盘的DBMS中,数据块可能会被系统从内存缓冲区替换到磁盘。如果锁信息和数据放在一起,一旦数据块被替换,锁管理器和所有事务都不能获得关于数据的锁信息。因此,对于传统的基于磁盘的DBMS,锁应该独立地维护在内存中,并且始终保留在内存中,不能被替换。但是,内存数据库没有这样的场景。

内存数据库技术历史生长

前两个阶段的技术可以大致分为以下几类:

1984年 - 1994年

1984年 - 1994年

事实上,数据库治理系统中有两种锁机制,称为锁和闩锁。目的是保护数据的一致性不被同时进行的访谈破坏。锁机制是数据库逻辑内容的幌子。一般来说,具有较长的连续时间,通常是交易执行的全过程;此外,锁定机制应该支持事务的回滚,以消除事务对数据的修改。Latch机制是为了保证内存中特定的数据结构不会因为并发访问而导致错误。比如多线程编程中插入或删除一个共享的行和列时,需要Latch来保证操作过程中的行和列不受其他线程的干扰。Latch的保持时间和操作有关,这个操作完成了就结束了。同时,不需要支持数据修改的回滚。

1994年 - 2005年

1994年 - 2005年

锁和闩锁特性的比较

前两阶段小结

前两阶段小结

可以看出,基于磁盘的数据库治理系统做了很多非同寻常的治理工作。这些东西虽然不处理和惩罚业务逻辑,但是不能保证业务逻辑的正确性。内存数据库面临的问题是应该做什么优化来获得最佳性能。与基于磁盘的系统相比,内存数据库的主要存储是内存,但对于检查点和日志记录故障,仍然需要磁盘,因此整个内存数据库应该通过磁盘上的检查点数据和日志来恢复。

1、解决Buffer Pool的In-Direction会见:用直接记忆地址会议代替了间接会议;索引的叶节点不再放页标识和偏移量,而是直接放内存地址。

一类无同时访问控制的2、Data Partition:分段数据技术。

与面向磁盘的数据库管理系统相比,3、Lock-free和Cache-Conscious:在数据块中存储一个索引节点。在内存数据库中,索引节点的长度是一个或几个缓存行。

4、粗粒度的锁:一次锁定一个表或一个分区,而不是一个记录,但是现在很少使用这种技术,因为多核场景会遇到激烈的竞争,粗粒度的锁定可能会导致并发级别的降低。(现在用的少了)

5、Functional Partition:根据功效来划分体系,每一条线索都在争取一种特定的功效。(现在用的少了)

数据库管理系统历史和技术综述

— 数据库系统的现代化生长

对于传统的基于磁盘的DBMS,即使内存缓冲区足够大,可以将所有数据加载到内存中,数据历史中的地址映射和转换仍然存在,这只是节省了将数据块从磁盘加载到内存中的开销。即使所有数据都已经加载到内存中,基于磁盘的DBMS的性能仍然远远落后于内存数据库,这是重要原因之一。

在数据库治理系统中,需要保证并发访问场景中事务的ACID属性,即事务的原子性、一致性、隔离性和持久性。事务的ACID属性主要通过数据库治理系统中的两种机制来实现,一种是并发控制,另一种是日志/恢复机制。

大多数传统的基于磁盘的数据库管理系统接受不鼓励的基于锁定的并发控制,即当遇到数据时,事务在解锁之前被锁定。如果遇到数据有冲突,其他事务需要等待有锁的事务释放锁。传统的DBMS一般在内存中维护一个单一的数据结构——Lock Table来存储所有锁,锁管理器模块持有统一的治理,这样内存中锁的缓冲区中的数据就留给存储和治理。当事务遇到数据时,它首先向锁管理器申请与数据对应的锁,然后遇到数据。锁管理器在执行后释放锁,可以保证所有事务申请和释放锁都遵循严格的两阶段锁协议。同时,并发控制机制带来的开销与用户的实际业务惩罚没有直接关系,而是为了保证事务一致性和隔离性而产生的额外开销。

去掉传统的缓冲区机制:传统的缓冲机制不适用于内存数据库中的锁和数据,但它仍然需要并发控制,这需要接受不同于传统的基于锁的受抑并发控制的并发控制策略。

只管淘汰运行时开销:磁盘输入/输出不再是瓶颈。新的瓶颈在于需要在计算性能和功耗挪用方面提高运行时性能。

接纳编译执行方式:传统的数据库多接受火山模型执行引擎,每个操作符实现为一个迭代器,提供三个接口:初始、获取下一个和关闭,从上到下被挪用。这种执行引擎的挪用开销在基于磁盘的数据库治理系统中并不占主要比例(磁盘I/O是主要瓶颈),但可能在内存数据库中构成瓶颈。想看100万条记录,需要挪用100万次,性能会变得不堪。这就是内存数据库接受大量编译执行方法的原因。编译后的机械代码的直接占用不再需要运行时解释,指针占用性能将得到有效提高。

,可扩展的高性能索引构建:,虽然内存数据库不从磁盘读取数据,但日志仍然需要写入磁盘。需要考虑日志写入速度跟不上的问题。可以消除写日志的内容,比如去掉撤销信息,只写重做信息;只写数据,不写索引更新。如果数据库系统崩溃,可以在从磁盘加载数据后以并发方式重建索引。只要对底层表进行索引,就可以重建,在内存中重建索引的速度比force还快。

去掉传统的缓冲区机制:传统的缓冲机制不适用于内存数据库中的锁和数据,但它仍然需要并发控制,这需要接受不同于传统的基于锁的受抑并发控制的并发控制策略。

只管淘汰运行时开销:磁盘输入/输出不再是瓶颈。新的瓶颈在于需要在计算性能和功耗挪用方面提高运行时性能。

接纳编译执行方式:传统的数据库多接受火山模型执行引擎,每个操作符实现为一个迭代器,提供三个接口:初始、获取下一个和关闭,从上到下被挪用。这种执行引擎的挪用开销在基于磁盘的数据库治理系统中并不占主要比例(磁盘I/O是主要瓶颈),但可能在内存数据库中构成瓶颈。想看100万条记录,需要挪用100万次,性能会变得不堪。这就是内存数据库接受大量编译执行方法的原因。编译后的机械代码的直接占用不再需要运行时解释,指针占用性能将得到有效提高。

,可扩展的高性能索引构建:,虽然内存数据库不从磁盘读取数据,但日志仍然需要写入磁盘。需要考虑日志写入速度跟不上的问题。可以消除写日志的内容,比如去掉撤销信息,只写重做信息;只写数据,不写索引更新。如果数据库系统崩溃,可以在从磁盘加载数据后以并发方式重建索引。只要对底层表进行索引,就可以重建,在内存中重建索引的速度比force还快。

— 本文小结

本文主要介绍了基于磁盘的数据库治理系统和主存数据库治理系统在几个方面的主要异同,以及从1984年至今主存数据库的技术成长。后面我们会继续分享关于内存数据库技术的成长,包括从数据组织、索引、并发控制、编译查询、持久化等角度对几种主流的内存数据库产品的实现技术进行分析和比较。

:这个部门的材料来自:

2008年,SIGMOD的一篇论文分析了面向磁盘的数据库的性能开销,划分了整个数据库系统的开销。分析表明:假设一个业务处置惩罚的总成本为100%,实际上只有不到7%的资源真正在处置惩罚业务逻辑;34%用于缓冲区管理,如缓冲区负载替换和地址转换;14%处置惩罚闭锁;16%处置罚款锁定;然后12%处置处罚日志;最后的16%用来惩罚B树指数。也就是说,满负荷运行后,只有7%的机械资源用于处理惩罚业务逻辑。

在传统的数据库治理系统中,数据的主要存储介质是磁盘。例如,逻辑表通常映射到磁盘上的一个文件,该文件以数据块(也称为页面)的形式存储在磁盘上。对于结构化数据,磁盘上的一个数据块中会存在一条记录,记录的详细位置可以用数据块ID和Offset/offset来表示。这种形式的数据块也称为槽页。顾名思义,数据块被分成许多槽,然后一个记录被放置在某个槽上。当一条记录被处罚时,可以通过表示该记录地址的Page ID Offset从磁盘中获取该记录;然后,系统将存储记录的数据块从磁盘读取到缓冲区(缓冲池分为多个帧,每个帧可以生存一个磁盘块),然后从缓冲区读取记录到线程或事务的事务区进行处置处罚;惩罚结束后

传统的数据库管理系统(DBMS)通常接受基于磁盘的设计,因为数据库管理系统的早期设计受到单个CPU、单核和可用内存小等硬件资源的限制。把整个数据库放在内存中,只放在磁盘上是不现实的。因为磁盘是一种非常慢的存储设备(相对于CPU的速度),所以学术界和工业界发展起来的数据库治理系统必须适应当时的硬件条件。像甲骨文和MySQL这样的数据库治理系统仍然接受这种架构设计。