0

As a follow-up to THIS question I asked earlier, are there any estimates of the per-key overhead in Riak when using the in-memory backend? Google hasn't helped much thus far, most searches leading me back to Bitcask estimates.

I'm basically trying to understand if the in-memory backend will be a better fit for storing session-ids per user, (each user being a separate key and the session-id being the ONLY value in this key) versus Bitcask. The per-key overhead is one of the variables I'm evaluating in this process.

Community
  • 1
  • 1
Dev Kanchen
  • 2,332
  • 3
  • 28
  • 40

1 Answers1

0

The memory backend does require the whole object to be stored in memory, which apart from the data, bucket and key includes the metadata that Riak adds to an object, e.g. vector clock, even if no user metadata or indexes are defined. I do not have an exact estimate of how large this metadata is, but believe that a few hundred bytes as outlined in the links provided in your previous question as well as this post on the Riak mailing list is fairly accurate.

Christian Dahlqvist
  • 1,665
  • 12
  • 9
  • Right. I was assuming that perhaps some of the metadata being stored per-key would be pruned when storing in-memory and hoping someone would have an idea of how much would be pruned. Keeping this open for a few more days in case any additional information comes through. Thanks! – Dev Kanchen Apr 08 '13 at 05:43
  • 1
    As the backends in Riak are pluggable, the format of the objects and their associated metadata does not depend on which backend that is used. – Christian Dahlqvist Apr 08 '13 at 09:32
  • Oh. Okay, that makes a lot of sense. The estimates don't change then. I'll mark this answer as accepted. Thanks. – Dev Kanchen Apr 08 '13 at 09:35