Hello Julien, the cluster and diskstore are completely different projects from the point of view of priority: Redis Cluster is all I'm doing every day more or less, but I stop from time to time in order to focus also on 2.4 since the cluster release date is too far (later this summer) to block everything else in the meantime: we need to provide something to the user at the same time we develop the cluster.
Diskstore is just an exercise for now. Likely we'll ship 2.4 that is an improved version of 2.2. Then Redis 3.0 that is 2.4 + cluster and other things. Later if even diskstore will be good enough, we'll ship it, but it is possible that we'll mark diskstore as "off topic".
About Redis Cluster, it is no longer into a private branch. It is into unstable, and you can even play with it, check the latest antirez.com blog posts for instructions. Currently I'm designing the second layer, that is the resharding and how master-slave nodes interact. It does not need much coding, but requires to get the details right now that we have a base.
You'll see something about Redis Cluster soon.
About scripting, don't think that every blog post I do means I'll spend a lot of time on it. What will happen is that in the following weeks at some time I'll send something like one or two mornings of work to get an alpha version with scripting and put it into a topic branch, post a message on the mailing list and a blog post. Everything else will wait for the later times.
I've the attitude of talking a lot, at the point the development of Redis is almost completely a public process.
I also change ideas often, that I think is a good idea, as to go forward without reconsidering what you are doing is not good. But this does not means that the development of Redis is a complex path that goes forward and backward, we actually are trying since Redis 2.2 to provide continuously updates not about features but about the quality of the implementation.
A more precise view of the actual development path can be seen looking at the 2.4 and unstable branches commit log messages.
I'm quite surprised that Diskstore isn't more concrete than that - were there unforseen problems with it? Or is the focus going to stay on in memory databases?
As a happy Redis user, the VM is the only sore spot - it seems like it should be possible to get Redis like performance on cached keys and still be able to store a long tail of data on the same server.
The problem is exactly the one with VM: I believe that likely disk will suck but for a specific work load, that is, extremely biased working set + mostly reads. But this is exactly the use case of on disk DBs anyway, that are doing a lot work to work well in this use case, why should we also enter this business? There should be space for everybody, I'll be very happy if we'll do our work well, that is, the in memory data structure server :)
BUT I did not stop experimenting, we'll return on this, but in the form of diskstore and as on disk allocators using mmap() that is another thing I'm playing with.
Diskstore is just an exercise for now. Likely we'll ship 2.4 that is an improved version of 2.2. Then Redis 3.0 that is 2.4 + cluster and other things. Later if even diskstore will be good enough, we'll ship it, but it is possible that we'll mark diskstore as "off topic".
About Redis Cluster, it is no longer into a private branch. It is into unstable, and you can even play with it, check the latest antirez.com blog posts for instructions. Currently I'm designing the second layer, that is the resharding and how master-slave nodes interact. It does not need much coding, but requires to get the details right now that we have a base.
You'll see something about Redis Cluster soon.
About scripting, don't think that every blog post I do means I'll spend a lot of time on it. What will happen is that in the following weeks at some time I'll send something like one or two mornings of work to get an alpha version with scripting and put it into a topic branch, post a message on the mailing list and a blog post. Everything else will wait for the later times.
I've the attitude of talking a lot, at the point the development of Redis is almost completely a public process. I also change ideas often, that I think is a good idea, as to go forward without reconsidering what you are doing is not good. But this does not means that the development of Redis is a complex path that goes forward and backward, we actually are trying since Redis 2.2 to provide continuously updates not about features but about the quality of the implementation.
A more precise view of the actual development path can be seen looking at the 2.4 and unstable branches commit log messages.