Redis 2.4 will be released tomorrow
feedproxy.google.com
feedproxy.google.com
* Specially encoded sorted sets, now small sorted sets will use little memory.
* Native persistence of specially encoded data types (ziplists, zipmaps,intsets). Many data sets will be saved and loaded an order of magnitude faster.
* Variadic versions of commands: SADD, HDEL, SREM, ZREM, ZADD, L/RPUSH.
* Jemalloc support (enabled by default for Linux build) in order to avoid fragmentation issues.
* Reduced memory usage while saving.
* More info fields (peak memory, fork time, ...)
* OBJECT command for objects introspection.
* CLIENT command for clients introspection.
* Non blocking slave -> master connection.
* Better redis-cli connection handling. New redis-cli features.
* Better redis-benchmark, now able to benchmark user provided commands.
* Colorized Make.
* VM deprecated. Still supported but with a big warning... don't use it.
* Many speed optimizations and bug fixes.
If you're interesting in reading more, there's some good discussion at http://news.ycombinator.com/item?id=2606096
Just a big confused about what the best-practice is moving forward for bigger-than-memory data sets.
Personally, I'm using Redis right now for queueing and API request rate limiting. The portion of my data that's larger than memory is in MySQL. This is working pretty well.
If redis wants to focus on ultra-fast/in memory I can take advantage of that in the right ways. Just wanted to make sure I understood the constraints correctly.
Just don't plan to keep anything important in it for very long. It's not even a great idea for queuing anything important as you're better of logging or using transactions for things that might cost you money if they fail.
Personally, I think it's the memcached I always wanted. :)
1) with AOF you have innodb-level durability. 2) with replication you can do your HA setups. 3) RDB files are self-contained files holding all the dataset that can be copied and backed-up while Redis is running. 4) with the upcoming cluster you can have fault tolerance without too much problems, but for this there is to wait this fall.
After seeing some pain that is required to resuscitate Redis from the persisted files if it goes down, I was wary of relying on that persistence.
I'm pretty excited about the cluster functionality. At my current company sadly I'm working with big data so I can't really use Redis as a main backing store, but it's always in my head for personal projects.
Scripting is definitely the feature I'm waiting for.