一说到关系型数据库,我总感觉缺了点什么。如果你尝试透过“关系型数据库是如何运作的”的关键词句来进行搜索,其搜索结果是少量的而且内容是简短的。难道说是由于它已经太老旧而已经不再流行吗?
作为一名开发者,我讨厌使用我不明白的技术。此外,关系型数据库已经使用超40年,肯定有它过人的原因。因此,我花了大量时间来想真正弄懂它里面如同黑盒子那样的奥秘。关系型数据库实际上是非常有趣的,因为它是基于实用和复用的概念。但是限于篇幅,以下我将把重点放在数据库如何处理SQL查询的问题上。本文内容大致划分为以下三部分:
1.低阶数据库和高级数据库组成概述 2.查询优化流程的处理概述 3.事务和缓冲池管理概述
基本概念回顾
在编程年代早期,开发者是必须要理解清楚自己所进行操作的原理的。他们对于所使用的算法和数据结果是了然于胸的,因为他们很注重在计算机配置较低时于CPU和内存上的开销。在这一节,我首先要介绍的是数据库索引。
O(1) vs O(n2)
时间复杂度用于计算算法处理数据的用时。科学家使用大O表示法来进行时间复杂度描述,其定义是对于输入的数据算法需要进行多少步运算。这里要强调的是,它的核心是数据量增加对运算增加的影响而不是数据量的多少。时间复杂度不会直接给出精确的运算步数,而是以趋势的方式展示。
在上图中,你可以看到不同复杂度的发展趋势,我使用的方法是对数法。换言之,数据量将会从1快速地增加到10亿。我们可以得出以下结论:
举例说明
如果是处理少量数据,O(1)和O(n2)的差别是不明显的。例如是2000个运算元素:
尽管O(1) 和 O(n2)的运算量的差距是4百万,但是这仅需2ms,也就是眨眼的功夫。此外,如果使用的是多核处理器,其运算速度会更快。所以性能和优化问题在现在的重视程度无法跟以往相比。如果处理的数据量是1 000 000,其结果又会如何呢?
这样一来,你可以先喝杯咖啡休息下再回来看结果了!如果再加个0,你可以先进行午休了!
进一步说明
这里有几点提示: 具体算法和数据结果会在本文稍后列示
时间复杂度的类型有:
时间复杂度通常是最差时间场合。除了时间复杂度,复杂度还可以用来表示内存使用和磁碟I/O占用情况等。诚然,比n2更复杂的计算有n4,3n,nn 。
合并排序
如果你要对一个集合进行排序该如何做呢?什么?使用sort()?听起来是个好的答案。
但如果排序对象是一个数据库,你就务必知道sort()的工作原理。这里我介绍排序算法中最重要的一种:合并排序。对合并排序理解透彻,一方面可以掌握如何进行查询优化,二来可以更好地理解本文稍后说到的合并join运算。
合并(Merge)
合并排序的运算过程是:合并两个已排序的N/2数组到一个已排序N个元素数组,例如下图所示:
以上是本系列文的上篇,更多内容请关注后续文章,后续内容简述:全局概念,客户管理器,查询管理器,数据管理器。
本文以下内容是下篇,内容涉及数据库总体架构,客户端管理器,查询管理器,数据管理器介绍等。
总体架构
前述文章从比较细的角度来讨论了数据库,现在我们尝试从宏观角度来分析。
数据库的核心组件:
数据库的工具:
下面将详细介绍客户端管理器,查询管理器以及数据管理器。
客户端管理器
客户端管理器用于处理和管理客户端的通信。客户端可以是一台服务器或是终端应用。客户端管理器透过不同的API来提供访问权,例如:JDBC,ODBC,OLE-DB等。
当你连接到一个数据库时:
查询管理器
查询管理器是数据库的重要组成部分。其工作过程是:
查询重写器的运作
重写器的目的是:
常见的重写规则:
数据管理器
查询管理器的作用是执行查询并对资源发出请求,数据管理器会处理这些请求并返回结果。但这里有两个问题:
那么关系数据库是如何解决这两个问题的呢?
缓存管理器
如前所述,数据库的主要瓶颈是磁碟I/O。所以现代数据库使用了缓存管理器来提高效率。查询执行器的数据请求对象是缓存管理器而不是直接的文件系统。缓存管理器有一个内存里缓存叫做缓冲池。从内存获取数据会大大提高数据库速度。
缓冲–替换策略
很多主流数据库(如:SQL Server,MySQL,Oracle等)使用的是LRU算法。LRU是Least Recently Used的简写,意思最近使用。其理念是缓存最近使用的数据以便再次使用时快速读取。
虽然它有很多优点但也存在不足,比方说表/索引的大小超过了缓冲区大小。因此出现了进阶版本的LRU,这就是LRU-K,例如在SQL Server 使用的是LRU-K,K=2。在LRU-K中:
事务管理器
事务管理器是为了确保每个查询会执行自己的事务。在讲述事务管理期前,我们需要理解ACID事务的概念。ACID是一个工作单元,它的意思是:
Atomicity(原子性):事务是”全或全不”的,即使是10个小时的事务。如果事务崩溃了,会发生状态回滚。
Isolation(隔离性):如果事务A和B同时运行,那么事务A和B的结果必须是一致的,不论A对于B是完成前/完成后/过程中的状态。
Durability(耐久性):一旦事务完成,数据会存放在数据库中而不论发生什么情况(异常或错误)。
Consistency(一致性):只有有效数据被写入数据库。一致性与原子行和隔离性关联。
并发控制
确保隔离性,附着性和原子性的关键是能对同一数据进行正确写操作(添加,更新和删除)
如果仅仅是数据读取事务,那么它们可以不与其它修改事务发生冲突; 如果一个修改事务处理的数据被其它事务读取,数据库需要找到方法来隐藏这些修改操作。同时,它需要保证这些修改操作不会被清除。
以上问题就是并发控制。最简单的处理方法是逐个执行事务。但是这不利于进行规模扩张,也无法发挥服务器/CPU的多核性能。理想的处理方式是每当事务新建或取消时
监视所有事务的全部操作,检查同时读取/修改相同数据的两个(或多个)事务是否发生冲突,在发生冲突的事务中进行操作记录以减少冲突部分的大小,把冲突部分以其它次序进行处理,判别某事务是否可以取消。
更正规的做法是进行冲突日程表管理。但是在企业级数据库中,是很难为每个新事务事件分配足够多的处理时间。所以会使用其它方法来进行处理。
锁管理器
为了处理以上问题,多数数据库会采用锁或数据版本来进行处理。但这是个内容丰富的话题,以下会把讨论重点放在锁部分。
什么是锁呢?
这叫做排斥锁。但是排斥锁针对的对象相同数据的读取和等待,这是不利于资源调配的。还有一种锁,叫共享锁。
在共享锁中:
锁管理器的作用是提供和释放锁。从内部角度看,它把锁存储在一个有关联的hash数据表中。
死锁
锁的存在会导致一个问题:两个事务在无限期地等待数据。下图所展示,这就是死锁。
遇到死锁后,锁管理器会选择对哪个事务进行撤销(回滚)以消除死锁。但要进行选择,并不是件容易的事。DB2和SQL Sever使用了两段锁协议(Two-Phase Locking Protocol)来进行处理。
其核心理念是:
写在最后
我一直所坚持的习惯是:明白你所使用的技术,如果你想不断提升自己的开发水平,尝试深入掌握你所使用的工具的原理是个大有裨益的方法。虽然NoSQL在现今很流行,但是它们还是属于发展初期,一些特定的问题或重要思想还是得借助关系数据库才能彻底弄懂。文章来自极客头条,关系数据库是如何运作的(上 /下)。
本文分享自 kubernetes中文社区 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!