数据库并发控制理论

并发控制理论

Transactions

事务是在数据库上执行一系列一个或多个操作（例如 SQL 查询）以执行某些高级功能。

Strawman System

当每个 txn 到达 DBMS 时，逐一执行它们（即串行顺序）。

• DBMS 中可以同时运行一个且仅一个 txn。

在 txn 开始之前，将整个数据库复制到一个新文件并对该文件进行所有更改。

• 如果 txn 成功完成，则用新文件覆盖原始文件。
• 如果txn失败，只需删除脏副本

Problem Statement

一个（可能）更好的方法是允许独立事务的并发执行。
操作的任意交错可能导致：

• 暂时不一致(unavoidable)
• 永久不一致

我们需要正式的正确性标准来确定交错是否有效。

Definitions

一个txn可以对从数据库检索的数据执行许多操作

DBMS 只关心从数据库读取/写入哪些数据。

DB: 一组固定的命名数据对象
Txn : 读写操作的顺序

Transactions In SQL

一个新txn以BEGIN开始，以COMMIT或者ABORT结束

• 如果提交，这DBMS要么保存所有 txn 的更改，要么中止它。
• 如果中止，所有更改都将被撤消（undone），这样就好像 txn 根本没有执行过一样。

中止可能是txn自己造成的，也可能是由 DBMS 引起的。

Correctness Criteria : ACID

ACID 是数据库管理系统（DBMS）中用于确保事务处理可靠性和数据一致性的四个关键特性的缩写。这些特性有助于维护数据库在各种故障情况下的可靠性，并确保多个并发事务可以正确地操作和访问数据库。以下是 ACID 的四个特性：

1. 原子性（Atomicity）： 这意味着事务是不可分割的单元，要么全部执行，要么全部回滚。如果事务内的任何操作失败，整个事务将回滚到初始状态，不会留下部分更改。原子性确保数据库始终保持一致性状态。

2. 一致性（Consistency）： 事务在执行前后，数据库必须保持一致性状态。这意味着事务应该将数据库从一种一致状态转变为另一种一致状态，而不会破坏数据的完整性和约束。

3. 隔离性（Isolation）： 多个并发事务可以同时运行，但它们之间应该相互隔离，以防止彼此干扰。每个事务应该在完全独立的环境中运行，以避免数据不一致和竞态条件。

4. 持久性（Durability）： 一旦事务完成（提交），其更改应该在数据库中持久保存，即使在系统崩溃或故障后也应如此。这确保了数据的长期保存和可靠性。

这些 ACID 特性确保数据库在各种情况下都能维护数据的完整性和可靠性，尤其是在事务处理和并发操作的环境中。

Atomicity of txn

执行 txn 的两种可能结果:

1. 完成所有操作后提交
2. 执行某些操作后中止（或被 DBMS 中止）

DMBS保证txn的原子性atomic
从用户的角度来看：txn 总是要么执行其所有操作，要么根本不执行任何操作。

mechanisms for ensuring atomicity

方法1： logging

• DBMS 记录所有操作，以便可以撤消中止事务的操作
• 在内存和磁盘上维护撤消记录。

方法2：Shadow Paging

• DBMS 制作页面副本，并且 txns 对这些副本进行更改。 仅当 txn 提交时，副本页面才对其他人可见

Consistency

数据库所代表的“世界”在逻辑上是正确的。 所有关于数据的问题都会给出逻辑上正确的答案。
数据库一致性
txn一致性

Database Consistency

数据库准确地模拟现实世界并遵循完整性约束。

未来的txn会看到过去在数据库内提交的txn的影响。

Txn Consistency

如果数据库在txn开始前（单独运行）是一致的，那么txn开始后数据库也将是一致的。

txn一致性是应用程序的责任。 DBMS 无法控制这一点。

Isolation of Txn

用户提交 txn，每个 txn 的执行就像被它自己运行一样。

但是 DBMS 通过交错 txns 的操作（DB 对象的读/写）来实现并发。

我们需要一种方法来交错 txns，但仍然让它们看起来像是一次运行一个。

Mechanisms For Ensuring Isolation

并发控制协议是 DBMS 如何决定多个事务的操作的正确交错

两类协议
悲观(Pessimistic)：从一开始就不要让问题出现
乐观(Optimistic)：假设冲突很少发生，则在发生后进行处理。

Interleaving Txn

交错 txns 以最大化并发性。

• 磁盘/网络 I/O 缓慢。
• CPU多核

当一个 txn 由于资源（例如，页面错误）而停止时，另一个 txn 可以继续执行并取得进展。

Formal Properties of Schedules

Serial Schedule

• 不交错不同事务的操作的计划。

Equivalent Schedules

• 对于任何数据库状态，执行第一个Schedule的效果与执行第二个Schedule的效果相同。

Serializable Schedule

• 相当于事务的某些串行执行的计划。
• 如果每个txn都保持一致性，那么每个可序列化的Schedule也都保持一致性。

与 txn 启动时间或提交顺序相比，可串行性是一个不太直观的正确性概念，但它为 DBMS 在调度操作方面提供了更大的灵活性。

Conflicting Operations

我们需要一个正式的等价概念，可以基于“冲突”操作的概念有效地实现。
如果出现以下情况，则两个操作会发生冲突：

1. 他们是通过不同的txn
2. 它们位于同一个对象上，其中之一是写入。

交错执行异常 Interleaved Execution Anomalies

• Read-Write Conflicts (R-W)
• Write-Read Conflicts (W-R)
• Write-Write Conflicts (W-W)

考虑到这些冲突，我们现在可以理解调度可序列化意味着什么。

• 这是为了检查时间表是否正确。
• 这不是生成正确时间表的方法。
  

可串行化有不同级别：

• Conflict Serializability（Most DBMS try to support this）
• View Serializability （No DBMS can do this）

Conflict Serializability Schedules

两个Schedule 是冲突等价的

1. 它们涉及相同交易的相同操作。
2. 每对冲突的动作都以相同的方式排序

Schedule S 是冲突可序列化的，如果

• S是相当于某些串行调度的冲突。
• 可以通过交换不同事务的连续不冲突操作，将 S 转换为串行调度

Serializability

当计划中只有两个Txn时，交换Txn很容易。 当txns很多的时候就很麻烦了。

在实践中，系统支持冲突可串行化，因为它可以有效地实施。

为了允许更多并发性，一些特殊情况在应用程序级别单独处理。

Txn Durability

已提交事务的所有更改都应该是持久的。

• 没有撕裂的更新
• 失败的交易没有变化

DBMS 可以使用日志记录或影子分页来确保所有更改都是持久的。