我正在参加「启航计划」

原文: dsf.berkeley.edu/papers/fntd…

本文首要评论DBMS的体系结构，包含进程模型、并行架构、存储体系规划、事物体系完结、查询处理器和优化器架构，以及常见的同享组件和东西。

1 介绍

数据库体系是最早广泛布置的在线服务器体系之一，因而，它创始了不仅跨过数据办理，并且跨过运用程序、操作体系和网络服务的规划处理计划。前期的dbms是核算机科学中最具影响力的软件体系之一，为dbms创始的思维和完结问题被广泛仿制和从头创造。

1.0 DBMS的架构——DBMS的首要组件

DBMS的首要组件

DBMS的5大组件:

客户端通讯办理器（Client Communication Manager）
进程办理器（Process Manger）
查询处理器（Relation Query Processor）
事物性存储办理器（Transanctional Stroage Manager）
同享组件和东西（Shared Components and Utilities）

1.1 联系型体系：一条查询的履行进程

树立衔接。调用者调用客户端API，客户端经过网络与服务端（的Client Communications Manager）通讯.
- Client Communication Manager的首要功用:
  - 为调用者树立衔接并保护调用者的状况；
  - 呼应调用者的SQL指令，然后回来正确的数据和操控信息；
分配核算线程。在接纳到客户端的第一个SQL指令之后，DBMS有必要分配一个“核算线程”来履行SQL指令。还需求保证线程的数据和操控输出能够经过 Communication Manger 发送给客户端。
- Process Manager的首要功用：
  - 为收到的SQL指令分配核算线程。DBMS在此阶段要做的最重要的决议是关于准入操控（admission control）的——即体系是否应该当即处理查询，或推延履行直到有满意的体系资源能够用于此查询。
履行查询。一旦确认并分配了一个核算线程，就能够履行查询了。
- Relation Query Processor：
  1. 查看用户是否有权限履行查询，
  2. 然后将用户的SQL编译为内部的查询计划（internal query plan） 。
  3. 一旦编译完结，**计划履行器（plan executor）**会履行该计划。
    
    计划履行器由一组operators组成，它能够履行任何查询。一般operators完结的联系型查询处理使命包含joins,selection,projection,aggregation,sorting等，以及从体系的较低层恳求数据记载的调用。
从数据库中获取数据。需求经过 Transaction Storage Manager 才干获取数据
- Transanctional Storage Manager：
  - 它办理一切的**数据拜访（read）和操控（create,update,delete）**调用。operators从Transactional Storage Manager获取数据。
    
    存储体系包含安排和拜访磁盘上数据（access methods）的算法和数据结构，
    - 包含像表和索引这样的根底数据结构
    - 它还包含缓存办理模块（buffer manager）。
    在拜访数据之前，需求先从 lock manager 获取锁，以保证并发查询时的正确履行。
    
    假如查询需求更新数据库，还需求 log manger 交互，以保证事物在提交后是耐久的，在吊销后是可吊销的。
回来数据，业务完毕，封闭衔接。拜访数据记载，核算终究成果并回来给客户端。
- access methods 将操控回来给查询履行器的 operators，它编列数据库数据的核算；当成果生成后，会被放到 client communications manager 缓存中，它会将成果回来给调用者。

上面的比如涉及了RDBMS的多个核心组件，但不是一切。catalog 和 memory managers 会在事物中被调用。catalog在认证、解析和查询优化时会被查询处理器运用。memory manager 只需在DBMS需求动态分配或吊销分配内存时就会运用。

1.2 评论规模和概览

本文首要重视的是支撑数据库核心功用的根底架构：

进程架构
DBMS特定范畴的组件
存储架构和事物存储架构规划
常见DBMS中的同享组件和东西

2 进程模型

当规划任何一个多用户服务时，前期要决议怎么履行并发用户恳求以及怎么将这些恳求映射到操作体系进程或线程。

咱们先从一个简略的结构开端，假定操作体系关于线程的支撑很好，且只重视单处理器体系。接下来的评论根据下面的界说：

一个操作体系进程由多个操作体系线程和进程私有地址空间组成。为进程保护的状况包含操作体系资源和安全的上下文。线程由操作体系内核调度，每个进程有其仅有的地址空间。
操作体系线程是操作体系程序的履行单元，没有私有操作体系上下文和私有地址空间。操作体系线程由内核调度。
Lightweight Thread （轻量级线程，LWT）支撑在单个进程中存在多个线程。不像操作体系线程由内核调度，这些线程由运用程序调度。LWT在用户空间中调用，操作体系线程在内核空间中调度。
DBMS Client是一个软件，完结了用于运用程序与DBMS通讯的API。
DBMS worker 是DBMS中履行的线程，它代表DBMS客户端作业。DBMS worker和DBMS 客户端之间是一一对应的：DBMS worker处理一切来自单个DBMS 客户端的SQL恳求。

2.1 单处理器(Uniprocessors)和轻量级线程（LWT）

咱们以两个简略的假定开端（后面会放宽假定）:

操作体系线程支撑：假定操作体系对内核线程供给了高效的支撑，且一个进程能够有很多线程。咱们还假定每个线程的内存开支很小，且上下文切换和便宜。
单处理器硬件：假定咱们是为只需单CPU的单个机器规划的。

在此简化的环境下，DBMS有三个自可是然的进程模型可选。总最简略到最杂乱，依次是：

每个（DBMS）worker一个进程
每个（DBMS） worker一个线程
进程池

虽然这些模型都被简化了，它们三个都在商业DBMS中有运用。

2.1.1 每个worker一个进程（Process per DBMS Worker）

Fig. 2.1 Process per DBMS worker model: each DBMS worker is implemented as an OS process.

由操作体系对DBMS workers进行办理，DBMS程序员能够依托操作体系的保护设备来阻隔规范过错，如内存超限。

长处：

易于完结。workers 直接映射到操作体系进程。
各种编程东西能够运用。如调试器、内存查看器。

缺陷：

多个DBMS衔接之间需求同享内存数据结构。包含lock table 和 buffer pool。同享的数据结构有必要由操作体系显现的分配，需求操作体系支撑和一些特别DBMS编码。在实践中，同享内存降低了地址空间别离的优势。
关于很多并发衔接的扩展性欠好。进程需求保护的信息很多，因而很多进程需求耗费更多的内存。

2.1.2 每个worker一个线程

Fig. 2.2 Thread per DBMS worker model: each DBMS worker is implemented as an OS thread

单个多线程进程办理一切的DBMS worker 活动。调度器线程监听新的DBMS client衔接。每个衔接分配一个新的线程。

长处：

关于并发的扩展性好。

缺陷：

多线程编程的缺陷它都有。难于调试，竞争条件；各个操作体系的线程接口不同，跨渠道有问题。

2.1.3 进程池

此模型是“每个worke一个进程”的一个变体。有了进程池，不是每个worker分配一个进程，进程由进程池办理。每个client分配一个进程。当SQL履行完结后，客户端收到成果，进程会回收到进程池，等候分配给下一次恳求。假如一个恳求来了，可是进程池空了，那么该恳求需求等候有进程可用。

进程池的巨细一般是动态的，一般其巨细与并发恳求数有关。

长处：

“每个worker一个进程” 有的它都有
需求的内存更小，更高效

2.1.4 同享数据和进程鸿沟

以上介绍的模型的意图都是尽或许独立地履行并发恳求。可是，DBMS worker彻底的独立和阻隔是不或许的，因为它们需求操作同一个数据库。在这三个模型中，数据需求从DBMS移动到客户端。这暗指，一切的SQL恳求需求移动到服务端进行，且一切的回来的成果需求从服务端移回客户端。怎么移动？简略来说便是运用各种缓冲。两种重要的缓冲类型是：

*磁盘I/O缓冲(disk I/O buffers) ：*最常见的跨worker数据依靠是对同享数据存储的读取和写入。所以，worker之间的I/O交互很常见。有两种独立的磁盘I/O场景需求考虑:
1. 数据库I/O恳求（Database I/O Requests）: 缓冲池（The Buffer Pool）。一切耐久化的数据库数据都需求经过DBMS buffer pool暂存。
  - 在 “每个worker一个线程 ” 模型中，缓冲池分配在堆上，DBMS地址空间中的一切的线程都能够拜访
  - 在其他两种模型中，缓冲池分配在一切进程能够拜访的同享内存中。
  一切模型中的终究成果是，缓冲池是一个大的同享数据结构，一切数据库线程或进程都能够拜访。
  
  缓冲“读”
2. 日志恳求（Log I/O Requests）：The Log Tail。数据库日志是存在一个或多个磁盘上的一组条目。一切日志条目都是在事物处理进程中生成的，它们暂存在内存行列中，被周期性的按FIFO次序写入到日志磁盘中。这个行列一般叫做log tail。在很多体系中，有一个别离的进程或线程担任周期性地将 log tail 写入到磁盘中。
  - 在 “每个worker一个线程” 模型中，log tail 分配在堆上
  - 在其他两个模型中，有两种常见的规划办法：
    1. 运用一个独立的进程办理日志。日志记载经过同享内存或其他高效的进程间通讯协议与日志办理器通讯。
    2. 与上面处理缓冲池的办法相似，log tail 在同享内存中分配。要害的一点是，一切履行数据库客户端恳求的线程和/或进程都需求能够恳求写入日志记载并改写log tail。
      
      一种重要的 log flush 类型是commnit transaction flush。业务只需在提交日志记载被写入到日志设备之后才干被报告为成功提交。
  缓冲“写”
*客户端通讯缓冲(client communication buffers) *：SQL一般以“pull”形式运用：客户经过反复宣布SQL FETCH恳求，从查询游标中消费成果记载，每次恳求检索一个或多个记载。大大都DBMS试图在FETCH恳求流之前作业，以便在客户端恳求之前排定成果。

