From f35ed210c1cc2fb2ebe0d2ebd5631cb41288da11 Mon Sep 17 00:00:00 2001 From: Alex Chi Date: Thu, 23 Feb 2023 15:49:32 -0500 Subject: [PATCH] Update 04-engine.md --- mini-lsm-book/src/04-engine.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/mini-lsm-book/src/04-engine.md b/mini-lsm-book/src/04-engine.md index 3df4328..70225e7 100644 --- a/mini-lsm-book/src/04-engine.md +++ b/mini-lsm-book/src/04-engine.md @@ -77,9 +77,10 @@ Remember to change `SsTableIterator` to use the block cache. ## Extra Tasks -* As you might have seen, each time we do a put or deletion, we will need to take a write lock protecting the LSM - structure. This can cause a lot of problems. Some lock implementations are fair, which means as long as there is a - writer waiting on the lock, no reader can take the lock. Therefore, the writer will wait until the slowest reader - finishes its operation before it can actually do some work. One possible optimization is to implement `WriteBatch`. - We don't need to immediately write users' requests into mem-table + WAL. We can allow users to do a batch of writes. +* As you might have seen, each time we do a get, put or deletion, we will need to take a read lock protecting the LSM + structure; and if we want to flush, we will need to take a write lock. This can cause a lot of problems. Some + lock implementations are fair, which means as long as there is a writer waiting on the lock, no reader can take + the lock. Therefore, the writer will wait until the slowest reader finishes its operation before it can actually + do some work. One possible optimization is to implement `WriteBatch`. We don't need to immediately write users' + requests into mem-table + WAL. We can allow users to do a batch of writes. * Align blocks to 4K and use direct I/O.