From ce51eb0c6d858956d09cf2974d33b127748b74a6 Mon Sep 17 00:00:00 2001 From: Alex Chi Date: Sun, 28 Jan 2024 18:21:52 +0800 Subject: [PATCH] add question on alternative snapshot implementation Signed-off-by: Alex Chi --- mini-lsm-book/src/week3-01-ts-key-refactor.md | 3 +++ mini-lsm-book/src/week3-02-snapshot-read-part-1.md | 5 +++++ mini-lsm-book/src/week3-03-snapshot-read-part-2.md | 6 ++++++ mini-lsm-book/src/week3-04-watermark.md | 3 +++ mini-lsm-book/src/week3-05-txn-occ.md | 3 +++ mini-lsm-book/src/week3-06-serializable.md | 4 ++++ mini-lsm-book/src/week3-07-compaction-filter.md | 3 +++ 7 files changed, 27 insertions(+) diff --git a/mini-lsm-book/src/week3-01-ts-key-refactor.md b/mini-lsm-book/src/week3-01-ts-key-refactor.md index c12ea86..4753771 100644 --- a/mini-lsm-book/src/week3-01-ts-key-refactor.md +++ b/mini-lsm-book/src/week3-01-ts-key-refactor.md @@ -105,3 +105,6 @@ Now that we have a timestamp in the key, and when creating the iterators, we wil When you check if a user key is in a table, you can simply compare the user key without comparing the timestamp. At this point, you should build your implementation and pass all week 1 test cases. We will make the engine fully multi-version and pass all test cases in the next two chapters. + + +{{#include copyright.md}} diff --git a/mini-lsm-book/src/week3-02-snapshot-read-part-1.md b/mini-lsm-book/src/week3-02-snapshot-read-part-1.md index dfb61ae..2ec1bd0 100644 --- a/mini-lsm-book/src/week3-02-snapshot-read-part-1.md +++ b/mini-lsm-book/src/week3-02-snapshot-read-part-1.md @@ -24,3 +24,8 @@ pass all tests except week 2 day 6 * What is the difference of `get` in the MVCC engine and the engine you built in week 2? * In week 2, you stop at the first memtable/level where a key is found when `get`. Can you do the same in the MVCC version? + +We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community. + + +{{#include copyright.md}} diff --git a/mini-lsm-book/src/week3-03-snapshot-read-part-2.md b/mini-lsm-book/src/week3-03-snapshot-read-part-2.md index 8972a9c..10ed8ec 100644 --- a/mini-lsm-book/src/week3-03-snapshot-read-part-2.md +++ b/mini-lsm-book/src/week3-03-snapshot-read-part-2.md @@ -17,3 +17,9 @@ do not implement put and delete ## 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 `___.sst` as the SST file name? What might be the potential problems with that? +* Consider an alternative implementation of transaction/snapshot. In our implementation, we have `read_ts` in our iterators and transaction context, so that the user can always access a consistent view of one version of the database based on the timestamp. Is it viable to store the current LSM state directly in the transaction context in order to gain a consistent snapshot? (i.e., all SST ids, their level information, and all memtables + ts) What are the pros/cons with that? What if the engine does not have memtables? What if the engine is running on a distributed storage system like S3 object store? + +We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community. + + +{{#include copyright.md}} diff --git a/mini-lsm-book/src/week3-04-watermark.md b/mini-lsm-book/src/week3-04-watermark.md index 87f84cc..2d001f7 100644 --- a/mini-lsm-book/src/week3-04-watermark.md +++ b/mini-lsm-book/src/week3-04-watermark.md @@ -3,3 +3,6 @@ ## Task 1: Implement Watermark ## Task 2: Garbage Collection in Compaction + + +{{#include copyright.md}} diff --git a/mini-lsm-book/src/week3-05-txn-occ.md b/mini-lsm-book/src/week3-05-txn-occ.md index 2488675..3c20754 100644 --- a/mini-lsm-book/src/week3-05-txn-occ.md +++ b/mini-lsm-book/src/week3-05-txn-occ.md @@ -5,3 +5,6 @@ ## Task 2: Get and Scan ## Task 3: Commit + + +{{#include copyright.md}} diff --git a/mini-lsm-book/src/week3-06-serializable.md b/mini-lsm-book/src/week3-06-serializable.md index 5fb649f..43708ff 100644 --- a/mini-lsm-book/src/week3-06-serializable.md +++ b/mini-lsm-book/src/week3-06-serializable.md @@ -9,3 +9,7 @@ ## Test Your Understanding * If you have some experience with building a relational database, you may think about the following question: assume that we build a database based on Mini-LSM where we store each row in the relation table as a key-value pair and enable serializable verification, does the database system directly get ANSI serializable isolation level capability? Why or why not? + +We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community. + +{{#include copyright.md}} diff --git a/mini-lsm-book/src/week3-07-compaction-filter.md b/mini-lsm-book/src/week3-07-compaction-filter.md index 962137f..82213a6 100644 --- a/mini-lsm-book/src/week3-07-compaction-filter.md +++ b/mini-lsm-book/src/week3-07-compaction-filter.md @@ -1 +1,4 @@ # Snack Time: Compaction Filter + + +{{#include copyright.md}}