为了支撑这种预取行为，DBMS worker能够运用客户端通讯socket作为成果集行列。更杂乱的办法是完结客户端游标缓存，并运用DBMS客户端来存储或许在不久的将来被获取的成果，而不是依靠操作体系的通讯缓冲区。

其他同享的数据:

确认表(Lock table) 。确认表由一切DBMS worker 同享，并由**确认办理器（Lock Manager）**用来完结数据库的确认语义。同享锁表的技术与缓冲池的技术相同，这些技术也能够用来支撑DBMS完结所需的任何其他同享数据结构。

2.2 DBMS 线程

因为留传、可移植性和可扩展性的原因，大大都DBMS并不根据操作体系线程完结。那些运用“thread per DBMS worker” 模型的，需求一个不运用操作体系线程的处理计划。其间一个计划是：自己完结轻量级的线程。

2.3 规范实践

以上介绍的三种架构（及变体）在现实的DBMS中都有运用。如 IBM DB2支撑4种进程模型：

假如OS对线程的可扩展性支撑的很好，DB2默许运用 thread per DBMS worker 模型，也能够挑选 thread pool 模型
假如OS对线程的可扩展性支撑的欠好，DB2默许运用 process per DBMS worker 模型，也能够挑选 process pool 模型。

现在来总结一下IBM DB2,MySQL，Oracle , PostgreSQL 和 Microsoft SQL Server 支撑的进模型：

Process per DBMS worker:

这是最直接的模型，依然被很大都据库运用。
- DB2在对线程扩展性支撑欠好的OS上的默许模型
- Oracle的默许模型
- PostgreSQL支撑此模型
Thread per DBMS worker:

此模型的两个首要变体是：
1. OS thread per DBMS worker:
  - DB2在对线程扩展性支撑很好的OS上的默许模型
  - MySQL运用的模型
2. DBMS thread per DBMS worker:
  
  在此模型中，DBMS worker 由调度器调度，要么调度到OS processes上，要么调度到OS threads上。
  
  此模型有两个首要的子类：
  - DBMS threads 被调度到 OS process 上：
    - Syhbase 支撑此模型
  - DBMS threads 被调度到 OS threads 上：
    - Microsoft SQL Server支撑此模型
Process/thread pool
- process pool
  - Oracle 支撑此模型
- thread pool
  - Microsoft SQL Server在大大都机器上的默许模型

大大都现代商用DBMS都支撑内部查询并行（intra-query parallelism）：将单个查询分红多个部分，在多个处理器上并行履行。内部查询并行便是将单个SQL查询分配给多个DBMS worker去履行。底层的进程模型不会因而受到影响。

2.4 准入操控（Admission Control）

跟着吞吐量的增加，DBMS因为内存压力会呈现颤动：无法将数据库页的“作业集”保存在缓冲池中，并且一切时刻都花在了页替换上。

什么状况下会形成颤动？

sorting 和 hash joins 耗费很多内存
锁争用: 事物之间相互死锁，需求回滚和从头启动

怎么避免颤动？

准入操控机制——只需在DBMS资源满意时才接纳新的作业。有了一个好的准入操控器，体系在过载的状况下会高雅的退化：事物推延将与到达率（arrival rate）成比例地增加，但吞吐量将坚持在峰值。

DBMS 中的准入操控能够在两层中进行：

第一层：dispathcer process 保证客户端衔接数在阈值之下。这样能够避免过度耗费网络衔接资源。
第二层：在DBMS relational query procecssor中完结。准入操控在查询被解析和优化后履行，并决议查询是被推延，或以少数资源履行，仍是无束缚地履行。

优化器会估量查询需求的资源和当时体系中的可用资源，这些信息为供给给准入操控器。

3. 并行架构: 进程和内存和谐（Memory Coordination）

本章评论每个并行架构的中进程模型和内存和谐问题

3.1 同享内存（Shared Memory）

同享内存架构：一切处理器能够以大致相同的功用拜访同一个RAM和磁盘。

第2章中的3中模型都能够在同享内存架构上很好地运转。在同享内存机器上，OS关于跨处理器分配worker（processes 或 thread）是通明的。

此架构的首要的应战是修正查询层，使其能够运用多个CPU对单个查询并行履行。

3.2 无同享（Shared-Nothing）

无同享并行体系由一组独立的机器组成，它们之间经过网络进行通讯。各个机器之间无法直接拜访内存或磁盘。

无同享体系没有供给硬件同享笼统，需求DBMS来调度各个机器。DBMS选用的最常见的技术是在每个机器或节点上运转各自的规范进程模型。每个节点都能够接纳客户端的SQL恳求，拜访必要的元数据，编译SQL恳求，并进行数据拜访，就像在单个机器上相同。首要的不同的是：集群中的每个体系只存储部分数据。查询恳求不只查询本地数据，还会被发送到集群中的其他相关节点上，一切相关节点都需求履行查询。这些表运用水平数据分区分布在集群中的多个体系上，每个处理器能够独立于其他处理器履行。

有哪些数据分区计划？

hash-based
range-based
round-robin
range-based + hash-based

无同享架构的问题:

部分失效：一个处理器失效会导致整个机器失效，因而DBMS也会失效。虽然单个节点失效不会影响其他节点，但会对整体DBMS的行为产生影响。

3种处理办法：
- 一个节点失效，就封闭一切节点。（本质上仿照的是同享内存架构）
- “Data skip” ——越过毛病节点上的数据
  - 适用于: 数据的可用性 > 成果的完整性
- 冗余

无同享架构的长处：

扩展性好
便宜

运用场景：

决策支撑体系
数据库房

3.3 同享磁盘（Shared Disk）

同享磁盘架构：一切的处理器能够以大致相同的功用拜访同一个磁盘，但不能拜访各自的RAM。

长处：

办理本钱低。不必考虑对数据进行分区
单个节点失效不会影响其他节点拜访数据库

缺陷：

单点毛病。
跨机器的数据同享需求显现调度
- 根据分布式锁办理器
- 需求缓存共同性协议来办理分布式缓冲池
这些都是很杂乱的组件，易产生竞争，成为体系的瓶颈。

3.4 NUMA

NUMA（*Non-Uniform Memory Access (NUMA,非共同内存拜访)* ）在内存独立的集群上供给了一个同享的内存编程模型（把多个独立的机器上的内存看成一个内存）。集群中每个节点能够快速拜访本地内存，而长途内存拜访需求经过集群中的高速互联通道（存在一些推延）。此架构称号的来源便是内存拜访时刻不共同。

NUMA架构介于无同享和同享内存之间。

NUAM集群现已消失了。

3.5 DBMS线程和多处理器

在“thread per DBMS worker”模型中，一切线程在单个进中运转，单个进程一次只能在单个处理器上履行。因而，在多处理器体系中，DBMS只会运用单个处理器，其他处理器会闲置。

当在多个进程中运转DBMS线程时，有时会呈现一个进程承当了大部分作业，而其他进程（也便是处理器）处于空闲状况。为了使这种形式在这些状况下能很好地作业，DBMS有必要在进程之间完结线程迁移（migration） 。从6.0版别开端，Informix在这方面做得很好。

当把DBMS线程映射到多个操作体系进程时，需求决议选用多少个操作体系进程，怎么把DBMS线程分配给操作体系线程，以及怎么在多个操作体系进程中分配。一个好的经历法则是每个物理处理器分配一个进程。这能够最大限度地进步硬件中固有的物理并行性，一起最大限度地削减每个进程的内存开支。

3.6 规范实践

关于对并行的支撑，盛行的办法与上一张相似：大大都首要的DBMS支撑多种并行模型。因为同享内存体系（SMP、多核体系和两者的组合）在商业上的盛行，一切首要的DBMS供货商都对同享内存的并行性供给了良好的支撑。咱们看到支撑的不合是在多节点集群并行中，广泛的规划挑选是同享磁盘和无同享。

同享内存：大大都首要的DBMS都支撑，包含：IBM DB2，Oracle 和 Microsoft SQL Server
无同享：IBM DB2, Informix, Tandem, 和 NCR Teradata
同享磁盘：Oracle RAC, RDB , 和 IBM DB2

4. 联系型查询处理器

查询处理器（query processor）的作用：接纳一个SQL句子，验证SQL，将SQL优化为查询计划，然后履行该查询计划。客户端获取（pull/fetch）查询的成果，一般是一次获取或一批一批地获取。

以下评论的是常见的SQL：DML句子（增修正查）。而不是DDL句子。查询优化器不处理DDL； DDL一般是静态的DBMS逻辑，经过显现调用存储引擎和catalog manager。

查询处理器的首要组件:

解析器：解析查询句子、验证履行权限
重写器：简化和规范化查询
优化器：生成查询计划
履行器：履行查询计划

4.1 查询解析和授权

关于一个SQL句子，SQL**解析器（parser）**一般需求履行以下处理:

查看表名是否正确
解析称号和引证
将查询转化为优化器运用的内部格局
验证用户是否有权限履行查询
- 验证用户是否对表、用户自界说函数、或查询中引证的其他方针有权限。
- 有些体系会将权限查看放到查询计划履行的时分做。如支撑行级安全的体系，因为只需在履行时才干根据值做安全查看。

在解析和验证经过之后，生成查询的内部格局。

4.2 查询重写

查询重写模块（重写器，rewriter）担任简化和规范化查询，而不改动其语义。大大都重写实践上是对查询的内部标明的操作，而不是对原始SQL句子的。查询重写模块的输出一般是查询的内部标明。

在大多商用数据库中，查询重写是一个逻辑组件，一般在查询解析后，或查询优化前履行。不论怎么，将查询重写与其他模块别离是很有用的。

重写器的首要职责有：

扩展视图(View expansion): 将视图替换为视图引证的表、谓词或列。
简化常量数学表达式。如，将 R.x < 10+2+R.y 重写为 R.x < 12+R.y
逻辑重写谓词(predicates): 根据WHERE句子中的谓词和常量进行逻辑重写。

