Project #4 - Concurrency Control 项目要求
摘要：
https://15445.courses.cs.cmu.edu/fall2022/project4/ OVERVIEW 这个项目是关于在 BusTub 中增加对事务的支持！为了实现这个目标，你将在你的数据库系统中添加一个 Lock Manager，然后用它来支持并发查询的执行。Lock Manag
Lecture#20 Database Crash Recovery
摘要：
上节课介绍到，故障恢复算法由两个部分构成： - 在事务执行过程中采取的行动来确保出现故障时能够恢复 (上节课) - 在故障发生后的恢复机制，确保原子性、一致性和持久性 (本节课) ## 1 ARIES 本节课介绍的是 Algorithms for Recovery and Isolation Exp
Lecture#19 Logging Schemes
摘要：
数据库在运行时可能遭遇各种故障，这时可能同时有许多正在运行的事务，如果这些事务执行到一半时故障发生了，就可能导致数据库中的数据出现不一致的现象： 这时就需要故障恢复机制来保证数据库的原子性、一致性、持久性。故障恢复机制包含两部分： 在事务执行过程中采取的行动来确保在出现故障时能够恢复 (本节课) 在
Lecture#18 Multi-Version Concurrency Control
摘要：
> MVCC 不是并发控制的 (继 2PL、时间戳控制协议) 第三种实现，它不单独作为一种并发控制的实现，而是与 2PL / 时间戳控制协议 (T/O、OCC) 结合使用。 多版本并发控制 (MVCC) 首次被提出是在 1978 年的一篇 MIT 的博士[论文](https://web.archiv
Lecture#17 Timestamp Ordering Concurrency Control
摘要：
上节课介绍的 2PL 是悲观的并发控制策略，本节课介绍的 Timestamp Ordering (T/O) 则是一个乐观的策略，其乐观表现在事务访问数据时无需显式加锁。 T/O 的核心思想就是利用**时间戳**来决定事务的可串行化执行顺序：**如果 $TS(T_i) 给它一个新时间戳后 restar
Lecture#16 Two-Phase Locking
摘要：
上节课介绍了通过 WW、WR、RW conflicts (使用 “交换” 或依赖图) 来判断一个 schedule 是否是可串行化 (serializable) 的方法，但使用该方法的前提是预先知道所有事务的执行流程，这与真实的数据库使用场景并不符合，主要原因在于： 1. 请求连续不断。时时刻刻都有
Lecture#15 Concurrency Control Theory
摘要：
回顾本课程的路线图： 在前面的课程中介绍了 DBMS 的主要模块及架构，自底向上依次是 Disk Manager、Buffer Pool Manager、Access Methods、Operator Execution 及 Query Planning。但数据库要解决的问题并不仅仅停留在功能的实现
Lecture#14 Query Planning & Optimization
摘要：
SQL是声明性的，这意味着用户告诉 DBMS 他们想要什么答案，而不是如何得到答案。因此，DBMS 需要将 SQL 语句转换为可执行的查询计划。 但不同的查询计划的效率可能出现多个数量级的差别，如 Join Algorithms 一节中的 Simple Nested Loop Join 与 Hash
Lecture#13 Query Processing2
摘要：
我们在 Lec12 中已经讨论了怎么将 operators 组织为一个 query plan。当时我们是假设 query 是由一个 worker (是 DBMS 的组件，负责代表客户机执行任务并返回结果，可能是一个线程或进程) 执行。然而在实践中，**query 往往是由多个 workers 并发执
