数据库核心体系

简介: 数据库核心体系

SQL引擎中的parser


所谓解析器(Parser),一般是指把某种格式的文本(字符串)转换成某种数据结构的过程。最常见的解析器(Parser),是把程序文本转换成编译器内部的一种叫做抽象语法树(AST)的数据结构,此时也叫做语法分析器(Parser)。


编译器、解释器中的解析器一般包含:

扫描器(scanner,也叫tokenizer或者lexical analyzer,词法分析器)。扫描器的输入一般是文本,经过词法分析,输出是将文本切割为单词(token)的流。

语法分析器(parser,也叫syntax analyzer)。语法分析器的输入是单词的流,经过语法分析,输出是语法树或者精简过的AST。

综合来看,解析器主要作用是进行词法分析和语法分析,提取出句子的结构。其输入一般是程序的源码,输出一般是语法树(syntax tree)或抽象语法树(abstract syntax tree,AST)。


解析器类似于解码器,只不过是把字符串解码成数据结构。

编译器/解释器中的解析器一般要完成词法分析、语法分析的功能。


5f93bab044cb4ef7b86660741448bc7b.png


内存数据库与分布式数据库


微信截图_20230519011158.png


柔性事务


刚性事务(如单数据库)完全遵循 ACID 规范,即数据库事务正确执行的四个基本要素:

原子性(Atomicity)

一致性(Consistency)

隔离性(Isolation)

持久性(Durability)

柔性事务(如分布式事务)为了满足可用性、性能与降级服务的需要,降低一致性(Consistency)与隔离性(Isolation)的要求,遵循 BASE 理论:

基本业务可用性(Basic Availability)

柔性状态(Soft state)

最终一致性(Eventual consistency)

同样的,柔性事务也部分遵循 ACID 规范:

原子性:严格遵循

一致性:事务完成后的一致性严格遵循;事务中的一致性可适当放宽

隔离性:并行事务间不可影响;事务中间结果可见性允许安全放宽

持久性:严格遵循


柔性事务的分类


柔性事务分为:两阶段型、补偿型、异步确保型、最大努力通知型。


两阶段型

分布式事务二阶段提交,对应技术上的 XA、JTA/JTS,这是分布式环境下事务处理的典型模式。

补偿型

TCC 型事务(Try-Confirm-Cancel)可以归为补偿型。在 Try 成功的情况下,如果事务要回滚,Cancel 将作为一个补偿机制,回滚 Try 操作;TCC 各操作事务本地化,且尽早提交(没有两阶段约束);当全局事务要求回滚时,通过另一个本地事务实现“补偿”行为。

TCC 是将资源层的二阶段提交协议转换到业务层,成为业务模型中的一部分。

异步确保型

将一些有同步冲突的事务操作变为异步操作,避免对数据库事务的争用,如消息事务机制。

最大努力通知型

通过通知服务器(消息通知)进行,允许失败,有补充机制。


隔离级别标准


MVCC不是单独可以使用的技术,需要配合其他并发控制技术一起来实现不同的隔离级别,如S2PL。


那我们来看看MVCC+S2PL如何实现不同的隔离级别。


事务号

数据有多个版本由不同的版本号区分,这种版本号就是一个事务号,是一个单调递增的数字。

将事务分成两种类型:只读事务和更新事务。


如果是只读事务:则在事务开始时获取一个事务号,读取数据时,就读取比这个事务号小的版本号的数据。这种读取是不用加锁的。


如果是更新事务:

读操作:获取共享锁,读取最新版本的值

写操作:获取排它锁,为写的数据创建一个新版本,版本号为无穷大(版本号类型的最大值,当然实际数据库很少这样实现的,考虑到崩溃恢复和持久化,实际数据库实现的版本控制和可见性判断远比这复杂,属于工程上的优化,目的是一样的),这样其他事务根据其版本号就无法读取到这条记录,提交时,重新获取事务号,将此写入的数据的版本号改为此事务的事务号+1。


所以MVCC天然就不会读取到未提交数据。


读已提交

每次读都重新获取一次快照,读取最新已提交数据。

可重复读

第一次执行读操作时生成快照,后面的读都以此快照进行读取,这样每次读取的版本都是一样的。

如果是SELECT … FOR UPDATE或DML语句,需要用排它锁锁住需要读写操作的数据直到数据结束。

可串行化

可串行化用SS2PL来实现。

这样,通过MVCC+S2PL实现了数据库的不同隔离级别。


可串行化


与串行化相比 是允许并发的实现

在保证一致性情况下,允许并发操作执行。


冲突可串行化(conflict serializability)


一个调度,如果通过交换相邻两个无冲突的操作能够转换到某一个串行的调度,称为冲突可串行化的调度。

