update questions

Signed-off-by: Alex Chi <[email protected]>
skyzh · Jan 23, 2024 · 20bb117 · 20bb117
1 parent 6520d8f
commit 20bb117
Show file tree

Hide file tree

Showing 3 changed files with 4 additions and 1 deletion.
diff --git a/mini-lsm-book/src/week1-06-write-path.md b/mini-lsm-book/src/week1-06-write-path.md
@@ -125,5 +125,6 @@ We do not provide reference answers to the questions, and feel free to discuss a
 ## Bonus Tasks
 
 * **Implement Write Stall.** When the number of memtables exceed the maximum number too much, you can stop users from writing to the storage engine. You may also implement write stall for L0 tables in week 2 after you have implemented compactions.
+* **Prefix Scan.** You may filter more SSTs by implementing the prefix scan interface and using the prefix information.
 
 {{#include copyright.md}}
diff --git a/mini-lsm-book/src/week1-07-sst-optimizations.md b/mini-lsm-book/src/week1-07-sst-optimizations.md
@@ -95,7 +95,7 @@ After that, you can modify the `get` read path to filter SSTs based on bloom fil
 
 We do not have integration test for this part and you will need to ensure that your implementation still pass all previous chapter tests.
 
-## Task 3: Key Compression Encoding + Decoding
+## Task 3: Key Prefix Encoding + Decoding
 
 In this task, you will need to modify:
 
@@ -121,6 +121,7 @@ After you finish the encoding, you will also need to implement decoding in the b
 * How does the bloom filter help with the SST filtering process? What kind of information can it tell you about a key? (may not exist/may exist/must exist/must not exist)
 * Consider the case that we need a backward iterator. Does our key compression affect backward iterators?
 * Can you use bloom filters on scan?
+* What might be the pros/cons of doing key-prefix encoding over adjacent keys instead of with the first key in the block?
 
 We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community.
 

diff --git a/mini-lsm-book/src/week2-04-leveled.md b/mini-lsm-book/src/week2-04-leveled.md
@@ -160,6 +160,7 @@ The implementation should be similar to simple leveled compaction. Remember to c
 * What is the peak storage usage for leveled compaction? Compared with universal compaction?
 * Is it true that with a lower `level_size_multiplier`, you can always get a lower write amplification?
 * What needs to be done if a user not using compaction at all decides to migrate to leveled compaction?
+* Some people propose to do intra-L0 compaction (compact L0 tables and still put them in L0) before pushing them to lower layers. What might be the benefits of doing so? (Might be related: [PebblesDB SOSP'17](https://www.cs.utexas.edu/~rak/papers/sosp17-pebblesdb.pdf))
 
 We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community.