* Redis Cluster: a distributed implementation of a subset of Redis.
    * New "embedded string" object encoding resulting in less cache
      misses. Big speed gain under certain work loads.
    * AOF child -> parent final data transmission to minimize latency due
      to "last write" during AOF rewrites.
    * Much improved LRU approximation algorithm for keys eviction.
    * WAIT command to block waiting for a write to be transmitted to
      the specified number of slaves.
    * MIGRATE connection caching. Much faster keys migraitons.
    * MIGARTE new options COPY and REPLACE.
    * CLIENT PAUSE command: stop processing client requests for a
      specified amount of time.
    * BITCOUNT performance improvements.
    * CONFIG SET accepts memory values in different units (for example
      you can use "CONFIG SET maxmemory 1gb").
    * Redis log format slightly changed reporting in each line the role of the
      instance (master/slave) or if it's a saving child log.
    * INCR performance improvements.

WARNING: Redis 3.0 is currently a BETA not suitable for production environments.

Looking forward to seeing it taken apart by aphyr.

Congrats to Salvatore and the rest of the redis committers!

As far as I can tell, most of the advantages of Redis come from the fact that it's all held in memory and so access is fast. Is networked access to other parts of the cluster quick enough that it is quicker than storing the data on one computer, partly on disk? When would one want to use a Redis cluster rather than something stored on-disk and cached in memory?

    In Redis Cluster nodes don't proxy commands to the right
    node in charge for a given key, but instead they redirect
    clients to the right nodes serving a given portion of the
    key space.

    Eventually clients obtain an up to date representation 
    of the cluster and which node serves which subset of 
    keys, so during normal operations clients directly 
    contact the right nodes in order to send a given command.

    Because of the use of asynchronous replication, nodes 
    does not wait for other nodes acknowledgment of writes 
    (if not explicitly requested using the WAIT command).

Being memory-based was simply a feature but not necessarily something that set it apart: Memcached had that area pretty well locked down for being a blazing fast key-value store. And then Membase was basically memcached + persistence and clustering. Now Redis has clustering too!

   Maybe it works great from day one,
   maybe it will need a few more iterations, 
   and possibly with 3.2 we'll improve support for many stuff, 
   but my guess is that Redis 3.0.0 today, in some way, changes what Redis is.

"p.s. no April fools here. 1 year ago I released HyperLogLog, today 3.0.0, just to contrast with some shit done this April fool lameness."

http://antirez.com/news/75

You’re totally within your rights here. I just beg you to consider the audience.

Now with embedded strings there is a special kind of string objects that instead use a single allocation for both the object structure and the string itself. This is slightly more memory efficient, but especially, improves memory locality a lot, so basically everything uses string objects (string types, or aggregate data types large enough to use string objects as values of the collection), will perform better.

Those special strings are used only for small strings (the majority in most work loads).

Anyone interested in trying it out, or contributing, you can see the project here: https://github.com/renatomassaro/asyncio-redis-cluster

Edit: as for blocking requests, redis-py-cluster is an awesome lib that provides cluster support over the traditional redis-py client.

Depending on what you need your database for, there are some that perform better than others. You can check this site for comparisons: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

It's not even close to the same thing as Redis except superficially.

The key/value part of Redis is just the beginning. The values themselves can be of several different types that allow for a lot more flexibility in how you store and query data.

Memcached is just a cache. Don't store anything there you can't lose.

>In order to achieve its outstanding performance, Redis works with an in-memory dataset. Depending on your use case, you can persist it either by dumping the dataset to disk every once in a while, or by appending each command to a log.

At a previous job people started using Redis thinking it was a fast in-memory data store. It turned out we had accumulated tens of thousands of records.

I haven't measured, but I doubt it's much faster than Postgres. It does have other nice features. I like using the expiring records for caching.

[0] http://hyperdex.org/solutions/

    p.s. no April fools here. 1 year ago I released HyperLogLog, today 3.0.0, just to contrast with some shit done this April fool lameness.

http://www.mongodb.com/blog/post/announcing-mongodb-30

Like, stunnel: https://www.stunnel.org/index.html and how to setup (Re: MySQL over stunnel) http://linuxgazette.net/107/odonovan.html

https://www.varnish-cache.org/docs/trunk/phk/ssl.html

upd.: don't get me wrong, Redis is my favorite DB, really. But better to be objective.

Implementing SSL is easy. Implementing SSL correctly is very difficult, and you probably won't find out you did it wrong for a long time, if ever.

I'm happy that redis doesn't implement SSL, it just shows that they are prioritizing relevant features.

Also solutions like stunnel create a separate process that has to be managed. If I have one for redis, and then one for something else it is harder to tell them apart, because both will be named stunnel.