Riak & memory backend: handling expiration and pruning

140 views Asked by At

I am wondering what the best strategy is to manage expiration of session-related data stored in a memory Riak bucket type.

It seems that this backend supports ttl (http://docs.basho.com/riak/kv/2.2.3/setup/planning/backend/memory/#ttl and http://docs.basho.com/riak/kv/2.2.3/configuring/backend/#memory-backend), however the documentation of the second link states that:

"Once that object's time is up, it will be deleted on the next read of its key." What if the object will never be read again? Will it stay in-memory? However I guess it will eventually be destroyed when reaching the memory_backend.max_memory_per_vnode limit.

Is storing the expiration timestamp another relevant option? In this case pruning would be done by a process periodically searching for "old" timestamps:

:riakc_pb_socket.search(pid, "expirable_token", "exp_counter:[* TO 1542468475]")
# then we delete them

I've tested it by storing the timestamp in a counter since it's not possible to range-request registers that are indexed as strings:

iex(34)> :riakc_counter.increment(System.system_time(:second), :riakc_counter.new())
{:counter, 0, 1542468373}

However, I'm not sure counters are designed for storing integers. What's the best practice for storing integers in Riak data types? Custom schema with proper int type declared?

1

There are 1 answers

1
dams On

I'd recommend to use a different backend. Bitcask expiration is very efficient and can be configured very precisely. leveldb expiration works well enough.