为何RocksDB不直接缓存键值对而是采用Block缓存以加速单键读取？

Great question! It’s totally reasonable to wonder why RocksDB doesn’t just cache individual key-value pairs for O(1) lookups instead of going through block-based caching with binary searches. Let’s break down the key reasons:

• Memory Efficiency & Overhead Reduction
  Individual key-value pairs come with significant per-entry overhead: think hash table metadata, separate storage for each key, and tracking structures for every single entry. Blocks, on the other hand, bundle dozens or hundreds of key-value pairs together. The metadata overhead (like LRU tracking, block identifiers) is shared across all entries in the block, making it far more memory-efficient. For example, caching one 4KB block might cover 100 key-value pairs, using way less memory than caching those 100 pairs individually.

• Leveraging Disk IO Patterns
  RocksDB stores data on disk in fixed-size blocks—when you miss the cache for a single key, you still have to read the entire block from disk to get that key. If you don’t cache the block, the next time you need another key from the same block, you’ll have to hit the disk again. By caching the block, you turn one disk read into potentially hundreds of cache hits, drastically reducing IO operations (which are the biggest performance bottleneck for most storage systems).

• Better Cache Hit Rates
  LRU caches have limited capacity. Block caching naturally groups related keys (since RocksDB sorts keys within blocks), so when you access one key, you’re also caching adjacent keys that might be accessed soon (e.g., in range queries or sequential scans). This leads to much higher overall hit rates compared to caching random individual keys, which would only benefit their specific lookups and get evicted faster if they’re not frequently accessed alone.

• Lower Maintenance Complexity
  Managing a global hash table for millions (or billions) of individual key-value pairs is computationally expensive—you’d deal with constant hash collisions, frequent resizing, and high memory usage for the hash structure itself. Block caching operates at a coarser granularity, so the number of entries to track is orders of magnitude smaller. Plus, RocksDB supports block compression; caching compressed blocks saves even more memory, a benefit that’s negligible if you’re caching individual small key-value pairs.

• The "O(1) vs Binary Search" Tradeoff is Overblown
  While individual key caching gives O(1) lookups, the binary search within a block is practically negligible. A typical block holds hundreds of keys, so binary search only takes ~10 steps. Compare that to the milliseconds it takes for a disk read—this tiny in-memory operation is nothing compared to the IO savings you get from block caching.

内容的提问来源于stack exchange，提问作者user29131