update toc for week 2

Signed-off-by: Alex Chi <iskyzh@gmail.com>

mini-lsm-book/src/week2-03-tiered.md

@@ -11,9 +11,13 @@ The tiered compaction we talk about in this chapter is the same as RocksDB's uni
 
 ## Task 1: Universal Compaction
 
-## Task 2: Compaction Simulation
+### Task 1.1: Triggered by Space Amplification Ratio
 
-## Task 3: Integrate with the Read Path
+### Task 1.2: Triggered by Size Ratio
+
+### Task 1.3: Reduce Sorted Runs
+
+## Task 2: Integrate with the Read Path
 
 ## Test Your Understanding
 

mini-lsm-book/src/week2-04-leveled.md

@@ -9,6 +9,12 @@ In this chapter, you will:
 
 ## Task 1: Leveled Compaction
 
+### Task 1.1: Compute Target Sizes
+
+### Task 1.2: Decide Base Level
+
+### Task 1.3: Decide Level Priorities
+
 ## Task 2: Compaction Simulation
 
 ## Task 3: Integrate with the Read Path

mini-lsm-book/src/week2-overview.md

@@ -45,7 +45,7 @@ So from the above example, we have 2 naive ways of handling the LSM structure --
 
 Compaction is a time-consuming operation. It will need to read all data from some files, and write the same amount of files to the disk. This operation takes a lot of CPU resources and I/O resources. Not doing compactions at all leads to high read amplification, but it does not need to write new files. Always doing full compaction reduces the read amplification, but it will need to constantly rewrite the files on the disk.
 
-The ratio of memtables flushed to the disk versus total data written to the disk is write amplification. That is to say, no compaction has a write amplification ratio of 1x, because once the SSTs are flushed to the disk, they will stay there. Always doing compaction has a very high write amplification. If we do a full compaction every time we get an SST, the write amplification will be quadratic to the number of SSTs flushed. For example, if we flushed 100 SSTs to the disk, we will do compactions of 2 files, 3 files, ..., 100 files, where the actual total amount of data we wrote to the disk is about 5000 SSTs. The write amplification after writing 100 SSTs in this cause would be 50x.
+The ratio of memtables flushed to the disk versus total data written to the disk is write amplification. That is to say, no compaction has a write amplification ratio of 1x, because once the SSTs are flushed to the disk, they will stay there. Always doing compaction has a very high write amplification. If we do a full compaction every time we get an SST, the data written to the disk will be quadratic to the number of SSTs flushed. For example, if we flushed 100 SSTs to the disk, we will do compactions of 2 files, 3 files, ..., 100 files, where the actual total amount of data we wrote to the disk is about 5000 SSTs. The write amplification after writing 100 SSTs in this cause would be 50x.
 
 A good compaction strategy can balance read amplification, write amplification, and space amplification (we will talk about it soon). In a general-purpose LSM storage engine, it is generally impossible to find a strategy that can achieve the lowest amplification in all 3 of these factors, unless there are some specific data pattern that the engine could use. The good thing about LSM is that we can theoretically analyze the amplifications of a compaction strategy and all these things happen in the background. We can choose compaction strategies and dynamically change some parameters of them to adjust our storage engine to the optimal state. Compaction strategies are all about tradeoffs, and LSM-based storage engine enables us to select what to be traded at runtime.
 
@@ -65,7 +65,7 @@ In tiered compaction, the engine will dynamically adjust the number of sorted ru
 
 The most intuitive way to compute space amplification is to divide the actual space used by the LSM engine by the user space usage (i.e., database size, number of rows in the database, etc.) . The engine will need to store delete tombstones, and sometimes multiple version of the same key if compaction is not happening frequently enough, therefore causing space amplification.
 
-On the engine side, it is usually hard to know the exact amount of data the user is storing, unless we scan the whole database and see how many dead versions are there in the engine. Therefore, one way of estimating the space amplification is to divide the full storage file size by the last level size.
+On the engine side, it is usually hard to know the exact amount of data the user is storing, unless we scan the whole database and see how many dead versions are there in the engine. Therefore, one way of estimating the space amplification is to divide the full storage file size by the last level size. The assumption behind this estimation method is that the insertion and deletion rate of a workload should be the same after the user fills the initial data. We assume the user-side data size does not change, and therefore the last level contains the snapshot of the user data at some point, and the upper levels contain new changes. When compaction merges everything to the last level, we can get a space amplification factor of 1x using this estimation method.
 
 Note that compaction also takes space -- you cannot remove files being compacted before the compaction is complete. If you do a full compaction of the database, you will need free storage space as much as the current engine file size.