Perl and Redis

2017-02-22 10:24:05 mihai.szilagyi Guest blog posts 2 Comments

My name is Mihai and I’m a Perl developer at Evozon. I love Perl, I’ve been using it for almost 5 years now, it’s my go to language since my university days. Full disclosure, back then, in my students days I actually wanted to be a Java foot soldier. I really dodged a bullet there :)

My first experience with Perl was at the beginning of 2012, when a wonderful company offered me a tremendous opportunity (insert sarcasm here) for an internship. I’m using Perl 5, so all references in this article go to this version.

Now you might be wondering what’s my connection to Redis.

The short story is that I had to find an appropriate solution for a caching and queuing system. I did a bunch of research and ended up on Redis. It’s easy to use and it has some basic data structures already built in. I got through the documentation in an afternoon and was ready to go at it. Now here’s the long version.

One of the first things that I found, unfortunately for me, were linked lists. Linked lists were a mystery and a pain in the @#% in highschool, I never could understand them. Luckily Redis already implemented this, as linked lists are very useful if you want a fast and easy stack implementation.

Because Redis is basically a non-SQL system, it also inherits all the disadvantages and benefits that come with it. You can imagine Redis as a huge Perl hash where each element is identified by a unique ID. It also has some structure similar to the Perl (5) hash where one ID contains multiple subcategories of IDs. This is very useful if you want to store multiple data on a particular ID, usually when you want to store a complex data we serialize it in the JSON format. We don’t need to do this in Redis because we can store simple JSON values without having to serialize them.

Take this as an example: Store the following Perl hash in non-SQL.

$to_be_stored={name =>Donald, age=>70, country=U.S.} - any resemblance is purely coincidental

The classical approach would be to serialize it in JSON and then store it.

The Redis hash structure allows us to store it directly using the right Perl module. For this example I’m using Redis (module).

$Redis_con->hmset($ID,name, Donald, age,70, country,U.S.)

Redis also supports publish subscribe mechanism: “SUBSCRIBE, UNSUBSCRIBE and PUBLISH implement the Publish/Subscribe messaging paradigm where senders (publishers) are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be”.

Another interesting feature is that Redis has implemented a way to store a set. Even more, it has a sort set implementation which sorts elements by their rank and it returns the greatest/lowest  element in O(1).

It was easy to catch up with Redis because it’s similar to Perl and it also has a few Perl modules  that make working with it (as a perl developer) quite easy. It was a great experience for me and I recommend you check it out.

Which one of the structures I mentioned is optimal, in your opinion, for a queuing system?

Leave a comment


2 Comments

    Thanks for sharing this I love hearing about the first impressions and experiences people have with Redis The natural candidate data structure for a queue would be your old nemesis the List

    We explored both SSDB and Redis for implementing Delay Queue for Email in our email security product We decided to go with Redis at the end

Subscribe to our newsletter!

Make sure you never miss the interesting stories of Perl startups, apps and projects.