About Archive Tags RSS Feed

 

Blogspam moved, redis alternatives being examined

10 July 2014 21:50

As my previous post suggested I'd been running a service for a few years, using Redis as a key-value store.

Redis is lovely. If your dataset will fit in RAM. Otherwise it dies hard.

Inspired by Memcached, which is a simple key=value store, redis allows for more operations: using sets, using hashes, etc, etc.

As it transpires I mostly set keys to values, so it crossed my mind last night an alternative to rewriting the service to use a non-RAM-constrained service might be to juggle redis out and replace it with something else.

If it were possible to have a redis-compatible API which secretly stored the data in leveldb, sqlite, or even Berkley DB, then that would solve my problem of RAM-constraints, and also be useful.

Looking around there are a few projects in this area nds fork of redis, ssdb, etc.

I was hoping to find a Perl Redis::Server module, but sadly nothing exists. I should look at the various node.js stub-servers which exist as they might be easy to hack too.

Anyway the short version is that this might be a way forward, the real solution might be to use sqlite or postgres, but that would take a few days work. For the moment the service has been moved to a donated guest and has 2Gb of RAM instead of the paltry 512Mb it was running on previously.

Happily the server is installed/maintained by my slaughter tool so reinstalling took about ten minutes - the only hard part was migrating the Redis-contents, and that's trivial thanks to the integrated "slave of" support. (I should write that up regardless though.)

| 5 comments

 

Comments on this entry

icon antirez at 09:28 on 10 July 2014
http://redis.io

Hello Steve, did you evaluated different data layouts to save memory? Sometimes it is possible to do wonders.

icon Steve Kemp at 09:31 on 10 July 2014
http://steve.org.uk/.

Honestly no.

The priority was getting the system back up and running when RAM-exhaustion caused it to die. (That was achieved by taking down another KVM-guest on the same host, and assigning the freed memory to the blogspam guest).

It did cross my mind that I could shave back some RAM by renaming keys - e.g. changing a key from "blacklist-1.2.3.4" to "b-1.2.3.4", etc, but I figured that if that solved the problem it wouldn't do so indefinitely.

I am going to reassess the RAM-usage and see if I can be more efficient, but it'll probably take me until the weekend to find the time to do anything significant.


icon postgres_sqlite at 12:11 on 10 July 2014
http://kiem.pro

Some links that migth interest you
- www.slideshare.net/amdunstan/pgcon-redis
- http://www.pgxn.org/dist/redis_fdw/
Postgres is not so difficult to setup,
it justs sounds difficult (try to pronounce it :)
Sqlite is even easier, but postgres handles total system crashes much better, as this seemed to be important for you?


icon Tuyan Ozipek at 12:07 on 13 July 2014

Hi Steve,

Redis should already provide data persistence. Did i miss something in your blogpost , or did you already try it with no joy?

http://redis.io/topics/persistence

Cheers.

icon Steve Kemp at 12:47 on 13 July 2014
http://steve.org.uk/.

By persistence here I meant "cope with datasets larger than the RAM on the host". i.e. Persistence on-disk, or similar.

Redis does provide persistence, and it continues to serve me very very well on several hosts. Just one particular service has so much data that it wouldn't fit in RAM any more.