Add illustration of log-structured storage

[brson]

Per questions mentioned here: https://github.com/pingcap/talent-plan/issues/114#issuecomment-510635176

It's not clear what to write to disk on "set". The task is purposefully open to interpretation, but there's not quite enough guidance yet. Also per #114 there needs to be some discussion about log management strategies.

The bitcask background reading should provide clues as to what do do here, but there's perhaps not enough text connecting the dots. Add a simple illustration of a growing log.

[brson]

Use asciiflow like in project 4.

[liufuyang]

It would so nice to have some simple illustration.

Perhaps, if possible, it might be good to have some simple illustration on a simple compaction method :)

---

Some other thoughs

Some difficulty I had when I first reading project 2 is that:

• I didn't know or I was not not clear that whether I could use serde to reconstruct the k, v map from a single file. So when I started to implement SET, I had to think a lot about whether this single file, without and positions/index/offset saved in it, will be able to construct the key values again in memory.

So, not sure if it is a good idea, but I feel, maybe it would be simpler for people to firstly implement a GET with a given single file format such as {"Set":{"key":"k1","value":"v1"}}{"Set":{"key":"k2","value":"v2"}}.

Then they can move on to implement SET to generate files like this above.

Or perhaps even also provide with some type definitions such as

#[derive(Serialize, Deserialize, Debug)]
enum Command {
    Set { key: String, value: String },
    Remove { key: String },
}

impl Command {
    fn set(key: String, value: String) -> Command {
        Command::Set { key, value }
    }

    fn remove(key: String) -> Command {
        Command::Remove { key }
    }
}

Because, as a Java people, I firstly never thought I could actually implement some methods on enum to help creating those enums. Also people new to Rust might didn't know how to match on enums easily like this

match command {
            Command::Set { key, value } => {
                return Ok(Option::Some(value));
            }
           ...
        }

So I feel it would be nice to have a few simple tips around here and there, would be nice as well. And I guess those "tips" can exist on another pages and only have links on the project page, so we can encourage students to firstly try think their solution then checkout some tips to see whether they are doing the Rust way or not.

If we don't provide any tips, people like me would start thinking: "Am I actually doing something making sense here or not??". And if I think too hard about it but couldn't get an answer, I will try search for source code / solutions around to verify whether I am doing the right thing or not :P

I don't know, hope my words about makes some sense :)