A Newsletter About Everything Redis

Issue #40
April 16th, 2015

Editor's Note

The number 40 traditionally signifies a large number so this issue definitely qualifies as an umpteen milestone. BTW, did you know that "forty" is the only integer with its letters in lexicographical order?

Also, many (i.e. >0) of Redis Watch's readers have complained about the last issue's strange loop in the Redis Trivia section. I have a fetish for self references and I apologize if it sometimes gets out of hand – if it's any consolation, please accept an alternative Redis Trivia #39 that doesn't refer to itself even remotely (although it does make issue #39 the first issue to have two trivia facts ;)).

Remindr: on Tuesday, April 21st, you can meet Lukas Sliwka, Vice President Engineering @Grindr, and listen to his #NYCSQL Tech Talk about "Using Redis to Create a Blazing Fast Mobile App" (+swag, beer & drinks, candy…) – free signup at: http://www.meetup.com/mysqlnyc/events/221681071/?action=detail&eventId=221681071

Redis Trivia #39a: Redis embeds strings that are up to 39 bytes long, larger ones it devours uncooked

Redis Trivia: There are 160 tags in the Redis repository from the first commit until v3.0.0


Be social, share this issue of Redis Watch (tweet can be edited before posting): I'm reading Redis Watch #40: https://redislabs.com/redis-watch-archive/40

int main(int argc, char **argv) { 

Intro | Redis  (00:11 minutes to watch)

Mandatory to watch: 11 seconds of pure Redis experience (LP version hitting the market soon?).

A Conversation with the Core Developer of Redis (18:11 minutes to watch)

Salvatore Sanfilippo @antirez interviewed by Rags Srinivas @ragss from @Pivotal via @InfoQ taken at the recent @RedisConf. FQ:

"Redis it's a bit strange project because it is a database in some way, is a cache in some way and it is a messaging system in some other way. So what if it's true of all these many different aspects of Redis, I think that the reality is that Redis is actually a different object, it's like cut, strip down a programming language with just a DSL basically, a Domain Specific Language, that can alter data structures and the data structures are optionally durable on disk."

Learn to stop using shiny new things and love MySQL (10 minutes to read)

@Pinterest's founding engineer and architect Marty Weiner @MartyWeiner and the Pinterest Engineering @PinterestEng team share their love for a hit from the 90's, namely MySQL. The right hammer for the right nail and so forth, but always good to learn from/off the experience of others #ILoveItWhenYouTalkBigOhToMe:

"FIFOs, such as feeds: My biggest complaint about MySQL is that it's still living in 1994 (with baggy pants and the.. erk.. Macarena). Many uses of databases back then needed relational queries. There were no social networks. MySpace wouldn't come around for another nine years! And so MySQL is built out of trees and has no good notion of queues. To insert into a B-tree is an O(lg(N)) operation (assuming happy balance). But today, social networks are a major force on the internet, and they depend heavily on queues. We want uber fast O(1) enqueuing! My suggestion is to not use MySQL for feeds. It's too much overhead. Instead, consider Redis, especially if you're still a small team. Redis is super fast and has lists with fast insertion and retrieval. If you're a larger company and can hire the folks to maintain it, consider HBase. It's working well for our feeds."

Microsoft's Redis Implementation – Mind the Gap (24 minutes to read)

A 2-part series from Stephen Kennedy @DevEnable about the state of Microsoft Open Technologies @OpenAtMicrosoft's Redis, mainly from the POV of a DIYer. While some gaps can be breached (i.e. even by running the vanilla OS Redis version on Linux in a VM), the points raised are very valid and expose some of the unique challenges when working with Redis via .NET (kudos Marc Gravell @marcgravell for his amazing StackExchange.Redis client).

Redis Ram Ramifications – Part I (13 minutes to read)

Something I've been wanting to do for a long time now – a cartographical exercise of sorts if you will, feedbacks are always more than welcome.

Tools & Development

Making Autolab's Backend Scalable

#Python #howto

Ilter Canberk @icanberk discusses Tango, a backend service used by the bigger Autolab project, for autograding. A queue management at heart, Tango's design lets it dance with larger loads, with Redis beneath the hood.


#Puppet #foss

Puppet masters rejoice! What at first appears to be yaprm is actually based on solid reasoning. Blog post: https://www.scriptscribe.org/infrastructure/yet-another-puppet-redis-module-heres-why/ and mailing list item: https://groups.google.com/d/msg/redis-db/bLc72-Vm8TQ/htpLvVZRXVoJ by Dan Sajner @devopsdans via @CoverMyMeds.


#NodeJS #foss

A delightful, performance-focused Redis client for Node and io.js by Zihua Li @luinlee who works at Alibaba. Looks chock-full of goodness, including full Cluster/Sentinel support, Lua scripts management, error handling strategy and much more.

Some Architectural Design Concepts For Redis

#Redis #howto

Yusuf Uzun @ysfuz review of several configurations and topologies for Redis – solid analysis and clear diagrams.

Finding Spammers & Scammers through Rate Tracking with Python & Redis (27:47m)

#Python #video

An uplifting, heart-warming and moving talk by Mica Swyers @micaswyers and Jay Chan @justecorruptio from Eventbrite Engineers @evbeng given at @PyCon 2015. The talk covers rate tracking & Redis basics, as well as introduces the bad-ass Redis-based Velocity Engine that emulates windowing, arbitrary granularity and tracks Top-N actors. More background at: https://engineering.eventbrite.com/heavy-hitters-in-redis/. Quite a few good laughs and one open question – why isn't it open source?


#Ruby #foss

From Michael Parrish @michael_parrish comes a rate limiter that provides both time-based limits and quantity-based limits (based on @ClassDojo's rolling-rate-limiter(RW#31).

Invalidation Semantics and Caching Strategy for a Redis Cache

#Redis #mailinglist

I'm so happy I didn't answer this one because instead we got a great #instantclassic answer from Dvir Volk @dvirsky.

Dancing around strings in Node.js and Redis

#NodeJS #howto

Kyle Davis @stockholmux tells how he came to terms with his colons (:).


#ObjectiveC #foss

Creator of rlite (RW#34), Sebastian Waisbrot @seppo0010, with an Ohm-bective port of Michel Martens @soveran's popular mapper.

Writing a Redis client in pure Bash

#Bash #howto

Nikola Krzalic @nkrzali likes it so raw that he uses Bash 🙂 Inspired by the HN thread on Redis-Pipe (RW#38) but quite original by it's own right. One can't help but wonder what's the next client implementation going to be – Assembler? Brainfuck? How about plain old MS-BASIC?


#Docker #foss

Thus making it even easier to run your Redis Cluster from Johan Andersson @GrokZen RW#11.


Charity Majors @mipsytipsy: "OH "So here's a terrible command that you should definitely never run …"" + "fwiw the command was redis "KEYS *", which we have actually protected against by renaming to a long random string. http://redis.io/topics/security"

nulltype: "I hear redis is the new heapness."

Marcus Andre @meggesje: "Just learned about the Redis command BRPOPLPUSH. It's amazing and could make your queues much more reliable. http://redis.io/commands/brpoplpush #redis"

Mike J. Reid @kineticnz: "enjoying just how easy Redis 3.0 is to cluster. delightful"

Josh Nesbitt @joshnesbitt: "Redis is by far one of the most solid pieces of software ever written. Absolute workhorse."

Tim Lossen @tlossen: "shutting down production server …> uptime_in_days: 553> total_commands_processed: 13971662268 (= 25m ops per day) #redis #serverporn"

I Wayan Ryandi @ryandisaskara: "fall in lope with redis . blazingly fu*cking fast . 10000x faster than mysql . wuuush. #nosql"

Redis Labs

Support Portal: the Redis Labs Team overdid itself with this one – check out our shiney & new self-help Support portal: https://support.redislabs.com – let us know if you find any mistakes, missing question and any other idea you have for improvement!

Report: Redis Labs got a nice, in-depth retrospective in the new Gartner @Gartner_Inc Cool Vendors in In-Memory Computing Technologies, 2015 report by Massimo Pezzini @mpezziniGartner, Roxane Edjlali and Nick Heudecker @nheudecker (warning: you need to be a Gartner client to access the full document).

Event: Tuesday, April 21st #NYCSQL – "Using Redis to Create a Blazing Fast Mobile App" – free signup at: http://www.meetup.com/mysqlnyc/events/221681071/?action=detail&eventId=221681071

Questions?  Feedback?  Anything you want to share?  Email or tweet me – I'm highly available 🙂

This newsletter was produced and distributed by Redis Labs, Inc.
Redis Labs, Inc. 700E El Camino Real, Suite 170, Mountain View, CA 94041

Archive | Subscribe | Follow on Twitter