maokaihe/mini_lsm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add your solutions

Browse Source 
Signed-off-by: Alex Chi <iskyzh@gmail.com>
This commit is contained in:
Alex Chi
2024-01-28 21:13:10 +08:00
parent b04683fca4
commit c586aaffee
5 changed files with 35 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
mini-lsm-book/src/week3-03-snapshot-read-part-2.md
View File

@@ -1,12 +1,16 @@
# Snapshot Read - Engine Read Path and Transaction API
## Task 1: Store Largest Timestamp in SST
In this chapter, you will:
## Task 2: Recover Commit Timestamp
* Finish the read path based on previous chapter to support snapshot read.
* Implement the transaction API to support snapshot read.
* Implement the engine recovery process to correctly recover the commit timestamp.
## Task 3: Lsm Iterator with Read Timestamp
At the end of the day, your engine will be able to give the user a consistent view of the storage key space.
## Task 4: Multi-Version Scan and Get
## Task 1: Lsm Iterator with Read Timestamp
## Task 2: Multi-Version Scan and Get
For now, inner = `Fused<LsmIterator>`, do not use `TxnLocalIterator`
@@ -14,6 +18,10 @@ explain why store txn inside iterator
do not implement put and delete
## Task 3: Store Largest Timestamp in SST
## Task 4: Recover Commit Timestamp
## Test Your Understanding
* So far, we have assumed that our SST files use a monotonically increasing id as the file name. Is it okay to use `<level>_<begin_key>_<end_key>_<max_ts>.sst` as the SST file name? What might be the potential problems with that?