如，将 NOT Emp.Salary > 1000000 重写为 Emp.Salary <= 1000000 。

将 Emp.salary < 75000 AND Emp.salary > 1000000 重写为 FALSE；

乃至还能够从一个谓词转化为另一个谓词，R.x < 10 AND R.x = S.y 转化为 AND S.y < 10。

意图：
- 进步优化器的功用，使其挑选更好的查询计划
语义优化: 当表上的约束与查询谓词不兼容时，语义优化能够避免履行查询。

比如，消除冗余的join。
```
SELECT Emp.name, Emp.salary
FROM Emp, Dept
WHERE Emp.deptno = Dept.dno
```
重写为：
```
SELECT Emp.name, Emp.salary
FROM Emp
```
子查询翻开和其他启发式重写：

优化器是DBMS中最杂乱的组件。为了坚持这种杂乱性的有限，大大都优化器只在单个SELECT-FROM-WHERE 查询块上运转，而不是跨块进行优化。因而，许多体系不会使优化器杂乱化，而不是重写查询，使其更符合优化器。这种办法转化有时叫做查询规范化（query normalization） 。
- 一类比如便是将查询重写为语义上持平的规范办法，语义持平的查询会被优化生成相同的查询计划
- 另一个重要的启发式办法是尽或许地翻开嵌套查询，以最大限度地为查询优化器的单块优化供给计划。

4.3 查询优化器

**查询优化器（query optimizer）的首要使命是将内部的查询标明转化为一个高效的查询计划（query plan）。**一个查询计划能够被认为是一个查询运算符（query operator）组成的图，表数据会流过该图。

查询计划有多种标明办法:

机器码
可解说（interpretable）的数据结构 (为了跨渠道)
- 轻量的方针
- 初级的“操作码”言语。与Java的字节码的思维相似
- 类代数（algebra-like）

一切的DBMS都为Selinger的论文中说到的查询计划做了扩展，首要的扩展有:

计划空间（Plan space）
挑选性估量（Selectivity estimation）
查找算法（Search Algorithms）
并行（Parallelism）
主动调优（Auto-Tuning）

4.4 查询履行器

**查询履行器（query executor）**用于履行查询计划。查询计划一般是一个数据流的有向图，其间节点是operators（包含要拜访的表和各种查询算法）。

在某些体系中，这个图被优化器编译为操作码，这时履行器的作用便是一个运转时解说器。

在其他体系中，履行器的输入是一个图，它会递归的调用程序来履行operators。

大大都现代查询履行器选用的是迭代器模型。

履行器的运转模型：

迭代器模型（iterator model）：迭代器的输入便是数据流图中的边。查询计划中的每个operators都是迭代器的子类。
- 特色
  - 面向方针形式
  - 迭代器的逻辑与其父亲和孩子相互独立
  - 数据流和操控流耦合在一起
  - 单线程架构。只需求运用单个线程来履行这个查询图。
    - 完结简练、易于调试
    - 在单体系（非集群）中查询功率高

4.5 拜访办法

拜访办法（Access Methods）是一个办理程序，办理各种根据磁盘的数据结构的拜访。这些一般包含无序的文件（”堆”），以及各种索引。一切首要的商业体系都完结了堆和B+树索引。

Access Methods供给的根底API:

init()：接纳一个“查找参数”——SARG，SARG为空标明全表扫描，SARG为列或许会运用索引。
next()：用于获取数据，假如next() 回来NULL，则阐明没有满意条件的数据了。

Q: 为什么要向 access method 层传递SARGs？

像B+树这样的index access methods需求SARGs来高效履行
功用问题：它更合适堆扫描和索引扫描
一切查询逻辑都在access methods 层中完结，使存储引擎与联系引擎之间的鸿沟明晰，功用更好

Q: 索引怎么与数据表（base 表）中的行相关?

RID(row ID)：直接指向base表中数据的物理磁盘地址。
- 长处
  - 块
- 缺陷
  - base表的行移动很费事，因为需求更新一切的二级索引。查询和更新的本钱都很高

Q: 怎么处理行移动的问题？

DB2: forwarding pointer：需求多一次IO找到移动后的page，但不必更新二级索引。
运用B+树作为主存储：运用主键代替物理地址。丢失了二级索引拜访base表的功用，但避免了行移动导致的问题。

4.6 数据库房

数据库房——用于决策支撑的大型前史数据库，定时加载新的数据——需求专门的查询处理支撑。

此主题之所以重要的两个原因:

数据库房是DBMS技术的一个重要运用。
传统查询优化和履行引擎在数据库房上作用不佳。因而，需求扩展或修正以进步功用。

Q: 为什么需求数据库房？

“商业剖析”的需求呈现。系型数据库首要是用于处理商业数据处理的需求，而数据库房首要用于处理“商业剖析”需求

Q: 数据库房与OLTP的差异？

数据的本质不同。数据库房处理的是的前史数据，而OLTP处理的是“现在”的数据
数据的schema不同。需求进行数据转化

Q: 数据库房中的数据从哪里来？

从OLTP体系中获取数据，并将这些数据放到数据库房中。能够运用ELT（extract,transform and load）体系。盛行的ELT产品有：Data Stage 和 PowerCenter。

4.6.1 Bitmap Indexes

B+tree对快速刺进、删去和更新记载做了优化。相反，数据库房中存储的都是静态数据，只用加载一次数据即可。此外，数据库房一般具有包含少数值的列。

Bitmap相对B+树的长处：

节约空间。方便存储列值数量较少的数据，如用户的性别，只需两个值。
数据过滤。多个bitmap取交集，能够很快地对数据进行过滤

缺陷:

更新本钱高。因而只在数据库房中运用

在现在的产品中，bitmap一般作为B+树的一个补充存在。

4.6.2 Fast Load

一般数据库房会在夜里加载白日的买卖数据，原因有:

白日买卖数据，晚上加载是一个很天然的战略
避免在用户交互的时分更新数据

Q: 为什么数据库房的数据不能被并发加载（查询和加载一起存在）?

因为数据剖析师剖析数据时，一般要运用很多查询，这些查询应该根据同一个数据集，假如答应查询的一起加载最近新生成的数据，那么或许会产生问题。

Q: 怎么快速地批量加载数据？

批量加载器（bulk loader）。将很大都据以流的办法传到存储中，不会对SQL层形成压力，并且运用像B+中的那样的特其他批量加载办法来获取数据。

这种办法比SQL刺进快一个数量级，一切首要的厂商都供给了高功用的批量加载器。

Q: “实时的”数据库房（运用: 电商和24小时零售）有哪些问题？

刺进（来自批量加载器或事物）有必要要设置写锁，这些锁会与读锁抵触，并且或许导致数据参库房“冻结”。
跨查询集的兼容性问题。处理办法有:
- 避免就地更新并供给前史查询
- 供给快照阻隔这样的MVCC阻隔等级

4.6.3 物化视图（Materialized Views）

数据库房一般十分大，多个大表的join查询很耗时。为了加速常用的查询，大大都厂商供给了物化视图。

与逻辑视图不同，物化视图采纳的是能够查询的实践表，但它对应于真实的 “根底 “数据表上的逻辑视图表达。对物化视图的查询能够避免在运转时履行视图表达式中的join。而在数据更新时，物化视图有必要坚持最新状况。

物化视图运用的三个方面：

挑选要物化的视图
保护视图的“新鲜”。两种办法:
- 更新表的时分更新物化视图
- 周期性地删去偏重建物化视图
考虑在特其他查询中运用物化视图

需求在运转时开支和物化视图的数据共同性之间进行权衡

4.6.4 OLAP和特别查询的支撑

一些数据库房有一些可猜测的查询。例如，每个月底汇总一下各个部分的销售额。除了这些惯例查询外，便是一些特其他查询了，由业务剖析师临时制定。

关于可猜测的查询，能够构建物化视图来加速。更一般地说，因为大大都商业剖析查询都要求汇总，咱们能够核算出一个物化视图，它是每个商铺的部分的总销售额。然后，假如指定了上述的区域查询，它能够经过 “滚动 “每个区域的各个商铺来满意。

这种聚合一般被称为数据立方（data cubes），是一类有趣的物化视图。在20世纪90年代初，Essbase等产品供给了定制的东西，用于以优先立方体格局存储数据，一起供给根据立方体的用户界面来阅读数据，这种才干被称为在线剖析处理（OLAP，联机剖析处理）。跟着时刻的推移，数据立方体的支撑现已被增加到全功用的联系型数据库体系中，并且一般被称为联系型OLAP（ROLAP）。许多供给ROLAP的DBMS现已开展到在内部完结一些特别状况下的前期OLAP式存储计划，因而有时被称为HOLAP（混合OLAP）计划。

4.6.5 雪花（Snowflake）形式查询的优化

fact表中存储的数据一般是: “customer X bought product Y from store Z at time T.”。dimensions一般包含 customer, product, store , time 等。

Star形式: fact表中的一条记载，包含N个dimension表中的外键。
Snowflake形式(多层Star形式): 与Star形式相似，不过这儿的dimension是分层的，如时刻(日/月/年)，办理层级等。

根本上一切的数据库房查询都需求在雪花形式中对这些表中的一些特色进行过滤，然后将成果衔接到中心facts表，经过facts表或dimensions表中的一些特色进行分组，然后核算SQL聚合。跟着时刻的推移，供货商在他们的优化器中对这一类查询进行了特别处理，因为它十分盛行，并且为这种长时刻运转的指令挑选一个好的计划是十分要害的。

4.6.6. 数据库房总结

数据库房需求的才干与OLTP有很大不同。除了B+树，数据库房还需求bitmap索引。数据库房需求特别重视雪花形式上的聚合查询，而不是通用的优化器。数据库房需求物化视图，而不是惯例视图。数据库房需求快速批量加载，而不是快速事物更新；等等。

