Bruno Michel:

But Redis doesn’t let you have several databases with this naming schema. So my teammates have used something else for their projects: redis-namespace. The idea is to prefix all keys with a given string (foobar_development in my previous example) and a separator (:) by subclassing the Redis library for Ruby.

I’m a bit confused as I knew Redis support multiple databases per server—indeed they don’t have a nice name, but just an index. Still it should work just fine for this scenario.

Original title and link: Should We Namespace Redis? (NoSQL database©myNoSQL)

via: http://dev.af83.com/2012/07/31/should-we-namespace-redis.html

Until Redis Sentil becomes generally available, Spreecast’s Ruby library using Apache ZooKeeper might be the solution for high availability Redis clusters:

We decided to address these concerns by creating the redis_failover gem, which was recently released as open-source for Ruby environments employing Redis. The redis_failover gem aims to be a drop-in replacement for the existing Ruby client for Redis. redis_failover is equipped with the capability to recognize and handle an automatic (or manual) failover gracefully. The client knows to automatically direct write operations to the current master and read operations to one of N slaves. redis_failover is built on top of ZooKeeper, a proven distributed configuration and notification system that handles pushing changes to nodes across the network. We decided to use ZooKeeper since it automatically handles network partitions, quorum management, client discovery, and other difficult distributed computing problems.

Original title and link: Redis Failover at Spreecast Based on Apache ZooKeeper (NoSQL database©myNoSQL)

via: http://engineering.spreecast.com/spreecast-redis-failover/

The story of going form S3 to CouchDB and Redis and then back to S3 and Redis for ad serving:

The solution to this situation has a touch of irony. With Redis in place, we replaced CouchDB for placement- and ad-data with S3. Since we weren’t using any CouchDB-specific features, we simply published all the documents to S3 buckets instead. We still did the Redis cache warming upfront and data updates in the background. So by decoupling the application from the persistence layer using Redis, we also removed the need for a super fast database backend. We didn’t care that S3 is slower than a local CouchDB, since we updated everything asynchronously.

Besides the detailed blog post there’s also a slidedeck:

Original title and link: From S3 to CouchDB and Redis and Then Half Way Back for Serving Ads (NoSQL database©myNoSQL)

via: http://dev.adcloud.com/blog/2012/07/13/nosql-not-only-a-fairy-tale/

Jakub Łopuszański describes in much detail and with examples an algorithm for cache invalidation:

Imagine a bipartite graph which on the left hand side has one vertex per each possible subspace of a write query, and on the right side has vertices corresponding to subspaces of read queries. Actually both sets are equal, but we will focus on edges.

Edge goes from left to right, if a query on the left side affects results of a query on the right side. As said before, both sets are infinite, but that’s not the problem. There are infinitely many edges, but it’s also not bad. What’s bad is that there are nodes on the left side with the infinite degree, which means, we need to invalidate infinitely many queries. What the above tricky algorithm does, is adding a third layer to the graph, in the middle between the two, such that the transitive closure of the resulting graph is still the same (in other words: you can still get by using two edges anywhere you could by one edge in the original graph), yet each node on the left, and each node on the right, have finite (actually constant) degree. This middle layer corresponds to the artificial subspaces with “?” marks, and serves as a connecting hub for all the mess. Now, when a query on the left executes, it needs to inform only its (small number of) neighbours about the change, moving the burden of reading this information to the right. That is, a query on the right side needs to check if there is a message in the “inbox” in the middle layer. So you can think about it as a cooperation where the left query makes one step forward, and the right query does a one step back, to meet at the central place, and pass the important information about the invalidation of cache.

I’m still in front of a piece of paper understanding how it works.

Original title and link: Algorithm for Automatic Cache Invalidation (NoSQL database©myNoSQL)

via: https://groups.google.com/d/topic/memcached/OiScvRbGaU8/discussion

Redis-cli is getting a new pipe mode especially designed for bulk inserts as described in the documentation:

cat data.txt | redis-cli --pipe

The redis-cli utility will also make sure to only redirect errors received from the Redis instance to the standard output.

Original title and link: Redis Bulk Insert (NoSQL database©myNoSQL)

via: http://redis.io/topics/mass-insert

Erwin van der Koogh:

All of this allows me, a fairly decent Java developer with hardly any Javascript skills, to solve real world problems in record time. And that’s why I love Node and Redis.

It’s perfect if it works for you. But please do not automatically generalize it.

Original title and link: Why I Love NodeJS and Redis | Erronis (NoSQL database©myNoSQL)

via: http://erronis.nl/2012/04/05/why-i-love-nodejs-and-redis/

Vincent Driessen creates RQ as an alternative to Celery inspired by Resque:

I wanted a solution that was lightweight, easy to adopt, and easy to grasp. So I devised a simple queueing library for Python, and dubbed it RQ.

Welcome to the world of a thousand Redis-based queues.

Original title and link: Another Redis-Based Queue for Python: Introducing RQ (NoSQL database©myNoSQL)

via: http://nvie.com/posts/introducing-rq/

The nuts and bolts of implementing synchronous and asynchronous Redis clients supporting pipelining:

In this post I describe different approaches for client-libraries to implement Redis protocol pipelining. I will cover synchronous as well as asynchronous (event-driven) techniques and discuss their respective pros and cons: Synchronous client APIs require the library user to explicitly pipeline commands, potentially yielding optimal protocol performance, but at the cost of additional bookkeeping when handling replies. Asynchronous client libraries, on the other hand, allow automatic pipelining, while being less efficient in their pipelining behavior.

Original title and link: Automatic Async and Sync Pipelining of Redis Commands (NoSQL database©myNoSQL)

via: http://informatikr.com/2012/redis-pipelining.html