0

I am looking at using RocksDB (from Java in my case) as a secondary "cache" behind a RAM based first level cache. I do not expect any items in RocksDB to be dramatically more commonly accessed than others (all the really frequently used items will be in the first level cache) and there will be no "locality" (if there is such a concept in RocksDB?) as the "next" key in sequence is no more likely to be accessed next than any other so I would like to optimize RocksDB for "truly random access" by for instance reading as little data as possible each time, not have any "cache" in Rocks etc. All suggestions of configurations are appreciated!

Tristpost
  • 19
  • 4

1 Answers1

2

The defaults should be more than enough for your use case - but you can increase the block size and pin index and filter blocks

You can also call optimizeForPointLookup if you only are going to do puts and gets to optimize even further

Asad Awadia
  • 1,417
  • 2
  • 9
  • 15
  • Thanks for the sugestions - for my understanding how will increasing block size improve performance in this case when the gets will be so scattered - I would have thought the opposite (i.e. read as little as possible and allow OS cache to hold as many smaller block in the hope of geting some hits)... – Tristpost Apr 03 '22 at 05:37