首要的联系型厂商都是从根据OLTP的架构开端的，然后增加了根据数据库房的架构。此外，有很多的小厂商也供给DBMS的处理计划。包含Teradata 和 Netezza，它们无同享的专有硬件，能够运转在它们的DBMS上。

终究，列存储在数据库房范畴与传统的存储引擎比较有巨大的优势，因为传统的存储单位是表行。当表很”宽”的时分，独自存储每一列是特别有用的，并且拜访往往只在几列上。列存储还能完结简略有用的磁盘紧缩，因为列中的一切数据都来自同一类型。**列式存储的应战在于，表熟行的方位需求在一切存储的列中坚持共同，不然就需求额定的机制来衔接列。**这对OLTP来说是个大问题，但对像库房或体系日志库这样的首要运用数据库来说不是个大问题。供给列存储的供货商包含Sybase、Vertica、Sand、Vhayu和KX。

4.7 数据库的可扩展性

联系型数据库有哪些扩展数据类型，为了能够扩展它做了哪些尽力？

4.7.1 笼统数据类型

最初的联系型数据库体系只支撑一组静态的字母数字列类型，这种约束与联系型模型自身相相关。

DBMS能够在运转时扩展到新的笼统数据类型。为了完结这一点，DBMS的类型体系——以及解析器——有必要由体系目录（system catalog）驱动，该目录保护着体系已知的类型列表，以及用于操作这些类型的 “办法”（代码）的指针。在这种办法中，DBMS不解说类型，它仅仅在表达式核算中恰当地调用它们的办法；因而被称为 “笼统数据类型”。典型的比如是“存储进程”，让你能够在SQL中履行自界说的函数。

4.7.2 结构化类型和XML

多年来，有许多主张对数据库进行积极的改动，以支撑非联系结构化类型：即嵌套的调集类型，如数组、调集、树，以及嵌套的图元和/或联系。或许今日这些主张中最相关的是经过像XPath和XQuery这样的言语对XML的支撑。

处理像XML这样的结构化类型的办法大致有三种：

树立一个定制的数据库体系，对具有结构化类型的数据进行操作
把XML类型当作一个ADT
DBMS在刺进时将嵌套结构 “规范化 “为一组联系，用外键将子方针衔接到它们的父方针

4.7.3 全文查找

传统上，在处理丰厚的文本数据和一般与之相关的要害词查找方面，联系型数据库是出了名的差。

可是，今日的大大都DBMS要么包含一个用于文本索引的子体系，要么能够与一个独自的引擎捆绑在一起来完结这项作业。文本索引设备一般既可用于全文文档，也可用于图元中的简略文本特色。在大大都状况下，全文索引是异步更新的（”抓取”），而不是业务性保护。在一些体系中，全文索引被存储在DBMS之外，因而需求独自的东西进行备份和康复。

5. 存储办理

DBMS存储办理器（storage manager）的两种拜访形式:

原始形式：直接与磁盘的初级的块设备驱动交互
OS文件体系：运用规范的OS文件体系东西

拜访形式会影响DBMS在空间和时刻上操控存储的才干。

5.1 空间操控（Spatial Control）

磁盘次序拜访比随机拜访的速度快10-100倍，且这个比例还在增加。因而，DBMS存储办理器的要害是：合理地寄存数据块，让大数据量的查询能够次序拜访磁盘。因为DBMS比底层的OS更清楚怎么拜访其存储的数据，因而由DBMS操控磁盘上数据块的拜访是有意义的。

操控空间局部性最好的办法有：

原始形式：彻底绕过文件体系直接将数据存储到“原始”磁盘上。
- 长处：局部性彻底可控
- 缺陷
  - DBA需求为DBMS进行磁盘分区
  - “原始磁盘”拜访接口一般是特定于操作体系的，难以移植
    - 大大都DBMS现已克服了此障碍
  - “虚拟”磁盘的盛行，导致原始形式的长处被淡化。RAID、Storage Area Networks(SAN) 和 logical volume managers。现在，大大都场景下，“虚拟”磁盘现已成为了规范。
大文件+偏移量：在文件体系中创立一个大文件，然后经过文件中的偏移量来办理数据的方位。
- 长处
  - 避免直接拜访块设备
  - 功用好

有的DBMS还支撑自界说数据页的巨细：

好处
- 适应不同的负载
缺陷
- 办理杂乱度进步
事例
- DB2，Oracle

5.2 临时空间操控：缓存

大大都操作体系供给了内置的I/O缓存机制，决议何时读写文件块。假如DBMS运用规范文件接口来写入数据，OS缓冲或许会经过静默推延或重排写入混淆DBMS的逻辑。这或许会导致DBMS呈现严重问题。因而，除了操控数据在磁盘上的方位之外，DBMS还有必要操控何时将数据写入磁盘。

不操控何时将数据写入磁盘或许会对DBMS形成的影响：

第一类问题：操作体系 I/O缓冲对ACID事物正确性影响。假如无法明确操控磁盘写入的时刻和次序，DBMS无法保证在软件或硬件毛病后进行原子康复。WAL要求在写入到数据库设备之前，需求先写入到日志设备，且在日志被可靠地写入日志设备之前，提交恳求不会回来。
第二类问题：操作体系 I/O缓冲问题会影响功用（但不影响正确性）。文件体系内置的预读（read-ahead）和后写（write-behind）机制不合适于DBMS的拜访形式。

文件体系逻辑依靠于文件中物理字节偏移的连续性来做出预读决议。DBMS根据未来的（在SQL查询处理层知道，但在文件体系中不简略辨其他）读取恳求，支撑逻辑上可猜测的I/O决策，这些恳求在SQL查询处理等级已知，但在文件体系等级不简略辨认。例如，在扫描不一定是连续的B+-树的叶子(行存储在B+-树的叶子中)时，能够恳求逻辑dbms等级的预读。逻辑预读在DBMS逻辑中很简略完结，办法是让DBMS提早宣布I/O恳求。
第三个功用问题：“双缓冲”和内存仿制的高CPU开支。假如DBMS自己需求做缓冲，那么操作体系做的额定缓冲便是冗余的。这种冗余会导致两个本钱：
1. 浪费了体系内存——能够进行有用作业的内存削减了。
2. 浪费时刻和处理资源。多了一个额定的仿制进程。
  
  内存中的仿制或许是一个严峻的瓶颈。仿制会导致推延，耗费CPU履行周期，且填满CPU数据缓存。因为CPU和RAM之间的速度差异，内存仿制成为了核算机架构中的首要瓶颈。
大大都现在体系都供给了钩子，能够让数据库这样的程序能够躲避两层缓冲文件缓存且能够操控页的替换战略。

5.3 缓冲办理

同享缓冲池：高效地拜访数据库页
- 缓冲池分配：静态分配 → 动态分配
- 缓冲池的结构：缓冲池由一组frame组成，每个frame是一个内存区域，巨细适当于数据库磁盘块。区块从磁盘仿制到内存中不需求格局转化，在内存中操作的是其原生格局，稍后会写回。这种不必转化的办法避了“编码”和 “解码”到/从磁盘中的CPU瓶瓶颈；更重要的是，固定巨细的frame避免了外部碎片和通用的紧缩技术导致的内存办理复度。
- 页替换: LRU算法

6. 业务：并发操控和康复

实践中，数据库体系并非是单体的、整体的软件体系，而是被分红多个独立的组件。而DBMS中真实单体的部分是 transactional storage manager，它一般包含4个深度交错在一起的组件：

用于并发操控的锁办理器（lock manager）
用于康复的日志办理器（log manager）
用于暂存数据库I/O的缓冲池（buffer pool）
用于安排磁盘上的数据的Access methods。

6.1 ACID 注意事项

回忆一下ACID：

原子性是对业务的 “全有或全无 “的保证——要么一个业务的一切行为都提交，要么都不提交。
共同性是一种特定于运用的保证；SQL完整性束缚一般被用来在DBMS中捕获这些保证。考虑到由一组束缚条件供给的共同性界说，一个业务只需在脱离数据库时处于共同性状况才干提交。

共同性严厉来说是凑数的，它一般需求运用程序来保护。
阻隔是对运用程序编写者的一种保证，即两个并发的业务不会看到对方的飞翔中的（没有提交的）更新。因而，运用程序不需求进行 “防御性 “编码以担心其他并发业务的 “脏数据”；它们能够被编码为程序员对数据库的仅有拜访。
耐久性是一种保证，已提交业务的更新在数据库中对后续业务是可见的，不受后续硬件或软件过错的影响，直到它们被另一个已提交业务掩盖。

粗略地说，现代DBMS体系经过锁协议完结阻隔性。经过日志和康复完结耐久性。阻隔性和原子性经过**锁（避免暂时数据可见） + 日志（保证可见数据的正确性）**保证。共同性由查询履行器在运转时查看：假如一个事物的操作会违反SQL共同性约束，该事物会被吊销并回来一个过错代码。

6.2 可串行化简要回忆

可串行化由DBMS并发操控模型强制履行。存在三种广泛的并发操控技术：

严厉的两阶段锁（2PL）：事物在读取数据之前取得同享锁，在写入数据之前取得互斥锁。一切的锁在事物完毕后主动开释。事物在等候获取锁时堵塞在等候行列中。

事物开端前获取锁，完毕后开释锁
多版别并发操控（MVCC）：业务不持有锁，而是保证在曩昔的某个时刻点上对数据库状况的共同视图，即使在那个固定的时刻点之后，行现已改动了。
达观并发操控（Optimistic concurrency Control, OCC）：多个业务被答应在不堵塞的状况下读取和更新一个项目。相反，业务保护其读和写的前史，在提交业务之前，查看前史上或许产生的阻隔抵触；假如发现任何抵触，其间一个抵触的业务将被回滚。

抵触检测 + 回滚

