Graham King:

On paternity leave for my second child, I found myself writing an in-memory hashmap (a poor-man’s memcached), in Go, Python and C. I was wondering how hard it would be to replace memcached, if we wanted to do something unusual with our key-value store. I also wanted to compare the languages, and, well, I get bored easily!

Actually it’s very easy and doesn’t require any coding at all. Plus you’ll get a bit more than what you’d expect.

Original title and link: In-Memory Key-Value Store in C, Go and Python (NoSQL database©myNoSQL)

via: http://www.darkcoding.net/software/in-memory-key-value-store-in-c-go-and-python/

So; what are the goals?

• to operate as a fully-functional Redis client (obviously)
• to be thread-safe and non-blocking
• to support implicit database switching to help with multi-tenancy scenarios
• to be on-par with redis-sharp on like scenarios (i.e. a complete request/response cycle)
• to allow absolute minimum cost fire-and-forget usage (for when you don’t care what the reply is, and errors will be handled separately)
• to allow use as a “future” – i.e request some data from Redis and start some other work while it is on the wire, and merge in the Redis reply when available
• to allow use with callbacks for when you need the reply, but not necessarily as part of the current request
• to allow C# 5 continuation usage (aka async/await)
• to allow fully pipelined usage – i.e. issue 200 requests before we’ve even got the first response
• to allow fully multiplexed usage – i.e. it must handle meshing the responses from different callers on different threads and on different databases but on the same connection back to the originator

A driver library that doesn’t support connection pooling and is not thread safe should not be considered production ready. And the future belongs to drivers that also offer an asynchronous non-blocking timeout-enabled API.

Original title and link: BookSleeve: StackExchange Redis C# async Library (NoSQL databases © myNoSQL)

via: http://marcgravell.blogspot.com/2011/04/async-redis-await-booksleeve.html

We have already talked about queues being a good Redis usecase and covered QR, Resque and thanks to readers heard of RestMQ.

Now we also have Babershop:

Barbershop is a simple priority queue daemon written in C using libevent and some well-crafted indexes and reverse indexes. With Barbershop, your created jobs’ ids are injected into Barbershop and the clients then query Barbershop for the next task/job to perform. You get the power that is Redis to scale tasks/jobs horizontally and the ability to increment and peak into a priority queue to adjust your application as needed.

Interesting ☞ comment from Salvatore Sanfilippo (@antirez)

Btw IMHO the way to go for Redis priority queues is mapping the priority to a discrete number of Redis lists instead going continuous

via: http://blog.socklabs.com/2010/03/10/creating-priority-influenced-jobs-with-barbershop/