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 ( ©myNoSQL)
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)
Written in C, supporting HTTP 1.1 pipelining, using only
POST and making Redis commands part of the URI, with output in multiple formats (json, bson, txt, raw), ready to be forked or used on GitHub
Original title and link: Webdis: A Redis HTTP Interface with JSON Support (NoSQL databases © myNoSQL)
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