大大都商用DBMS运用2PL完结彻底的串行化。锁办理器是担任为2PL供给设备的代码模块。

为了削减锁和锁抵触，一些DBMS支撑MVCC或OCC，一般作为2PL的插件存在。在MVCC中，没有读锁，但这是一般以无法供给彻底串行化为代价完结的。

在商用MVCC完结中，共同视图要么是读事物开端时的值，要么是事物的最近的SQL句子开端时的值。
虽然OCC避免了锁上的等候，但在业务之间的真实抵触中，它或许会导致更高的赏罚。在处理跨业务的抵触时，OCC就像2PL相同，仅仅它将2PL中的锁等候转化为业务回滚。

6.3 锁和闩锁(Latch)

锁有不同的锁 “形式”，这些形式与锁—形式兼容表相关，一般的锁形式有：同享形式、独占（排他）形式。

锁办理器支撑两个根本调用：lock(lockname, transactionID, mode) 调用，和 remove transaction(transactionID) 调用。

关于2PL协议，不该该有独自的调用来独自解锁资源——remove transaction()调用将解锁与一个业务相关的一切资源。

关于较低程度的阻隔等级，需求一个unlock(lockname, transactionID)调用。还有一个upgrade(lockname, transactionID, newmode)调用，答应业务以两阶段的办法 “升级 “到更高的锁形式（例如，从同享形式到独占形式），而不需求放弃和从头获取锁。

此外，一些体系还支撑conditional lock(lockname, transactionID, mode)调用。带条件的lock()调用总是当即回来，并指出它是否成功地获取了锁。假如没有成功，调用的DBMS线程不会排队等候获取到锁。

为了支撑这些调用，锁办理器保护两个数据结构:

大局锁表。保存锁名及其相关信息。锁表是一个动态的哈希表，key是锁名的哈希值，value是一个锁形式标志，以及一个锁恳求(事物ID,形式)的等候行列。
事物表。key是事物ID，value包含每个事物T中都有的两个特色:
- 1. 一个指针，指向T的DBMS线程状况，当T获取到锁时，其对应的DBMS线程能够被从头调度。
- 1. 一个指针列表，指向大局锁表中T恳求的一切锁，以便删去与事物T相关的一切锁（例如，在事物提交或间断时）。

作为数据库锁的辅助手法，较轻量的闩锁（latch）也有互斥的功用。闩锁更相似于监控器或信号量，而不是锁；它们被用于完结对DBMS内部数据结构的互斥拜访。例如，缓冲池页表有一个与每个帧相关的锁，以保证在任何时分只需一个DBMS线程在替换一个给定的帧。闩锁被用于完结锁和或许被并发修正的、短暂安稳的内部数据结构。闩锁在很多方面与锁都有不同:

锁保存在锁表中，并经过哈希表定位；闩锁位于它们所保护的资源邻近的内存中，并经过直接寻址进行拜访。
在严厉的2PL完结中，锁需求在事物开端前获取，事物完毕后开释。闩锁能够在事物履行期间获取或开释。
锁的获取彻底由数据拜访驱动，因而获取锁的次序和声明周期受运用程序和查询优化器的操控。闩锁经过DBMS内部的特别代码获取，DBMS会根据战略恳求和开释闩锁。
关于锁来说，死锁是答应的，一般会检测死锁并经过重启事物来处理死锁问题。关于闩锁来说，有必要避免死锁；闩锁的死锁是DBMS代码bug。
闩锁运用原子的硬件指令或OS内核中的互斥指令来完结。
闩锁恳求最多耗费几十个CPU周期，而锁恳求需求几百个CPU周期。
锁办理器会追寻一个事物持有的一切锁，并在事物异常后主动开释锁；但在DBMS内部程序中，异常处理时需求手动清理闩锁。
闩锁无法被追寻，因而假如出错也无法被主动开释

6.3.1 事物阻隔等级

在业务概念开展的前期，人们试图经过供给比可序列化更 “弱 “的语义来进步并发性。应战在于怎么在这些状况下为语义供给强有力的界说。ANSI SQL规范界说了四个 “阻隔等级”：

读未提交: 事物能够读取任何已提交或未提交的数据，。这在锁的完结中是经过读取恳求的进行而不获取任何锁来完结的。
读已提交:事物能够读取任何已提交的数据。重复读取方针或许或导致读到不同版其他提交数据。这是经过读取恳求在拜访方针前获取一个读锁，然后在拜访该方针后当即开释锁完结的。
可重复读: 事物只能够读取某个版其他已提交的数据；一旦事物读取了一个方针，它总是会读取该方针的相同版别。这是经过读取恳求在拜访方针前获取一个读锁，且直到事物完毕共同持有该锁完结的。

乍一看，可重复读似乎供给了彻底的可序列化，但现实并非如此。可重复读存在幻读问题。
幻读(phantom read): 在同一个业务中用相同的谓词多次拜访一个联系，可是在再次拜访时看到了第一次拜访时没有看到的新的 “幻影 “记载。幻读产生的原因是行级粒度的两阶段锁不能避免向表中刺进新的记载。表的两阶段锁能够避免幻行，但在事物只能经过索引拜访几个元祖的状况下，表级确认或许会受到约束。
串行化: 保证彻底串行化的拜访。

商业体系经过根据锁的并发操控完结来供给上述四个阻隔等级。不幸的是，前期的ANSI规范没有供给真实明确的界说。它依靠于一个假定，即确认计划被用于并发操控，而不是达观的或多版别并发计划。除了规范的ANSI SQL阻隔等级之外，各种供货商还供给了额定的等级，这些等级在特定的状况下被证明是受欢迎的。

游标安稳性（CURSOR STABILITY）：这个等级是为了处理READ COMMITTED的 “丢掉更新（lost update） “问题。假定两个业务T1和T2。T1在READ COMMITTED形式下运转，读取一个方针X（例如一个银行账户的价值），记住它的价值，随后根据记住的价值写入方针X（例如在原始账户价值上增加100美元）。T2也读和写X（例如从账户中减去300美元）。假如T2的操作产生在T1的读和T1的写之间，那么T2的更新作用就会丢掉——在咱们的比如中，账户的终究价值将增加100美元，而不是像预期的那样削减200美元。在CURSOR STABILITY形式下的业务对查询游标上最近读到的记载持有一个锁；当游标被移动（例如，经过另一个FETCH）或许业务终止时，这个锁会主动丢掉。CURSOR STABILITY答应业务在单个记载上进行读—想—写的操作序列，而阻止其他业务的介入更新。
快照阻隔（SNAPSHOT ISOLATION）：在SNAPSHOT ISOLATION形式下运转的业务是在业务开端时存在的数据库版别上运转的；其他业务的后续更新对该业务来说是不行见的。这是MVCC在出产数据库体系中的首要用途之一。当业务开端时，它从一个单调增加的计数器中取得一个仅有的开端时刻戳；当它提交时，它从计数器中取得一个仅有的完毕时刻戳。只需当没有其他堆叠的事物（开端/完毕买卖时刻堆叠）写了相同的数据时，该事物才会提交。这种阻隔形式依靠于多版别并发来完结，而不是锁。可是，在支撑SNAPSHOT ISOLATION的体系中，这些计划一般是共存的。
共同读（READ CONSISTENCY）：这是由Oracle界说的MVCC计划；它与SNAPSHOT ISOLATION有纤细的不同。在Oracle计划中，每个SQL句子（在一个业务中或许有很多）看到的都是该句子开端时的最新提交的值。关于从游标中获取的句子，游标集是根据它被翻开时的值。这是经过保护单个记载的多个逻辑版别来完结的，一个业务或许引证一个记载的多个版别。与其存储或许需求的每个版别，Oracle只存储最新的版别。假如需求一个较早的版别，它经过采纳当时版别和 “回滚”，根据需求运用吊销日志记载来产生较早版别。修正是经过长时刻的写锁来保护的，所以当两个业务想写同一个方针时，第一个写者 “赢 “了，第二个写者有必要等候第一个写者的业务完结后才干持续写。比较之下，在SNAPSHOT ISOLATION中，第一个提交者 “赢”，而不是第一个写入者。

弱阻隔计划能够供给比彻底串行化更高的并发性。因而，一些体系乃至将弱共同性作为默许值。例如，Microsoft SQL Server默许为READ COMMITTED。缺陷是，阻隔（ACID意义上的阻隔）没有保证。因而，运用程序的编写者需求了解这些计划的奇妙之处，以保证他们的业务能够正确运转。考虑到这些计划在操作上界说的语义，这或许很扎手，并或许导致运用程序更难在DBMS之间移动。

6.4 日志办理器

日志办理器（log manager）担任保护已提交事物的耐久性、促进间断事物的回滚以保证原子性，以及担任从体系毛病或无序关机中康复。

日志办理器在磁盘上保护了一个日志记载序列，并在内存保护了一组数据结构。为了支撑在溃散后康复，内存中的数据结构需求能够从日志和数据库中的耐久化数据重建。

数据库康复的规范主题是预写日志（WAL）协议。预写日志协议由三个很简略的规矩组成：

每次对数据的更改都应该生成一个日志记载，且该日志记载有必要在数据库页被刷之前被刷到日志设备。
数据库日志有必要被按序刷入；直到一切在 r 之前的日志记载被刷入后，日志记载r才干被输入。
一旦事物提交恳求，提交日志记载有必要在提交恳求成功回来之前被刷到日志设备。

第1条保证原子性——未完结的事物的动作能够被吊销。第2、3条确坚耐久性——已提交事物的动作能够在体系溃散后被重做。

鉴于这些简略的准则，高效的数据库日志是令人惊奇的，因为它是如此奇妙和详细。可是，在实践中，上述简略的故事因为需求极端的功用而变得杂乱了。面对的应战是怎么保证提交的业务在 “fast path “上的功率，一起也为间断的业务供给高功用的回滚，并在溃散后快速康复。

