Storage Engines: LSM-Trees (Write-Heavy) vs B+ Trees (Read-Heavy)
B+ Trees optimize for point and range reads via fixed 4KB-16KB disk pages. Log-Structured Merge (LSM) Trees optimize for high write throughput by buffering writes in memory (MemTable) and flushing immutable SSTables to disk with background compaction.
The Post-it Notes on the Fridge vs The Alphabetical Filing Cabinet: LSM-Trees jot down quick Post-it notes into a pile (MemTable) and sort them into folders later (Compaction). B+ Trees open the heavy steel drawer and place each sheet into its exact alphabetical folder slot on every single write.
// LSM-Tree Architecture (RocksDB / Cassandra / ClickHouse): // 1. Write -> WAL (Disk) + MemTable (SkipList in RAM) [0ms latency!] // 2. MemTable full -> Flushed as immutable SSTable (Sorted String Table) on Disk // 3. Background Compaction: Merges overlapping SSTables, removes deleted keys (Tombstones).
Key Architectural Takeaways
- •LSM-Trees (RocksDB, Cassandra, Bigtable): High write throughput via sequential disk append, but higher read amplification.
- •B+ Trees (PostgreSQL, MySQL InnoDB): Predictable O(log N) read latency, but slower random write performance.
Using B+ Tree databases for massive write-heavy timeseries ingestion (1,000,000 writes/sec), causing disk I/O bottlenecks.
Use LSM-Tree based databases (ClickHouse, Cassandra, TimescaleDB, InfluxDB) for write-heavy telemetry.