About Archive Tags RSS Feed

 

Cover your heart! Cover your heart!

13 January 2010 21:50

I've long been a fan of Danga's Memcached, back in 2005 I wrote about it for the first time.

Recently I've been looking at the persistant version, memcachedb which is essentially a Berkeley Database using the memcached protocol as the transport layer. This allows you to get persistance for free, and means you can rely upon the content being present, rather than just hoping it will be there as an opportunistic cache.

However in this brave new world of nosql I've been mulling over different options for new projects / new toys. I have to say that memcachedb lost out for me, and that Redis is my preferred flavour of new hot.

Redis has a rich API allowing you to store interesting datatypes such as lists, and it allows both replication and distribution (neither of which I need just yet, but both are useful to have as options for the future).

The documentation is great including a well-documented Twitter clone, and the facilities that are available are a step up from memcached, albeit obvious extensions which you'd expect if you were doing interesting things.

The redis-server package is already part of Debian GNU/Linux, and creating .deb package of the Redis module was trivial.

So now that I'm familiar with it, what to use it for? Well I think the first thing will be the new 2010 Valentines site.

Over the years I've hosted several Livejournal Valentine sites, and this year is no different. (Why? I like matching people, and I like social stuff. This is why I did ctrl-alt-delete in the past, even if that failed it was a great learning experience and I'd do it again if I had the time/patience/more optimism).

So far the site only has a couple of users but I fully expect it to ramp up considerably before the magical day (ha!). In the past I've limited the lifetime of the site(s) from Feb 1st to Feb 14th and still managed to achieve 5000+ users. Right now I'm using flat files for storage specifically to avoid database-load issues (which caused me considerable pain one year).

I suspect the backend will be Redis-based in the very very near future, but in the meantime if you're open to amusement and use Livejournal then feel free to poke at it: ljvalentine.com.

ObFilm: Indiana Jones and the Temple of Doom

| 7 comments

 

Comments on this entry

icon lamby at 08:21 on 13 January 2010

I used to package up a whole bunch of client libraries as they were previously part of the same tarball. Is this a vote for a real perl package? :)

icon Steve Kemp at 13:00 on 13 January 2010

I'd definitely like to see a libredis-perl package for the perl client API.

It would also be nice if the redis-cli binary were in a package too - it might be overkill to have it in its own package, but it was very useful to me and I was disappointed that I had to download and compile the source to get it.

icon lamby at 23:35 on 13 January 2010

A new redis-server with /usr/bin/redis-cli uploading as a speak.

About libredis-perl, I think that might be better maintained by the Perl team; I'll poke someone.

icon Steve Kemp at 13:17 on 14 January 2010

Perfect, thanks very much!

I'll update my lenny backport when I see it hit sid.

If the perl and other language bindings aren't in the same tarball anymore then it might make sense to off-load them to other people. But otherwise I'd assume having both server & client(s) be maintained by the same person/people would be a simpler approach.


icon Steve Kemp at 14:25 on 14 January 2010

OK I've done that now, just a couple of trivial changes to make it build under Lenny:

icon lamby at 19:48 on 14 January 2010

Out of interest, why backport when it can be installed from squeeze/sid?

The Python library is in NEW and I've asked diocles to upload a libperl-redis c/o pkg-perl. Oh, in case you've missed it, I've uploaded 1.2 (a stable release) a few hours ago.

icon Steve Kemp at 20:40 on 14 January 2010

Why backports? Because I never ever ever wish to run a mixed stable & testing system again.

I've sometimes trusted http://backports.org/, but mostly I prefer to host my own packages since that way I'll be sure they stay around for as long as I want them to.

Mostly backporting is trivial and so it's not a problem to make the effort.