这些准则虽然简略，但功率却很高。可是，在实践中，这些简略的准则因为需求极端的功用而变得杂乱。面对的应战是怎么保证提交的业务在 “快速途径（fast path）”上的功率，一起为间断的业务供给高功用的回滚，以及溃散后的快速康复。当增加特定的运用优化时，日志变得愈加杂乱，例如，支撑进步只能增量或减量的字段的功用（”保管业务”）。

为了最大限度地进步快速途径的速度，大大都商业数据库体系的运转形式被Haerder和Reuter称为 “直接（DIRECT）、偷盗（STEAL）/不逼迫（NO-FORCE）”:

数据就地更新
缓冲池中未固定的frame能够被“偷”，即使它们或许包含未提交的数据
在提交恳求回来到用户之前，缓冲池中的页不需求被“强制”刷到数据库。

这些战略将数据保存在DBA挑选的方位，它们给了缓冲区办理器和磁盘调度器充分的自由来决议内存办理和I/O战略，而不考虑业务的正确性。这些功用能够带来很大的功用优势，可是需求日志办理器有用地处理一切的奇妙问题，即吊销从间断的业务中偷来的页面的冲刷，以及重做对已提交的业务中因溃散而丢掉的非强制页面的修正。一些DBMS运用的一种优化办法是将DIRECT、STEAL/NOT-FORCE体系的可扩展性优势与DIRECT NOT-STEAL/NOT-FORCE体系的功用相结合。在这些体系中，除非缓冲池中没有干净的页面，不然页面不会被盗，在这种状况下，体系会退化到STEAL战略，并产生上述的额定开支。

日志中的另一个快速途径应战是坚持尽或许小的日志记载，以进步日志I/O的吞吐量。一个天然的优化是记载逻辑操作（例如，”将(Bob, $25000)刺进EMP”），而不是物理操作（例如，经过刺进元组修正的一切字节规模的后映像，包含堆文件和索引块上的字节）。这样做的权衡是，重做和吊销逻辑操作的逻辑变得适当杂乱。在实践中，运用的是物理和逻辑日志的混合物（所谓的 “生理 “日志）。在ARIES中，物理日志一般被用来支撑REDO，而逻辑日志被用来支撑UNDO。这是ARIES规矩的一部分，即在康复进程中 “重复前史 “以达到溃散状况，然后从该点回滚业务。

溃散康复是需求在体系毛病或非有序封闭后将数据库康复到一个共同的状况。如上所述，康复在理论上是经过重放前史，从第一条一直到最近的记载，一步步经过日志记载完结的。这种技术是正确的，但功率不高，因为日志或许是恣意长的。与其从第一条日志记载开端，不如从下面的这两条日志记载中最古老的一条开端康复，就能得到正确的成果：

描绘缓冲池中最古老的脏页的最早变化的日志记载；
代表体系中最古老的业务开端的日志记载。

这条日志的序列号被称为康复日志序列号（recovery LSN） 。因为核算和保存康复日志LSN会产生开支，并且咱们知道康复日志LSN是单调增加的，所以咱们不需求一直坚持它的最新状况。相反，咱们在称为**查看点（checkpoints）**的周期性间隔中核算它。

一个简略的查看点机制是强制一切的脏页刷盘，然后核算和存储康复日志LSN。关于一个大的缓冲池，完结脏页刷盘或许需求几秒钟的时刻。因而，需求一个更有用的 “含糊 “查看点计划，以及经过处理尽或许少的日志将查看点正确带到最近的共同状况的逻辑。ARIES运用了一个十分聪明的计划，其间实践的查看点记载十分小，只包含满意的信息来启动日志剖析进程，并能够从头创立溃散时丢掉的主内存数据结构。在ARIES含糊查看点期间，康复日志LSN被核算出来，但不需求同步写入缓冲池页面。选用一个独自的战略来决议何时异步刷盘。

请注意，回滚需求写入日志记载。这或许会导致一种状况——即因为日志空间耗尽，运转中的业务不能持续进行，但它们也不能回滚。这种状况一般是经过**空间预留计划(space reservation schemes)**来避免的，可是，这些计划很难在多版别体系中完结并坚持正确。

终究，因为数据库不仅仅是磁盘页上的一组用户数据记载，它还包含各种 “物理 “信息，使其能够办理其内部根据磁盘的数据结构，这使得日志和康复的使命愈加杂乱。咱们在下一节的索引日志中评论这个问题。

6.5 索引中的锁和日志

索引是用于拜访数据库中的数据的物理存储结构。索引自身关于数据库运用程序的开发者来说是不行见的，除非它们能进步功用或履行仅有性束缚。开发人员和运用程序不能直接观察或操作索引中的记载。这使得索引能够经过更有用的（和杂乱的）业务性计划来办理。索引并发和康复需求保存的仅有不变要素是——索引总是从数据库中回来业务上共同的记载。

6.5.1 B+树中的闩锁

B+树由数据库磁盘页组成，经过缓冲池拜访，就像数据页相同。因而，索引并发操控的一个计划是对索引页运用两阶段锁。这意味着每一个需求拜访索引的业务都需求确认B+树的根，直到事物提交——这种计划的并发性有限。为了处理这个问题，人们开发了各种根据闩锁的计划，而不在索引页上设置任何业务锁。这些计划的要害是对树的物理结构的修正（例如，拆分页面）能够以非事物的办法进行，只需一切并发的业务依旧能够在叶子上找到正确的数据。这方面大致有三种办法:

保存计划: 多个事物能够拜访同一个页中的不同内容。一个或许的抵触是，一个读业务想要遍历树的一个彻底打包的内部页面，而一个并发的刺进业务正在该页面下面操作，或许需求分割该页面。这些保存的计划与下面较新的想法比较，牺牲了太多的并发性。
闩与锁联合的计划。在每个树节点被拜访之前都会锁住它，只需当下一个要拜访的节点被成功锁住时才会解除锁住的节点。这种计划有时被称为闩锁 “抓取”，因为在树上 “抓 “住一个节点，”抓 “住它的子节点，开释父节点，然后重复这种动作。闩与锁耦合在一些商业体系中运用，如IBM的ARIES—IM版别。
右链接计划。向B+树中额定增加简略的结构，以尽量削减对闩锁和从头遍历的要求。特别是，在每个节点到右街坊之间增加了一个链接。在遍历进程中，右链计划不做闩与锁的耦合——每个节点都被闩、读取和解除闩。右链计划的首要思维是，假如一个遍历业务盯梢一个指向节点n的指针，发现n在中心被分割了，遍历业务能够检测到这个现实，并经过右链 “右移”，找到树中新的正确方位。一些体系也支撑运用反向链接进行反向遍历。

6.5.2 日志的物理结构

除了特其他并发逻辑外，索引还运用特其他记载日志逻辑。这种逻辑使得日志的记载和康复愈加有用，但代价是增加代码的杂乱性。首要的想法是，当相关的业务被间断时，关于索引结构的更改不需求在相关业务吊销时被吊销；这样的（索引结构）变化一般不会对其他业务所看到的数据库记载产生影响。例如，假如一个B+树页面在一个刺进业务中被割裂，而该业务随后又间断了，那么在间断处理进程中就没必要吊销割裂。

这带来的应战便是——将一些日志记载标记为只重做（redo-only）。在对日志的任何吊销处理进程中，只重做的修正能够保存（不必吊销）。ARIES为这些状况供给了一种高雅的机制，称为嵌套顶层举动（nested top actions），它答应康复进程在康复期间 “越过 “物理结构修正的日志记载，而不需求任何处理特别状况的代码。

6.5.3 Next-Key确认：

当一个业务经过索引拜访记载时，就会呈现幻行问题。在这种状况下，业务一般不会确认整个表，仅仅确认表中经过索引拜访的记载（例如，”Name BETWEEN ‘Bob’ AND ‘Bobby’ “）。在没有表级锁的状况下，其他业务能够自由地向表中刺进新的记载（例如，”Name=’Bobbie'”）。当这些新刺进的数据落在查询谓词的值规模内时，它们将呈现在随后经过该谓词的拜访中。请注意，幻行问题与数据库记载的可见性有关，因而是一个锁的问题，而不仅仅是锁的问题。准则上，咱们需求的是以某种办法确认原始查询的查找谓词所代表的逻辑空间的才干，例如，按照词典次序介于 “Bob “和 “Bobby “之间的一切或许字符串的规模。不幸的是，谓词确认是贵重的，因为它需求一种办法来比较恣意的谓词是否堆叠。这不能用根据散列的锁表来完结。

在B+树中，处理幻行问题的一种常见办法被称为下一个键确认(next-key locking)。在下一个键确认中，索引刺进代码被修正，这样，一个索引键为k的记载的刺进有必要对索引中存在的下一个键记载分配一个独占锁，其间下一个键记载的最低键大于k。它还保证记载不能被刺进到之前回来的最低键的记载下面。例如，假如在第一次拜访中没有发现 “Bob “键，那么在同一业务中的后续拜访中也不该该发现 “Bob “键。还有一种状况：刺进刚刚超越从前回来的最高键位元组的元组。为了避免这种状况，下一个键确认协议要求读业务在索引中的下一个键元组上也取得一个同享锁。在这种状况下，下一个键元组是不满意查询前提条件的最小键元组。更新在逻辑上体现为先删去后刺进，虽然优化是或许的和常见的。

下一个键的确认，虽然有用，但的确存在过度确认的问题，这在某些作业负载中或许会呈现问题。例如，假如咱们扫描从键1到键10的记载，可是被索引的列只存储了键1、5和100，那么从1到100的整个规模都会被读取确认，因为100是10之后的下一个键。

下一个键确认并不仅仅是一个聪明的骇客办法。它是一个运用物理方针（当时存储的元组）作为逻辑概念（谓词）的代名词的比如。这样做的好处是，简略的体系根底设备，如根据哈希的锁表，能够用于更杂乱的意图，只需修正锁协议。当这种语义信息可用时，杂乱软件体系的规划者应该将这种逻辑署理的一般办法放在他们的 “东西箱 “中。

