mannually update README.md and bonus.md

This commit is contained in:
2024-04-14 13:23:05 +00:00
parent 9a8a273e56
commit bfec8b0842
2 changed files with 158 additions and 0 deletions

View File

@ -0,0 +1,66 @@
# 火车票管理系统
SJTU CS1951 课程大作业
## 概况
### 作业安排
本作业分为两个部分。
在第一部分中,需要实现一个基于文件的 B+ 树。
在第二部分中,需要实现一个火车票管理系统。此部分要求使用 Git 开发,维持良好的项目管理习惯。此部分的中期检查等检查方式均会通过查看登记的 Git 仓库链接,因此如果想更换仓库的链接请及时联系助教。
### 作业周期
**注意:管理系统的截止日期 (2024-06-02 第 15 周周日) 为作业的硬性截止日期,除非有极其特殊的原因,否则不接受任何在截止后的提交,所有代码均以截止前的提交为准!**
- B+ 树: 2024-04-14第 8 周周日)~ 2024-05-12第 12 周周日)
- 管理系统: 2024-05-12第 12 周周日)~ 2024-06-02第 15 周周日)
## 评分标准
本作业占本课程总成绩 15%,其中 B+ 树占 7%,管理系统占 8%。
- B+ 树: 7%
- OJ 测试: 80%
- Code Review: 20%
- 管理系统: 8%
- 正确性测试: 50%
- 在正确性测试中,每一个测试点都有一个相对宽松的时间和磁盘使用限制,以仅检验程序的正确性和鲁棒性,只要通过测试即可得到满分。因此请不要尝试针对特定情况进行有损正确性和鲁棒性的优化。
- 压力测试 - 30%
- 在压力测试中,每一个测试点会有两档时间和磁盘限制,通过所有 Easy 的测试可以得到 (60% * 30% =) 18% 的分数,通过所有 Hard 测试可以得到另外 (40% * 30% =) 12% 的分数。
- Code Review: 20%
bonus 另外计算,计入平时分总分,且不超过总分的 1%。
## B+ 树 - 7%
### 作业要求
作业要求实现基于 BPT 的外存管理系统。在本作业中,只允许调用以下头文件中的函数和类:
iostream, string, cstdio, cmath, string, fstream, filesystem
不允许使用这些头文件包含的 STL 容器 (如 `std::vector`) 或算法 (如 `std::sort`)。唯一的例外是,你可以使用 `std::string`。如果需要用到其他与算法、数据结构无关的标准库,请向助教提出请求。
你需要在最后通过 [OJ 测试](https://acm.sjtu.edu.cn/OnlineJudge/problem/2186)。
注意:建议使用类模板以方便后续完成管理系统。
## 管理系统 - 8%
敬请期待发布。
## Bonus
见 [Bonus 文档](bonus.md)。
准备自行设计并实现其他 bonus 的同学可以联系助教协商。
## 扣分
请保证自己项目结构的可读性,可以包括优化项目结构、完善 README 的内容、适当的文件树指南等晦涩难懂的项目可能会加大助教的工作量也可能会影响你的成绩B+ 树阶段此条可忽略)。
**如有出现任何抄袭现象按 0 分计,并按照违反学术诚信的操作办法处理。**

92
bonus.md Normal file
View File

