东南大学数据库课程04-Database Management Systems

Database Management Systems

目录

• Database Management Systems
• Contens
• 4.1 The architecture OF DBMS
  • the components of DBMS Core
  • The Process Structure of DBMS
• 4.2 DataBase Acess Management
  • Acess Types
  • File Organization
• 4.3 Query Optimization（查询优化）
  • 查询优化的含义
  • Algebra Optimization
    • easy example
    • The Equivalent Transform of a Query
• 4.4 Operation Optimization
• 4.5 Recovery
  • Introduction
  • Trasanction
  • Some Structures to Support Recovery
  • Three kind of Recovery Stragety
• 4.6 Concurrency Control
  • Introduction
  • Serialization --- the criterion for concurrency consistency
  • Locking Protocol——a way to achieve serializaton
    • X Locks
    • Two Phase Locking
    • (S,X) Locks
    • (S,U,X) Locks
  • Deadlock & Live Lock

Contens

• The Architecture of DBMS
  • The components of DBMS core
  • The process structure of DBMS
• Database Access Management
• Query Optimization
• Transaction Management

4.1 The architecture OF DBMS

the components of DBMS Core

Acess management是重中之重，各种元组，关系的物理实现都是由它完成的

The Process Structure of DBMS

• Single process structure
• Multi processes structure
• Multi threads structure
• Communication protocols between processes/ threads

数据库内核与应用代码全部打包到一个执行文件里，开箱即用，一般适用于单用户

每个Core作为一个进程和app通信，本机就用pipe，联机就用socket

DAEMON：特殊线程，监控端口的连接和用户的请求
Catalog：目录信息，关于数据的数据
lock table：锁吗，用于并发控制

Core作为线程进行交互，减缓了资源消耗

4.2 DataBase Acess Management

• The access to database is transferred to the operations on files (of OS) eventually.

• The file structure and access route offered on it will affect the speed of data access directly.

