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

1
mini-lsm-book/src/week3-01-ts-key-refactor.md
View File

@@ -3,6 +3,7 @@
In this chapter, you will:
* Refactor your implementation to use key+ts representation.
* Make your code compile with the new key representation.
## Task 0: Use MVCC Key Encoding

7
mini-lsm-book/src/week3-02-snapshot-read-part-1.md
View File

@@ -1,5 +1,12 @@
# Snapshot Read - Memtables and Timestamps
In this chapter, you will:
* Refactor your memtable/WAL to store multiple versions of a key.
* Implement the new engine write path to assign each key a timestamp.
* Make your compaction process aware of multi-version keys.
* Implement the new engine read path to return the latest version of a key.
During the refactor, you might need to change the signature of some functions from `&self` to `self: &Arc<Self>` as necessary.
## Task 1: MemTable, Write-Ahead Log, and Read Path

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?