Redis 2.4 will be released tomorrow(feedproxy.google.com)
feedproxy.google.com
Redis 2.4 will be released tomorrow
http://feedproxy.google.com/~r/antirez/~3/T3p9g6TStMc/redis-doc-fiesta-2.html
2 comments
What replaced VM? I've seen antirez saying recently that diskstore isn't necessarily the perfect replacement it was suppose to be either.
Just a big confused about what the best-practice is moving forward for bigger-than-memory data sets.
Just a big confused about what the best-practice is moving forward for bigger-than-memory data sets.
For larger-than-memory data sets, your current options seem to be either to shard your data, or to use something other than Redis. Redis doesn't pretend to be the answer to every problem, and fortunately there are a lot of options out there.
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.
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.
Though in the long run, antirez wants to implement a system whereby data structures are actually manipulated in-place on disk, which sounds pretty amazing. The main loop and memory operations would still be single-threaded, but there would be threads in the background handling the disk IO. This is post-cluster though.
Last I heard "diskstore" was also scrapped.
Thank you PJ for the clarification. I have no problem with "the right tool for the right job", just wasn't sure how to fit all the pieces together.
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.
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.
Redis is in general, just an excellent pillow to put between your API, app servers, and frontend servers and your main backing stores for various purposes.
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. :)
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. :)
You can surely use Redis as a caching solution, but if your data fits in memory you can use it as a full featured and absolutely safe database:
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.
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.
Is AOF the preferred persistence method than I take it?
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.
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.
[deleted]
Yay! on vararg SADD and ZADD.
Thanks for preemptively answering my question.
it can't swap to disk
It never really could.
no, I don't think so http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
He didn't say "it never could": he said "it never really could." The VM feature was always experimental.
If you're interesting in reading more, there's some good discussion at http://news.ycombinator.com/item?id=2606096
If you're interesting in reading more, there's some good discussion at http://news.ycombinator.com/item?id=2606096
What's happening on the scripting front? Looked at the network graph at Github, but it does not seem to work currently. There is a branch for 2.2, but not for 2.4.
Scripting is definitely the feature I'm waiting for.
Scripting is definitely the feature I'm waiting for.
Hello Balu, what happened with scripting is that it was merged into the unstable branch! So now it is part of Redis. The first stable version featuring scripting will be 2.6.
* 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.