• It is impossible that one kind of file structure will be effective for all kinds of data access.

  所以，我们要根据不同的Acess Type（访问类型），来决定要采用那种File organization(文件组织）。

  同时介绍一下常用的index technique（索引技术）和Acess primitives（访问原语）

Acess Types

1. Query all or most records of a file (>15%)
2. Query some special record
3. Query some records (<15%)
4. Scope query
5. Update

💡 为什么访问的数据>15%就算是访问大部分或全部元素了？ 1. 磁盘中的数据是按块存储，所以数据库会把元组组织成一个磁盘块的大小存入磁盘中，读取时就按块来读取 2. 当访问的数据>15%时，可以认为这些数据分布在了该数据集所占的大部分磁盘块，因此要读出这15%的数据时，就要访问数据集所有磁盘块，相当于访问了全部数据

File Organization

retrieved sequentially：顺序访问

Indexed File是最常用的，index常用B+树索引【数据全部存放在叶子结点，其他节点用来导向，叶子结点间有链表用于遍历】

这种文件结构既可以顺序遍历，又可以根据索引快速查询某些元素。

但索引不是越多越好，因为有维护成本

关于Raw disk：一般来说，我们只能控制文件的逻辑结构，但是无法控制文件的物理结构，也就是无法控制文件存储在哪些盘块。而实际上，如果数据的文件能够存储在同一个盘块的同一个磁道上，就能大大减少寻道时间，从而提高查询速度。

Raw disk让操作系统给我们分配一大块存储空间，并在其上自己实现一个文件系统，从而对文件存储的物理结构也做出精确控制。现在大多数的主流数据库都会采用Raw disk，将一片数据存在一个磁道上，减少寻道时间，提高查询效率

💡

用这种方式存储的数据就叫做Cluster（簇集）

4.3 Query Optimization（查询优化）

查询优化的含义

• Algebra Optimization：代数优化【重写用户的SQL语句】
• Operation Optimization：操作优化【优化底层实现】

---

x^2+2xy+y2

代数优化 = (x+y)^2

操作优化：找到最有效的加法和乘法操作

Algebra Optimization

easy example

The Equivalent Transform of a Query

unary operation：一元操作

4.4 Operation Optimization

Join操作的优化

bR：外循环扫描次数

无论几个缓冲区，读盘时都是一块一块读

┌bR/(nB-1)┐×bS：内循环扫描次数

• Merge scan：本质是双指针
• Using index or hash to look for mapping tuples：同上，只不过内循环由于有B+index所以无需扫描，只需要查索引【但是如果索引的重复律>20%，那么相关的Relation就可能分布在该文件对应的大部分块中，此时索引逼近于顺序扫描】
• Hash Join：若两张表有公共属性，他们的Domain相同，那么可以对这两个属性运用同一个hash进行散列，置于同一个hash文件里。那么可以join的元组必然会在同一个桶里【适用于频繁链接且元组不太会变的情况下】

4.5 Recovery

Introduction

The main roles of recovery mechanism in DBMS are:

1. Reducing the likelihood of failures (prevention)
2. Recover from failures (solving)

Restore DB to a consistent state after some failures.

• Redundancy is necessary.
• Should inspect all possible failures.【解决所有问题不是必须的，但检测出来是必须的】
• General method：

1. Periodical dumping

2. Backup + Log

Trasanction

Atomic action：操作是原子的

Consistency preservation：并发保护

Isolation：类似于进程的隔离性

Durability：持久性

四个特性合起来，就叫做事务（transaction）的“ACID准则“

只是示意代码，不代表实际语法

Begin transactoin：定义一个事务

没有显式地定义事务，系统就会自动把每一条SQL当作一个事务，在此处显然就不合适

Commit：此时释放排它锁

Some Structures to Support Recovery

非挥发存储器，非易失：硬盘

Three kind of Recovery Stragety

Recovery strategies是上面两者的结合

💡 *undo和redo的幂等性：无论undo和redo做几次，和做一次的结果是一样的，这和word里的撤销操作逻辑不同*

Log Ahead Rule

先备份原数据，然后写DB。

恢复：调出log中的B.I

只差delete这一步了，所以直接删除TID即可

还有一个问题，就是有成千上万的tid，每次都要检查吗，
不，设置check point只检查check point以来运行的事务

Commit Rule

先把要修改的值写入log，然后在一次性把log里的修改值写到DB中。

恢复：重新把log中的A.I写入DB，直到成功

全部重搬运，幂等性

相比于第一中，可以延迟加排它锁的时间，并发度更高

二者结合

一二种的结合
由于修改了数据库，为了之后undo，要记录Bi到log

第一种情况：部分修改了DB，其他修改还没开始进行，最近的状态是数据库的原状态，所以undo，撤销之前的修改，恢复到原状态，这就是为什么需要B.I→Log，此时等价于Log Ahead Rule

第二种情况：部分修改了DB，其他情况已经开始进行，最近的状态是数据库的修改后状态，所以redo，让未生效的修改生效，此时等价于Commit Rule

4.6 Concurrency Control

Introduction

不同的Core Thread访问数据库的不同部分，如果不加以限制，就会产生并发问题

并发问题

写写冲突，更新丢失：x=2，那么结果无论是5还是6，都是正确的，但如果是4就是错误的，因为那说明T1对x的更新丢失了

写读冲突，访问脏数据：造成多米诺效应

Serialization --- the criterion for concurrency consistency

串行化/序列化：并发应执行的量度【能否并发很大程度上要看能否序列化】

schedule：调度； equivalent：等价的

n个事物，就会有n!中串行化的方式，如上例中x=5/6都是正确的，但是如果用户希望x=5才是正确结果，那么就不该让两个程序并行，系统不保证这一点

Locking Protocol——a way to achieve serializaton

X Locks

相容矩阵：行（已有的锁）；列（申请的锁）；NL（NONE LOCKS）

Two Phase Locking

unlock update：数据更新锁

End of Transaction

事物结束才释放锁，就不会存在其他进程提前读取数据，也就不会发生多米诺现象

(S,X) Locks

intended：可预期的。（并发读数据库是没有问题的）

(S,U,X) Locks

与After commit数据库恢复方式相配合

如果只有SX锁的话，两段红线处就要加X锁，这会导致其他进程在这段期间无法读数据库的内容。U锁的加入使锁的粒度更细了，加强了了并发性

Deadlock & Live Lock

x-lock：不断地写等待

Wait-die:我比你年老我就先等着，你好了就到我了；我比你年轻我就先挂了，一会儿再试

Wound-wait:我比年老我就为老不尊，直接把你干了，你一会儿再试；我比你年轻我就忍着，等你结束我再来

本质都是年老等年轻，按时间轴的顺序执行，单向等待，不会形成死锁