RocksDB用于缓存服务的适用性及相关技术问题咨询

Hey there! Let me break down these questions about RocksDB clearly, since I’ve spent a lot of time working with it and comparing it to other caching/storage tools:

1. Is RocksDB single-threaded or multi-threaded? Does it handle all tasks in multi-thread mode? How does its multi-threading mechanism work, and does it have a thread task distribution system similar to a load balancer? #

RocksDB is highly multi-threaded, but not every task runs in multi-thread mode—here's the breakdown:

• Frontend (user requests): Individual read/write requests are typically handled by a single thread, but RocksDB uses thread-safe data structures (like MemTables) to support concurrent access from multiple client threads.
• Background tasks: This is where multi-threading shines. RocksDB maintains dedicated thread pools for tasks like:
  • Flushing immutable MemTables to disk (SSTable files)
  • Compacting SSTable files to optimize read performance and reclaim space
  • Cleaning up obsolete files and WAL (Write-Ahead Log) segments
• Thread task distribution: RocksDB has a built-in task scheduling system for its background threads. It prioritizes tasks based on urgency—for example, flushing a full MemTable takes priority over low-priority compaction tasks. The thread pool manages a queue of tasks and distributes them to idle threads automatically, acting like a lightweight internal load balancer without needing external tools.

2. What happens when there isn't enough memory to store new records? Unlike some caches that delete LRU data or throw out-of-memory errors, what's RocksDB's logic? #

RocksDB manages memory through two core components, and handles memory pressure gracefully:

• MemTables (write buffers): When a MemTable reaches its configured size (write_buffer_size), it's marked as "immutable" (no longer accepts writes) and a new empty MemTable is created to take incoming writes. The immutable MemTable is then flushed to disk as an SSTable by a background thread—this process doesn't block writes unless all allowed MemTable slots (max_write_buffer_number) are filled (in which case writes will wait until a flush completes).
• Block Cache (read cache): This cache stores frequently accessed data blocks from SSTables. When it reaches its size limit, RocksDB automatically evicts the least recently used (LRU) blocks to make space for new ones. It never rejects read requests due to a full cache—it just falls back to reading from disk, which is slower but still functional.

RocksDB won't throw an "out-of-memory" error on its own unless the underlying system runs out of memory (triggering the OS's OOM killer). Its internal logic is designed to balance memory usage and disk operations to keep the service running.

3. For high-traffic websites choosing a caching service, which has better performance: RocksDB or Memcached? I couldn't find relevant benchmark data. #

First, it's important to clarify: RocksDB is a persistent key-value store with caching capabilities, while Memcached is a pure in-memory cache—their use cases overlap but aren't identical. Here's how they stack up:

• Memcached performance: If you need pure in-memory speed with no persistence, Memcached is hard to beat. It has ultra-low latency (microseconds) and can handle hundreds of thousands to millions of QPS for simple key-value operations. It's ideal for caching ephemeral hot data (like product details, user sessions) where persistence isn't required.
• RocksDB performance: When most of your data fits in the Block Cache, RocksDB delivers near-memory speed (low millisecond to high microsecond latency) with the added benefit of persistence. If data needs to be written to disk, latency increases but is still far faster than traditional databases. RocksDB also supports more advanced operations (range queries, transactions, TTL) that Memcached doesn't.
• Benchmarks: While there's no universal public benchmark, real-world tests show that:
  • Memcached leads in raw in-memory QPS and latency for simple operations.
  • RocksDB matches Memcached's performance when data is cache-resident, and outperforms it if you need persistence or advanced features.

Choose Memcached if you need a lightweight, pure-memory cache. Choose RocksDB if you need a cache that can also persist data, support complex queries, or handle datasets larger than available memory.

内容的提问来源于stack exchange，提问作者Андрей Новиков