Scaling Reads hard
Why might a database using Log-Structured Merge (LSM) Trees (like Cassandra/RocksDB) have slower read performance for specific keys compared to a B-Tree database (like PostgreSQL)?
- A LSM Trees do not use indexes.
- B LSM Trees require checking the MemTable and potentially multiple SSTables on disk to find the latest version of a key, whereas a B-Tree usually finds the exact leaf page in fewer hops.
- C LSM Trees store data in RAM only.
- D B-Trees are immutable.
Answer: B. LSM Trees require checking the MemTable and potentially multiple SSTables on disk to find the latest version of a key, whereas a B-Tree usually finds the exact leaf page in fewer hops.
LSM trees optimize for Writes (append-only). Reads are penalized because the data for a single key might be fragmented across different 'Levels' of files on disk, requiring compaction to clean up.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a caching system, what is a 'Cache Miss'?
- Why is `SELECT * FROM Users` generally discouraged in high-performance applications compared to `SELECT name, email FROM Users`?
- You have users all over the world downloading large images from your server in New York. Users in Australia complain it is slow. What solves this?
- What is the main downside of reading from a Read Replica instead of the Primary database?
- You have maximized the RAM on your single database server, but it's still too slow. You decide to add 10 more servers to share the load. What is this called?
- You have 5 Read Replicas. How does the application know which one to ask for data?