@ -0,0 +1,92 @@
# Bonus
括号里的分值为最高得分(分数为期末总分),最终得分由 code review 确定。另请注意,总分值不能超过 1 分。
## B+ 树相关
### 缓存 *(0.2%)*
如果将一些常用数据存在内存中,可以省去大量从外存上读取的时间,这就是缓存的意义。
此 bonus 根据实现难度和工作量给分。推荐使用 [LRU 算法](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU))。
关于正确性,你需要用开启缓存的程序通过 OJ 测试。
**注意:** 不允许把全部数据储存在内存中。
### 空间回收 *(0.1%)*
在删除 B+ 树中某些数据后,可能会产生一些空间碎片。此 bonus 要求实现空间回收功能使得删除数据后B+ 树可以在下次需要空间时利用这些空间。
关于正确性,你需要用开启空间回收的程序通过 OJ 测试。
### 并发 *(1%)*
对于一个强大的数据库系统来说,并发功能是非常重要的。在本任务中,你需要实现 B+ 树的并发功能。
从 Wikipedia 上可以找到对于并发的定义:
> In computer science, concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the final outcome.
此 bonus 仅是对于 B+ 树的要求,如果感兴趣,你也可以让你的主体支持高并发操作。此 bonus 无需通过 OJ 测试,但会在 code review 时检查正确性。
**注意:** 准备尝试此任务的同学请务必与助教联系并讨论自己的实现思路。
### 快照 *(0.8%)*
对于一个强大的数据库系统来说,支持快照与恢复功能是非常重要的。在本任务中,你需要实现一个快照系统,实现任意快照间的切换。
一个快照几乎不会占用额外存储空间:
- 在一个状态上创建一个快照,应该只会占用很小的额外存储来记录这个快照本身的信息,不会将快照的内容完全复制一遍;
- 在同样的内容上创建 100 个快照,应该只会占用很小的额外存储,不会使磁盘占用增加 100 倍;
- 在创建快照之后改动一小部分内容,再创建一个快照,也应该只会占用很小的额外存储,不会使磁盘占用增加一倍。
要做到这点,可以利用 [Copy-on-write](https://en.wikipedia.org/wiki/Copy-on-write) 的做法。简单来说,就是令所有块都是不可变的,在试图修改一个块的时候,对这个块做复制,然后在复制出的新块上做修改。但是如果在不快照的时候也对这些块做 copy-on-write 的话,每修改一次数据,就会增加一个新块,这是不可接受的。因此,你需要只在快照的时候做 copy-on-write。
你需要实现以下接口:(以下内容中 `SnapshotID` 为快照 ID是一个最大长度为 16 的字符串,字符只包含大小写英文字母和数字)
- **创建快照** (create)
- 在当前状态上创建一个快照,名称为 `SnapshotID`
- 如果 `SnapshotID` 已经存在,则不做任何事并抛出异常。
- **还原快照** (restore)
- 还原到名称为 `SnapshotID` 的快照状态。
- 如果 `SnapshotID` 不存在,则不做任何事并抛出异常。
- 还原快照并不会影响任何快照的状态。它不会使被还原到的快照失效,也不会使其他快照失效。
- **删除快照** (delete)
- 删除名称为 `SnapshotID` 的快照状态,不改变当前状态。
- 其占用的存储空间也需一并释放;
- 如果 `SnapshotID` 不存在,则不做任何事并抛出异常。
**注意:** 准备尝试此任务的同学请务必与助教联系并讨论自己的实现思路。
### 容错 *(1%)*
程序执行时,我们可能会遇到突然断电等意外情况,导致操作中断。如果此时恰好在对磁盘进行读写操作,那么原本的文件系统就会被破坏,从而造成数据损坏的情况。
在 Unix 中常用的文件系统中,删除一个文件可以分为 3 步:
1. 删除访问的 entry 指针
2. 释放对应的 index node
3. 归还对应的磁盘空间
如果操作发生中断,一个常见的恢复方式是从第一条输入指令开始,重新执行一整轮操作,但是时间成本显然难以接受。
因此,我们可以实现一个 journaling file system利用日志来恢复文件保证文件的数据不被损坏。
我们可以考虑把一个指令分为多个 **原子操作** (atomic operation),在 journal 中保存每个原子操作。当程序中断时,我们就可以知道保存了哪些原子操作,进而进行文件恢复。
**Hint**:请思考一下在不同步骤发生中断时,应该如何选取合适的原子操作,并通过原子操作来恢复文件。 [reference link](https://en.wikipedia.org/wiki/Journaling_file_system)
## 管理系统
### GUI 前端 *(1%)*
提供一个用户友好的图形化前端Qt、Gtk、Web、Tcl/Tk 等均可)。基本要求为:
- 前后端分离,即前端代码不过度侵入主体逻辑;
- 用户能通过用户友好的图形化界面完成**所有**操作;
- 提供完整的《系统安装手册》;
- (可选)提供更方便的操作,如查询后提供一键订票等。
**注意:** 准备尝试此任务的同学请务必与助教联系并讨论自己的实现思路。