6.6 事物存储的内部依靠

业务性存储体系的三个首要方面之间的一些相互依靠联系：并发操控、康复办理和拜访办法。在一个更幸福的国际里，有或许在这些模块之间确认狭窄的API，从而使这些API背面的完结能够被交流。咱们在本节的比如标明，这并不简略做到。咱们并不计划在此供给一份详尽的相互依靠联系的清单；生成并证明这样一份清单的完整性将是一项十分具有应战性的作业。可是，咱们的确希望能够阐明事物存储的一些曲折逻辑，从而证明商业DBMS中的单体完结是合理的。

咱们首要只考虑并发操控和康复，而不考虑拜访办法的进一步杂乱化。即使是这样的简化，各部分也是深深交错在一起的。并发和康复之间联系的一个体现是，预写日志对确认协议进行了隐含的假定。写入日志需求严厉的两阶段确认，而在非严厉的两阶段确认下，将无法正确操作。要看到这一点，请考虑在一个间断的业务的回滚进程中会产生什么。康复代码开端处理间断的业务的日志记载，吊销其修正。一般来说，这需求改动业务之前修正的页面或图元。为了进行这些修正，该业务需求在这些页面或图元上具有锁。在一个非严厉的2PL计划中，假如业务在间断前放弃了任何锁，它或许无法从头取得完结回滚进程所需的锁。

拜访办法使事情进一步杂乱化。将教科书上的拜访办法算法（例如线性散列或R-树），在事物体系中完结一个正确的、高并发的、可康复的版别，这是一个严重的智力和工程应战。因为这个原因，大大都领先的DBMS依然只完结堆文件和B+树作为事物保护的拜访办法；PostgreSQL的GiST完结是一个明显的破例。正如咱们在上面为B+树所阐明的那样，业务性索引的高功用完结包含杂乱的闩锁、确认和记载的协议。DBMS中的B+树充满了对并发和康复代码的调用。即使是像堆文件这样简略的拜访办法，也有一些环绕描绘其内容的数据结构的扎手的并发和康复问题。这种逻辑对一切的拜访办法来说都不是通用的——它在很大程度上是根据拜访办法的详细逻辑和它的特定完结而定制的。

拜访办法的并发操控只在面向锁的计划中得到了很好的开展。其他的并发计划（例如，达观的或多版其他并发操控）一般根本不考虑拜访办法，或许只在不经意间说到它们，并且不切实践。因而，关于一个给定的拜访办法完结，混合和匹配不同的并发机制是很困难的。

拜访办法中的康复逻辑是特别针对体系的：拜访办法日志记载的时刻和内容取决于康复协议的细节，包含对结构修正的处理（例如，它们是否在业务回滚时被吊销，假如不是，怎么避免），以及物理和逻辑日志的运用。即使是像B+树这样的特定拜访办法，康复和并发逻辑也是相互交错的。在一个方向上，康复逻辑取决于并发协议：假如康复办理器有必要康复树的物理共同状况，那么它需求知道哪些不共同的状况或许会呈现，以便用日志记载恰当地括住这些状况以完结原子性（例如，经过嵌套的顶部动作）。在相反的方向，一个拜访办法的并发协议或许依靠于康复逻辑。例如，B+树的右链计划假定树中的页在割裂后永远不会 “从头兼并”。这个假定要求康复计划运用一种机制，如嵌套的顶部举动，以避免吊销由间断的业务产生的割裂。

这儿的一个亮点是，缓冲区办理与存储办理器的其他组件相对阻隔得很好。只需页面被正确地缓冲，缓冲区办理器就能够自由地封装它的其他逻辑，并根据需求从头完结它。例如，缓冲区办理器能够自由地挑选要替换的页面（因为有STEAL特色），以及页面改写的调度（因为有NOT FORCE特色）。当然，完结这种阻隔是形成并发和康复方面的许多杂乱性的直接原因。因而，这个地方或许没有幻想中那么明晰。

7. 同享组件

在本节中，咱们将介绍一些同享组件和有用程序，它们几乎存在于一切商业DBMS中，但在文献中很少评论。

7.1 Catalog Manager

数据库目录（catalog ）持有体系中的数据信息，是元数据的一种办法。目录记载了体系中根本实体的称号（用户、形式、表、列、索引等）以及它们之间的联系，它自身作为一组表存储在数据库中。经过将元数据坚持在与数据相同的格局中，体系变得愈加紧凑，运用起来也愈加简略：用户能够运用与其他数据相同的言语和东西来调查元数据，而办理元数据的内部体系代码也与办理其他表的代码根本相同。这种代码和言语的重用是一个重要的教训，在前期阶段的实施中常常被忽视，一般会让后来的开发者感到十分遗憾。

因为功率的原因，根本目录数据的处理办法与普通表有些不同。目录中的高流量部分一般根据需求在主内存中被详细化，典型的数据结构是将目录的平面联系结构 “去规范化 “为一个主内存的方针网络。这种在内存中缺乏数据独立性的状况是能够承受的，因为内存中的数据结构只被查询剖析器和优化器以一种风格化的办法运用。额定的目录数据在解析时被缓存在查询计划中，并且一般是以合适查询的非规范化的办法。此外，目录表常常受制于特别状况下的业务处理技巧，以削减业务处理中的 “热门”。

在商业运用中，目录能够变得十分大。例如，一个首要的企业资源规划运用有超越60,000个表，每个表有4到8列，每个表一般有两到三个索引。

7.2 内存分配器

教科书中对DBMS内存办理的介绍往往彻底集中在缓冲池上。在实践中，数据库体系也会为其他使命分配很多的内存。对这些内存的正确办理既是一个编程担负，也是一个功用问题。塞林格局的查询优化能够运用很多的内存，例如，在动态编程期间树立状况。像哈希衔接和排序这样的查询操作者在运转时分配很多的内存。商业体系中的内存分配经过运用根据上下文的内存分配器而变得愈加有用和简略调试。

内存上下文是一个内存数据结构，它保护着一个连续的虚拟内存区域的列表，一般称为内存池。每个区域都能够有一个小头，包含一个上下文标签或一个指向上下文头结构的指针。内存上下文的根本API包含对以下内容的调用：

创立一个具有给定称号或类型的上下文。上下文类型或许会主张分配器怎么有用地处理内存分配。例如，查询优化器的上下文经过小的增量增加，而哈希衔接的上下文则以几个大的批次分配它们的内存。根据这些常识，分配器能够挑选一次分配更大或更小的区域。
在一个上下文中分配一大块内存。这个分配将回来一个指向内存的指针（很像传统的malloc（）调用）。该内存或许来自上下文中的一个现有区域。或许，假如在任何区域中没有这样的空间，分配器将要求操作体系供给一个新的内存区域，给它贴上标签，并将其链接到上下文中。
在一个上下文中删去一个内存块。这或许会也或许不会导致该上下文删去相应的区域。从内存上下文中删去是有点不寻常的。一个更典型的行为是删去整个上下文。
删去一个上下文。这首要开释了与该上下文相关的一切区域，然后删去了上下文头。
重置一个上下文。这将保存该上下文，但将其回来到最初创立时的状况，一般是经过吊销一切从前分配的内存区域。

内存上下文供给了重要的软件工程优势。最重要的是，它们能够作为废物搜集的初等级的、程序员可操控的替代品。例如，编写优化器的开发人员能够在优化器上下文中为一个特定的查询分配内存，而不必担心以后怎么开释内存的问题。当优化器挑选了最佳计划后，它能够从查询的独自履行器上下文中将计划仿制到内存中，然后简略地删去查询的优化器上下文。这就省去了写代码的费事，能够仔细阅读一切的优化器数据结构并删去它们的组件。它也避免了扎手的内存走漏，因为这种代码中的过错或许会导致内存走漏。这个功用关于查询履行的天然 “分阶段 “行为十分有用，操控从解析器到优化器再到履行器，每个上下文中都有一些分配，然后是删去上下文。

请注意，内存上下文实践上比大大都废物搜集器供给了更多的操控，因为开发者能够操控去分配的空间和时刻方位。上下文机制自身供给了空间操控，使程序员能够将内存分红逻辑单元。时刻上的操控来自于答应程序员在恰当的时分发布上下文删去。比较之下，废物搜集器一般在程序的一切内存上作业，并对何时运转做出自己的决议。这是试图用Java编写服务器质量代码的波折之一。

在malloc()和free()的开支相对较高的渠道上，内存上下文也具有功用优势。特别是，内存上下文能够运用语义常识（经过上下文类型），了解内存将怎么被分配和吊销，并能够相应地调用malloc()和free()，以尽量削减操作体系的开支。数据库体系的一些组件（例如解析器和优化器）会分配很多的小方针，然后经过上下文删去一次性开释它们。在大大都渠道上，调用free（）许多小方针是适当贵重的。内存分配器能够调用malloc()来分配大的区域，并将得到的内存分配给其调用者。相对来说，缺乏内存的吊销分配意味着不需求malloc()和free()运用的紧缩逻辑。当上下文被删去时，只需求调用几个free()来删去大区域。

有爱好的读者或许想阅读一下开源的PostgreSQL代码。这运用了一个适当杂乱的内存分配器。

7.3 磁盘办理子体系

DBMS的教科书倾向于把磁盘当作同质的方针。方针。在实践中，磁盘驱动器是杂乱的、异质的（异质）硬件，在容量和带宽上不同很大。在容量和带宽方面不同很大的硬件。因而，每个DBMS都有一个磁盘办理子体系来处理这些问题，并办理表和其他存储单元在原始设备、逻辑卷或文件上的分配。

