DBMS Architecture
现在并没有一个通用的关于数据库管理系统的设计蓝图。每个数据库都会有一些略微的不同，并且组件之间的边界也并很难去下定义。尽管这些边界在文档 (比如项目文档) 中体积，但在代码中，那些看起来映带独立的组件可能会因为一些性能优化、边界条件处理或架构选择等原因混杂在一起。
这些资料描述了数据库管理系统的架构 (如 [HELLERSTEIN07]，[WEIKUM01]、[ELMASRI11] 跟 [MOLINA08])，定义了组件之间的关联以及差异。在 Figure 1-1 中展示了其中较为通用部分的整体的架构。
数据库管理系统使用的是 client/server 模式，数据库系统的实例 (节点) 充当服务端 server 角色，应用的实例则充当客户端 client 的角色。
客户端的请求通过 transport 传输层 子系统接收，这些请求已查询的形式送达，大部分情况下他们是某种查询语言的表达式，传输层子系统同时还负责数据库集群中节点与节点之间的通信。
在接收到请求后传输层将查询转发给 query processor 查询处理器进行解析、翻译跟验证，在解析完成后，会对其进行访问控制验证，确认其执行权限。
之后解析完成的查询会被转发给 query optimizer 查询优化器，他会首先对查询中不必要的或者多于的部分进行排除跟裁减，然后会尝试根据一些全局的信息来找出最高效的执行方式，比如根据索引数据的数据量，或者数据的分布信息（比如集群中的哪些节点包含所需的数据以及其传输的代价等）进行分析。优化器同时需要对查询解析的关系操作 (通常表示为依赖树) 以及优化 (如索引顺序、数据的基数以及选择访问的方式) 进行处理。
具体的查询最后通常会表示为 execution plan 执行计划 (或 query plan)，他是一个操作的序列，在他被完整执行之后我们就能得到所需要的查询结果。相同的查询可能会同时符合不同的查询计划，优化器会在符合的查询计划中挑选出最合适的。
执行计划最后会交由 execution engine 执行引擎来执行，他会收集本地以及远程操作的执行结果，远程执行可能还会涉及到集群中其他节点的数据读写跟复制等操作。
本地的查询 (直接从客户端或其他节点发出的) 会交给 storage engine 存储引擎进行处理，存储引擎由下面的几个组件组成
-
Transaction manager该管理器对事务进行调度，以保证这些事务不会导致数据库产生逻辑性上的不一致。
-
Lock manager该管理器为数据库上执行的事务所涉及到的对象进行锁的管理，确保那些并行的操作不会违反数据在物理上的完整性。
-
Access methods (storage structures)该管理器负责访问跟组织磁盘上的数据，访问的方式主要包括了堆文件及存储的数据结构如 B-Trees 或 LSM Trees。
-
Buffer manager该管理器对内存中的数据页进行缓存
-
Recovery manager该处理器管理了操作日志，并负责将系统从失效的状态中恢复到正常状态。
这些组件合到一起就是，事务跟锁管理器负责并行控制，他们让并发操作能够尽量高效的执行，并确保数据在逻辑跟物理上的完整性。