SImpleDB 包含:
- Classes that represent fields, tuples, and tuple schemas;
- A catalog that stores information about available tables and their schemas.
- One or more access methods (e.g., heap files) that store relations on disk and provide a way to iterate through tuples of those relations;
- A buffer pool that caches active tuples and pages in memory and handles concurrency control and transactions
- Classes that apply predicates and conditions to tuples;
- A collection of operator classes (e.g., select, join, insert, delete, etc.) that process tuples;
不包括
- Views.
- Data types except integers and fixed length strings.
- Indices.
- DDL
储存
Catalog 储存了所有表的信息。每个表的信息包括：name，schema，相应的 DbFile，以及 primary key。
SImpleDB 只支持两种 field，Interger 和 fixed length string。
每个表的 schema 用 TupleDesc 定义，其储存每个 filed 的 type 和 name。其除了支持用 index (offset) 获得 field 的 type 或 name，用 name 获得 field 的 index，还提供一个静态方法用于 merge 两个 TupleDesc 获得一个新的 TupleDesc （Join operator 使用）
tuple 用来储存 field，其除了提供第 i 个 field 的 getter/setter，还提供了所有 field 的 iterator。
tuple 有一个 record id 标志其在磁盘中的位置。
HeapPage 实现了 Page 接口。用一个 PageId 唯一标志，用来储存 tuples，其用一个 byte[] header 作为bitmap。
其支持在该 page 上插入/删除 tuple，标志该 page 为 dirty。还提供了迭代器用来迭代 page 中所有的tuple。
其支持将 page 实例序列化为 byte[] 和由 byte[] 构建 page 实例。
HeapFile 实现了 DbFile 的接口，其提供唯一的 ID，以及获得文件系统 File，table schema 的 API。
其支持从从磁盘获取数据(byte []), 并构建相应 page 实例。和将 page 序列化到磁盘。
buffer pool 存放了当前所有的 page 实例，如果已满，则会剔除某个page(如果 page 为 dirty，则 flush 到磁盘)。
所有对数据(都是以 page，也就是构建 HeapPage 实例)的访问都要经由 buffer pool （调用 getPage API）
这里必须要理清：
数据是储存在磁盘中的（支持序列化），当需要访问时，都会通过 bufferpool 获得。后者调用相应的 HeapFile 从磁盘中获得数据并生成 HeapPage 实例放入 bufferpool。
当 bufferpool 已满，会 kick out 一个page，如果那个 page 是 dirty 的，会先 flush 到磁盘（通过调用 HeapFile 的 writePage API）。
Operator
Operator 就是迭代器的连接，其实现 DbIterator 接口，其接受 child DbIterator。
SimpleDB 实现了 SeqScan，project, filter, join, aggregate, order_by。
除了 SeqScan，其他都由子 DbIterator 获得 tuples。
SeqScan 由 DbFileIterator (所有 DbFile 都要实现，用于获得 file 的所有数据) 获得 tuples
Transaction
Lab3 是实现 Transaction 功能
代码的变动不大，只要在 BufferPool read page 时添加获得锁的代码就行。
这是因为 SimpleDB 设计上所有对磁盘文件的获取都要经由 BufferPool。
所以 BufferPool 特别适合用来获得锁保证线程同步。
OS 中针对 IO 慢的问题也有类似的 Block Cache，其往往也是在这里实现同步。
关键是如何以正确的姿势获得锁和释放锁。
我这里添加了个 LockManager 类专门用来管理锁。
如果对性能要求不高，可以对获得锁的方法(accquireLock)专门上个锁，保证一个时间所有事务只有一个能使用该方法获得锁。
但这里我是保证要求同一个page 的多个事务只有一个能调用方法（通过 Java 中 synchronized (Object)）。
这里我犯了一个错误，我误认为所有 PageId 对象都是相同的，就用 synchronized (pid) 来保证同步化，但实际上每次访问 page 时会生成一个新的 PageId 对象，他们相等但不相同 (定义了 equals 和 hashcode 保证相等，但他们是不同对象)，所以使用 synchronized (pid) 并没有起到同步化的作用。正确的姿势是用一个Map，Map相等的 PageId 到同一个对象。
死锁检测没有什么好说的，就是检测 wait-lock-graph 有没有环的问题。
在 lab3 时，并没有使用 log 进行 recovery
其使用 NO-STEAL/FORCE
- You shouldn't evict dirty (updated) pages from the buffer pool if they are locked by an uncommitted transaction (this is NO STEAL).
- On transaction commit, you should force dirty pages to disk (e.g., write the pages out) (this is FORCE).
- 假设数据库在执行 transactionComplete 命令时不会崩溃，
以上三点使得不需要 log-based recovery，因为 you will never need to undo any work (you never evict dirty pages) and you will never need to redo any work (you force updates on commit and will not crash during commit processing).
