why doesn't rocksdb cache key-value pair directly instead of block?

[Xiaofan Chen]

Rocksdb has LRU for caching blocks. But why doesn't it cache key-value pair directly to speed up single key read? For getting a key, with block cache, one needs to locate the block (O(1)) and then maybe do a binary search inside a block to find the key. But if cache keys directly, can get key in O(1) time.

[mram...@gmail.com]

I can think of a couple of reasons:

- Caching of keys would be a lot more expensive than caching of the blocks.  Keys and values have to be smaller than blocks, so there is going to be much more expense in keeping the cache current.  In addition to the small key, RocksDB would also need to cache the database and column family for each key, making the size of the keys fairly large w.r.t the value being cached

- The cache would have to deal with things like compaction and TTL and range deletions, adding to the complexities.

- Caching of keys solves a very specific use case where specific keys are repeatedly accessed.  That is a different use case than is solved by caching blocks, which would cache a range of similar keys (blocks contain a set of sorted keys).

- Caching of keys could be done in user-code (or a higher layer) that wraps RocksDB if required by the application.  Caching of blocks has to happen inside of RocksDB (since outer layers are unaware of blocks).

This is not to suggest that there is not a valid case to be made for caching the keys directly, but that they are trade offs involved.  Caching of blocks comes with its own set of issues and trade offs. 

I can see advantages and issues with the caching of keys directly but am not aware of it being implemented in or on top of RocksDB.

/ Mark

[Xiaofan Chen]

After reading code I found that rocksdb has RowCache, but it seems to be not widely spoken, not even in rocksdb wiki, wierd, Anyone got clue?

[Xiaofan Chen]

anyone has used that in product? We r evaluating it.

[Mr Koo]

how was the evaluating going?