there's the document http://redis.io/topics/cluster-spec about Redis Cluster specs -- AFAICS there's neither a time stamp, nor any kind of version of this document.
As Redis 2.6 was released recently, I'm pretty excited what* *the *current* state on this issues is?
On Wednesday, October 31, 2012 3:17:49 AM UTC+9, Timo Schoeler wrote:
> Hi,
> there's the document http://redis.io/topics/cluster-spec about Redis > Cluster specs -- AFAICS there's neither a time stamp, nor any kind of > version of this document.
> As Redis 2.6 was released recently, I'm pretty excited what* *the *current > * state on this issues is?
> On Wednesday, October 31, 2012 3:17:49 AM UTC+9, Timo Schoeler wrote:
>> Hi,
>> there's the document http://redis.io/topics/cluster-spec about Redis >> Cluster specs -- AFAICS there's neither a time stamp, nor any kind of >> version of this document.
>> As Redis 2.6 was released recently, I'm pretty excited what* *the * >> current* state on this issues is?
> there's the document http://redis.io/topics/cluster-spec about Redis Cluster
> specs -- AFAICS there's neither a time stamp, nor any kind of version of
> this document.
> As Redis 2.6 was released recently, I'm pretty excited what the current
> state on this issues is?
Hello Timo,
the Redis Cluster specification is not really a "specification" in the
proper strict sense as "get me the specification, I can implement it".
There are a number of holes that must be filled, not much, but the
evil is in the details.
A lot of those unspecified points are actually sometimes *already*
implemented in the unstable branch, other are discussed, and a lot
more will be simply discovered as the implementation gets more
complete / mature.
So what we have *for now* in the unstable branch about Cluster?
1) Gossip to propagate information about the cluster, to link every
node with each other.
2) Gossip to propagate information about what node is responsible for
what hash slot.
3) Redirections. Node can redirect you to the right node if you ask a
question they can't reply to.
4) Atomic keys migration, that is the base of the resharding.
5) Failure detection. It is possible that this will get reworked using
experiences from Sentinel. Sentinel failure detection is probably
better already.
6) The user space tool to manage the cluster is a work in progress,
but can already do a "toy resharding" operation.
So that's the current state, but the good news is, Cluster and
Sentinel will be my main goals in the next months, and I want to bring
Cluster to beta-quality ASAP. I'll focus a lot into it because at this
point with Redis 2.6 we have a project that's pretty mature compared
to the past, and I can't see other big features apart form Sentinel
and Cluster to say, ok, let's block the development of these two
features and get XYZ ready instead. I'm also pretty confident we'll
stick with our single-thread-serves-all design for time to come, and
use Cluster to distribute Redis when there is need to use multiple
cores. Basically this means that in the Redis philosophy the approach
could be "another core or another computer for me is the same". I can
change idea, but *after* I'll see how Cluster will perform in this
regard :-)
Cheers,
Salvatore
-- Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org
Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter
> On Tue, Oct 30, 2012 at 7:17 PM, Timo Schoeler > <timothy....@googlemail.com <javascript:>> wrote: > > Hi,
> > there's the document http://redis.io/topics/cluster-spec about Redis > Cluster > > specs -- AFAICS there's neither a time stamp, nor any kind of version of > > this document.
> > As Redis 2.6 was released recently, I'm pretty excited what the current > > state on this issues is?
> Hello Timo,
> the Redis Cluster specification is not really a "specification" in the > proper strict sense as "get me the specification, I can implement it". > There are a number of holes that must be filled, not much, but the > evil is in the details.
> A lot of those unspecified points are actually sometimes *already* > implemented in the unstable branch, other are discussed, and a lot > more will be simply discovered as the implementation gets more > complete / mature.
> So what we have *for now* in the unstable branch about Cluster?
> 1) Gossip to propagate information about the cluster, to link every > node with each other. > 2) Gossip to propagate information about what node is responsible for > what hash slot. > 3) Redirections. Node can redirect you to the right node if you ask a > question they can't reply to. > 4) Atomic keys migration, that is the base of the resharding. > 5) Failure detection. It is possible that this will get reworked using > experiences from Sentinel. Sentinel failure detection is probably > better already. > 6) The user space tool to manage the cluster is a work in progress, > but can already do a "toy resharding" operation.
> So that's the current state, but the good news is, Cluster and > Sentinel will be my main goals in the next months, and I want to bring > Cluster to beta-quality ASAP. I'll focus a lot into it because at this > point with Redis 2.6 we have a project that's pretty mature compared > to the past, and I can't see other big features apart form Sentinel > and Cluster to say, ok, let's block the development of these two > features and get XYZ ready instead. I'm also pretty confident we'll > stick with our single-thread-serves-all design for time to come, and > use Cluster to distribute Redis when there is need to use multiple > cores. Basically this means that in the Redis philosophy the approach > could be "another core or another computer for me is the same". I can > change idea, but *after* I'll see how Cluster will perform in this > regard :-)
> Beauty is more important in computing than anywhere else in technology > because software is so complicated. Beauty is the ultimate defence > against complexity. > — David Gelernter
> Thanks a lot, Salvatore, that did quite shed some light on open questions > of mine. I appreciate your answer very much!
> Best,
> Timo
> Am Donnerstag, 1. November 2012 19:55:48 UTC+1 schrieb Salvatore > Sanfilippo:
>> On Tue, Oct 30, 2012 at 7:17 PM, Timo Schoeler >> <timothy....@googlemail.com> wrote: >> > Hi,
>> > there's the document http://redis.io/topics/cluster-spec about Redis >> Cluster >> > specs -- AFAICS there's neither a time stamp, nor any kind of version >> of >> > this document.
>> > As Redis 2.6 was released recently, I'm pretty excited what the current >> > state on this issues is?
>> Hello Timo,
>> the Redis Cluster specification is not really a "specification" in the >> proper strict sense as "get me the specification, I can implement it". >> There are a number of holes that must be filled, not much, but the >> evil is in the details.
>> A lot of those unspecified points are actually sometimes *already* >> implemented in the unstable branch, other are discussed, and a lot >> more will be simply discovered as the implementation gets more >> complete / mature.
>> So what we have *for now* in the unstable branch about Cluster?
>> 1) Gossip to propagate information about the cluster, to link every >> node with each other. >> 2) Gossip to propagate information about what node is responsible for >> what hash slot. >> 3) Redirections. Node can redirect you to the right node if you ask a >> question they can't reply to. >> 4) Atomic keys migration, that is the base of the resharding. >> 5) Failure detection. It is possible that this will get reworked using >> experiences from Sentinel. Sentinel failure detection is probably >> better already. >> 6) The user space tool to manage the cluster is a work in progress, >> but can already do a "toy resharding" operation.
>> So that's the current state, but the good news is, Cluster and >> Sentinel will be my main goals in the next months, and I want to bring >> Cluster to beta-quality ASAP. I'll focus a lot into it because at this >> point with Redis 2.6 we have a project that's pretty mature compared >> to the past, and I can't see other big features apart form Sentinel >> and Cluster to say, ok, let's block the development of these two >> features and get XYZ ready instead. I'm also pretty confident we'll >> stick with our single-thread-serves-all design for time to come, and >> use Cluster to distribute Redis when there is need to use multiple >> cores. Basically this means that in the Redis philosophy the approach >> could be "another core or another computer for me is the same". I can >> change idea, but *after* I'll see how Cluster will perform in this >> regard :-)
>> Beauty is more important in computing than anywhere else in technology >> because software is so complicated. Beauty is the ultimate defence >> against complexity. >> — David Gelernter
<timothy.schoe...@googlemail.com> wrote:
> Hi again, however, I'm still searching for kind of 'matrix' to see what
> features are really implemented and 'production ready' in 2.6...
In 2.6 there is almost no cluster, with the exception of the following commands:
DUMP, MIGRATE, RESTORE, that are inside 2.6 and are production ready.
Cheers,
Salvatore
-- Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org
Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter
> Beauty is more important in computing than anywhere else in technology > because software is so complicated. Beauty is the ultimate defence > against complexity. > — David Gelernter