当下面三种条件都满足时,我们将两个操作视为冲突


两个操作属于不同的事务

两个操作访问和处理的数据集有重叠

至少有一个操作的是写操作


对于S1是conflict serializability,可以交换非冲突操作,但S2都不可交换,不是conflict serializability。

// S1 
T1        T2
R(A)
W(A)
          R(A)      <---
          W(A)
R(B)
W(B)                <------
          R(B)
          W(B)

d8a499141c344652aafe7c0b180efbb6.png

// S2 
T1         T2
           R(A)
           W(A)
R(A)
W(A)
R(B)
W(B)
           R(B)
           W(B)

同一个事务操作不可改顺序,同时t1的操作与相邻的t2操作不可交换。

关系

冲突可串行性 比 可串行性 要严格;

满足冲突可串行性 必 满足 可串行性,反之不然。

可串行化一定是正确的并发调度,反正不一定。

所以引出了优先图检测冲突可串行化。


优先图检测冲突可串行化


04d9bfa7f76b49b3abc1ad3044453412.png

如Ti的Ri(A)与Tj的Wj(A)冲突,而Ri(A)<Wj(A),所以Ti就要先于Tj执行,所以就可以使用优先图来检测冲突可串行化。而如果优先图(precedence graph)没有环,则说明调度是冲突可串行化的。因为如果Ti需要在Tj前执行,又有Tj需要在Ti前执行,显然这是矛盾的,所以存在环则不是冲突可串行化的。


相关文章
|
23天前
|
存储 NoSQL 关系型数据库
一文探索应运而生的数据库们
本文系统性回顾了数据库技术的发展历程与现状,从层次数据库 IMS 到新兴的向量数据库 Milvus,每一类数据库的诞生都映射了特定时代的技术挑战与应用需求。
|
3月前
|
存储 NoSQL 关系型数据库
现代数据库技术的演进与应用
本文探讨了现代数据库技术在面对日益复杂和庞大的数据需求时的演进路径及其应用实例。从传统关系型数据库到NoSQL和NewSQL,再到分布式数据库系统,我们分析了每种技术的特点、优势和适用场景,并讨论了它们在大数据处理、实时分析和云计算环境中的应用案例。通过本文的阐述,读者将能够深入理解不同数据库技术的选择依据及其在现代技术架构中的关键作用。
|
6月前
|
分布式数据库 数据库 数据安全/隐私保护
开发者关注的数据库技术与创新,未来数据库的演进及理想数据库的构想
作为开发者,想必大家都知道在技术圈中数据库相关领域是技术开发中的重中之重,数据库技术与创新不断推动着数字化时代的发展,数据库技术正在经历着一次创新的浪潮,还有就是数据库技术的不断创新为开发者们在日常实际开发中提供了更多的可能性和好的机遇。那么本文就来简单聊聊最值得开发者关注的数据库技术与创新,包括分布式数据库、图数据库、时序数据库、区块链数据库以及AI与数据库的结合等方面,以及探讨未来数据库的演进趋势,并讨论一下在开发者心目中最理想的数据库的特征与构想。
101 3
|
5月前
|
存储 SQL 多模数据库
深入剖析数据库技术:从核心原理到未来趋势
一、引言 在当今信息化社会中,数据库技术作为数据存储、管理和分析的关键技术,已经成为各行各业不可或缺的一部分
|
5月前
|
存储 SQL NoSQL
深入了解数据库技术:核心原理、类型及行业应用
一、引言 数据库技术是信息技术领域的重要组成部分,它负责数据的存储、检索、管理和保护
|
5月前
|
存储 SQL Cloud Native
揭秘数据库技术的核心与未来:从架构到应用
一、引言 数据库技术是当代信息系统中不可或缺的一部分,它为企业和个人提供了可靠、高效的数据管理解决方案
|
5月前
|
存储 Cloud Native 数据处理
探索数据库技术的核心与发展趋势
一、引言 数据库技术作为现代信息技术的基石,为各行各业提供了数据存储、检索、管理和分析的关键支持
|
5月前
|
存储 SQL 人工智能
数据库技术:从核心原理到行业应用
一、引言 数据库技术作为现代信息技术的基石,在各行各业中发挥着至关重要的作用
|
5月前
|
存储 SQL 安全
数据库技术:核心原理、现代应用与未来趋势
一、引言 数据库技术是现代信息系统不可或缺的组成部分,它为企业和个人提供了可靠、高效的数据存储、查询和管理手段
|
SQL 存储 运维
数据库生态工具&架构方案| 学习笔记(一)
快速学习数据库生态工具&架构方案
423 0
数据库生态工具&架构方案| 学习笔记(一)