这个子体系的一个职责是将表映射到设备和/或文件。表与文件的一对一映射听起来很天然，但在前期的文件体系中引起了严重问题。首要，操作体系文件传统上不能大于一个磁盘，而数据库表或许需求跨过多个磁盘。其次，分配太多的操作体系文件被认为是欠好的，因为操作体系一般只答应几个开放的文件描绘符，并且许多用于目录办理和备份的操作体系有用程序不能扩展到十分多的文件。终究，许多前期的文件体系将文件巨细约束在2GB。这显然是一个不行承受的小表约束。许多DBMS供货商运用原始IO彻底躲避了操作体系的文件体系，而其他供货商则挑选绕过这些约束。因而，一切领先的商业DBMS都能够将一个表涣散到多个文件中，或许在一个数据库文件中存储多个表。跟着时刻的推移，大大都操作体系文件体系的开展现已逾越了这些约束。可是留传的影响依然存在，现代DBMS依然一般将操作体系文件作为笼统的存储单元，恣意地映射到数据库表。

更杂乱的是处理设备特定细节的代码，以维持第四节所述的时刻和空间操控。今日有一个巨大而充满活力的产业，它根据杂乱的存储设备，”假装 “是磁盘驱动器，但实践上是大型硬件/软件体系，其API是一个传统的磁盘驱动器接口，如SCSI。这些体系包含RAID体系和存储区域网络（SAN）设备，往往具有十分大的容量和杂乱的功用特征。办理员喜欢这些体系，因为它们易于装置，并且一般供给易于办理、具有快速毛病搬运的位级可靠性。这些特色为客户供给了一种重要的舒适感，超越了DBMS康复子体系的承诺。例如，大型DBMS装置一般运用SANs。

不幸的是，这些体系使DBMS的完结变得杂乱。例如，RAID体系在产生毛病后的体现与一切磁盘正常作业时的体现十分不同。这有或许使DBMS的I/O本钱模型杂乱化。一些磁盘能够在写缓存形式下运转，但这或许导致硬件毛病期间的数据损坏。先进的SANs完结了大型电池支撑的缓存，在某些状况下挨近一兆字节，但这些体系带来了超越一百万行的微代码和适当的杂乱性。杂乱性带来了新的毛病形式，这些问题或许十分难以检测和正确诊断。

RAID体系也因为在数据库使命上体现不佳而使数据库规划者感到懊丧。RAID是为面向数据流的存储（如UNIX文件）而规划的，而不是数据库体系运用的面向页面的存储。因而，与数据库特定的处理计划比较，RAID设备在多个物理设备上分割和仿制数据时，往往体现不佳。例如，Gamma[43]的链式去lustering计划，与RAID的创造时刻大致符合，在DBMS环境中体现得更好。此外，大大都数据库供给了DBA指令来操控跨多个设备的数据分区，可是RAID设备经过将多个设备隐藏在一个界面后面来推翻这些指令。

许多用户装备他们的RAID设备，以尽量削减空间开支（”RAID等级5″），而数据库经过更简略的计划如磁盘镜像（”RAID等级1″）会体现得更好。RAID等级5的一个特别令人不快的特色是，写功用很差。这或许会给用户带来令人惊奇的瓶颈，而DBMS供货商往往要对这些瓶颈进行解说或供给处理办法。无论好坏，运用（和乱用）RAID设备是商业DBMS有必要考虑的一个现实。因而，大大都供货商花费了很多的精力来调整他们的DBMS，使其在领先的RAID设备上运转良好。

在曩昔的十年中，大大都客户的布置将数据库存储分配给文件，而不是直接分配给逻辑卷或原始设备。可是大大都DBMS依然支撑原始设备拜访，并且在运转大规模业务处理基准时常常运用这种存储映射。并且，虽然有上面概述的一些缺陷，今日大大都企业DBMS的存储是SAN保管的。

7.4 仿制服务

经过定时更新在网络上仿制数据库一般是可取的。这一般是为了取得额定的可靠性：仿制的数据库作为一个略微过时的 “热备用”，以防主体系产生毛病。在物理上不同的地方坚持热备用是有利的，能够在火灾或其他灾祸产生后持续运转。仿制也常常被用来为大型的、地理上分布的企业供给一种有用的分布式数据库功用的办法。大大都这样的企业将他们的数据库划分为大的地理区域（如国家或大陆），并在数据的主副本上运转一切本地更新。查询也在本地履行，但能够在来自本地操作的新鲜数据和从长途区域仿制的略微过时的数据的混合上运转。

疏忽硬件技术（如EMC SRDF），运用了三种典型的仿制计划，但只需第三种计划供给了高端设置所需的功用和可扩展性。当然，它也是最难完结的。

物理仿制。最简略的计划是在每个仿制期对整个数据库进行物理仿制。因为运送数据的带宽和在长途站点从头装置数据的本钱，这种计划不能扩展到大型数据库。此外，保证数据库的买卖共同性快照是很困难的。因而，物理仿制只被用作低端的客户端处理办法。大大都供货商并不鼓舞经过任何软件支撑来完结这一计划。
根据触发器的仿制。在这个计划中，触发器被放置在数据库表上，这样在对表进行任何刺进、删去或更新时，一个 “差异 “记载会被装置在一个特其他仿制表中。这个仿制表被运送到长途站点，并在那里 “重放 “修正内容。这个计划处理了上面说到的物理仿制的问题，但对某些作业负载来说，带来了不行承受的功用丢失。
根据日志的仿制。在可行的状况下，根据日志的仿制是首选的仿制计划。在根据日志的仿制中，一个日志嗅探器进程阻拦日志写入，并将其传递给长途体系。根据日志的仿制运用两种广泛的技术来完结：（1）读取日志并树立SQL句子来对方针体系进行重放，或许（2）读取日志记载并将其发送到方针体系，方针体系处于永久（永久的）的处于永久（永久的）康复形式，在日志记载到达时进行重放。这两种机制都有价值，所以Microsoft SQL Server、DB2和Oracle都完结了这两种机制。SQL Server称第一种为日志运送，第二种为数据库镜像。

这个计划克服了之前的一切问题：它是低开支的，对运转中的体系产生最小或看不见的功用开支；它供给增量更新，因而能够跟着数据库的巨细和更新率的变化而高雅地扩展；它重用了DBMS的内置机制，没有很多的额定逻辑；终究，它经过日志的内置逻辑天然地供给业务性的共同仿制。

大大都首要的供货商为他们自己的体系供给根据日志的仿制。供给跨供货商的根据日志的仿制要困难得多，因为在长途端驱动供货商的重放逻辑需求了解该供货商的日志格局。

7.5 办理员、监控和东西

每个DBMS都供给了一套用于办理其体系的有用程序。这些有用程序很少被作为基准，但往往决议了（操纵）体系的可办理性。体系的可办理性。一个在技术上具有应战性和特别重要的功用是使这些有用程序在线运转，即在用户查询和买卖正在进行时。这关于近年来因为电子商务的全球影响而变得愈加普遍的247的操作是很重要的。传统的 “重组窗口 “在清晨（一小会儿）的时分清晨时分的传统 “重组窗口 “一般已不复存在。因而，大大都供货商近年来都在供给在线服务方面投入了很多精力。咱们在这儿介绍一下这些东西的状况：

优化器统计数据的搜集。每一个首要的DBMS都有一些手法来扫描表并树立这样或那样的优化器统计数据。一些统计数据，如直方图，在不占用内存的状况下一次性树立是不难的。
物理重组和索引构建。跟着时刻的推移，因为刺进和删去的形式留下了未运用的空间，拜访办法或许变得低效。其他，用户或许偶然会要求在后台重组表，例如，在不同的列上从头分组（排序），或许在多个磁盘上从头分区。文件和索引的在线重组或许很扎手，因为在坚持物理共同性的一起，有必要避免坚持任何时刻的锁。在这个意义上，它与第5.4节中描绘的用于索引的记载和确认协议有一些相似之处。
备份/导出。一切的DBMS都支撑将数据库物理转储到备份存储器的才干。相同，因为这是一个长时刻运转的进程，它不能天真地设置锁。相反，大大都体系履行某种 “含糊 “转储，并经过日志逻辑来保证买卖的共同性。相似的计划也能够用来将数据库导出为交流格局。
批量加载：在许多状况下，很多的数据需求被快速带入数据库。与其一次刺进每一行，供货商供给了一个为高速数据导入而优化的批量加载东西。一般，这些东西由存储办理程序中的自界说代码支撑。例如，B+树的特别批量加载代码能够比重复调用树的刺进代码快得多。
监控、调优和资源办理器。即使是在办理环境中，查询所耗费的资源超越预期的状况也是很常见的。因而，大大都DBMS供给东西来协助办理员辨认和避免这类问题的产生。典型的做法是经过 “虚拟表 “为DBMS的功用计数器供给一个根据SQL的接口，它能够显现按查询或按锁、内存、临时存储等资源细分的体系状况。在一些体系中，还能够查询这些数据的前史日志。许多体系答应在查询超越某些功用约束时注册警报，包含运转时刻、内存或锁的获取；在某些状况下，警报的触发会导致查询被间断。. 终究，像IBM的猜测资源办理器这样的东西试图阻止资源密集型的查询被运转。

8. 结论

现代商业数据库体系既根据学术研讨，也根据为高端客户开发工业强度产品的经历。从头开端编写和保护一个高功用、全功用的联系型DBMS的使命是对时刻和精力的巨大投入。可是，联系型数据库办理体系的许多经历都能够转化为新的范畴。网络服务、网络附加存储、文本和电子邮件库、通知服务和网络监视器都能够从DBMS的研讨和经历中获益。数据密集型服务是当今核算的核心，而数据库体系规划的常识是一种广泛适用的技术，在首要数据库商铺的大厅表里都是如此。这些新的方向也提出了一些数据库办理方面的研讨问题，并为数据库社区和其他核算范畴之间的新的互动指明晰方向。

论文《Architecture of a Database System》小结