Some thoughts about Redis

http://vadymlotar.blogspot.com/2013/06/some-thoughts-about-redis.html

http://www.slideshare.net/renatko/couchbase-performance-benchmarking

http://redis.io/topics/benchmarks

雖然有點舊，不過還是可以借鑒，按需求尋找合适技術是首要

In this article I would like to shed light on what the Redis is. I will also explain when you may want to use it from my opinion and say few words about pros and cons of Redis.

I met with this storage few months ago during solving the task which required from me to use a distributed cache. Choosing the key/value store was not so simple task as I thought, because of our specific needs. Besides that the main requirements were stability, availability, scalability and, of course, speed (>60 000 ops/sec). Providing a simple and understandable API and not being a "monster" like MongoDB would also be a plus. So we decided to choose the winner from the following list: Couchbase (Couchbase/Memcached buckets), Memcached, Hazelcast and Redis.

We started our investigation from the Hazelcast, because we've been already using it in many other projects where it demonstrates pretty good results. We wrote simple test application trying to load 20 millions objects to the cache with 10 threads and after putting 7-8 millions objects Hazelcast has gone crazy. Sometimes it happened after loading 10 millions objects, but keeping in mind that we have to store up to 50 millions objects in storage, we decided to switch to the next candidate.

Then we were trying to see how both data buckets provided by Couchbase are working. From the first look Couchbase is awesome. It has a lot of different options like clustering, auto-failover, map/reduce and persistence for Couchbase buckets, asynchronous operations and many other things. Sounds good, yeah? Then we run our test and it quickly put everything in its place. The Couchbase Admin page showed incredible numbers for remote connection 50 000-60 000 ops/sec and >100 000 ops/sec for local connection, however only 40-60% of all data we were trying to load to the bucket was there in the end of the test. All other operations failed because of timeout. The Couchbase experts explained it by the fact that we didn't check the result of set/add operations. Yes, it was true, because when you add this check it means you are using synchronous operations instead of asynchronous and performance degradation is very impressive (<1000 ops/sec for remote connection and 20 000 - 30 000 ops/sec for local connection). So, taking into account that our distributed cache must handle huge amount of operations during bulk load correctly and in a very fast way, we decided to find luck somewhere else.

The next step was to choose between Memcached and Redis. It was our last hope... 

Memcached - free & open source, high-performance, distributed memory object caching system - was developed very long time ago and is very popular till now. It has only one disadvantage - it's a simple key/value store without an ability to work with different data structures. So, if you know that you won't need to store, for example, Sorted Set in the cache for sure, you might want to choose Memcached. Redis is a little bit more than that...

Thus, Redis became our choice and, fortunately, it meets all our needs. 

Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.

You can do "almost" the same operations with strings, lists, sets as you usually do working with simple String, ArrayList or HashSet in Java. Unfortunately, "almost" means not really, pardon the pun. For example, there is no ability to check whether the list contains some element or not. Strange? Yes, it's very strange. You wanna another "funny" example? Well, it's simple - you can get a range of elements from the sorted set but cannot do that using a regular one. Let's imagine that you don't want to use different data structures and want to use Redis as a simple key/value store, like a simple map. Another surprises will appear, be sure. For example it's not so simple to iterate over this map or get the ranges. I would say that it's even impossible to do without creating an additional key where you will store a list or a set of keys. What do you think about ability to specify the DB not by name and just by index? Why it's like that? - I have no idea. You can read about all operations provided by Redis here.

But let's finish telling bad things about Redis, because I have a feeling that you already don't like it. The good news are - it's stable, you can configure master-slave communication. It's very fast - some benchmarks say that it's even faster than memcached, but I would say that it's pretty much the similar. If you have enough memory you can implement missed functionality by creating additional lists, sets and so on. It also has a very good community. So basically it can do everything you might want to do with data in the cache and my suggestion is to play with it a little bit and you will understand what's what. Don't give up.