First impression of Redis-Cluster
Xiangrong Fang
revealed. I have some questions though:
1) Key hash slots are allocated via some hashing algorithm, right?
This means, there is no way to do sorta capacity planning e.g.
restrict the user keyspace to server 1~3, while the document keyspace
to server 4~50 (suppose there are far less users than documents in the
system) ? What I am thinking is possible network split over the WAN,
i.e. a group of redis servers in one datacenter and other clusters in
another DC...
2) What is the implication of clusters while doing cross-server data
manipulation, e.g. SINTER set1 set2, while set1 on server3 and set2 on
server6?
3) How compatible is current redis 2.0.x and the clustered redis?
Can we expect to only upgrade the client library without rewrite our
programs? Another important aspect is data format compatibility
between current and future redis. As persistence is another hot topic
besides clusters, and discussions of AOF, backup etc are on going...
Thanks a lot!
BR,
Shannon
Salvatore Sanfilippo
> Thanks to antirez's hard working, now we see the redis-cluster
> revealed. I have some questions though:
>
> 1) Key hash slots are allocated via some hashing algorithm, right?
> This means, there is no way to do sorta capacity planning e.g.
> restrict the user keyspace to server 1~3, while the document keyspace
> to server 4~50 (suppose there are far less users than documents in the
> system) ? What I am thinking is possible network split over the WAN,
> i.e. a group of redis servers in one datacenter and other clusters in
> another DC.
Hello Xiangrong,
the key slots are not allocated hashing. You can move any amount of
keys from one node to another node using "redis-iter".
Btw Redis Cluster is note designed and will never be in order to work
outside the spectrum of "well connected networks", so no WAN. It will
actually work as there is nothing not preventing from working, but is
a not-intended use :)
> 2) What is the implication of clusters while doing cross-server data
> manipulation, e.g. SINTER set1 set2, while set1 on server3 and set2 on
> server6?
You have to use hash tags in the form of set1{user0} set2{user0} in
order to make sure the keys will hash in the same slot, otherwise the
operation is not supported by the cluster. And the node will reply
with an error "-ERR keys in multi-keys command don't hash in the same
hash slot".
> 3) How compatible is current redis 2.0.x and the clustered redis?
> Can we expect to only upgrade the client library without rewrite our
> programs? Another important aspect is data format compatibility
> between current and future redis. As persistence is another hot topic
> besides clusters, and discussions of AOF, backup etc are on going...
In the first version all the commands operating on a single key will
be guaranteed to work, or multiple keys hashing to the same hash
slots. It is very unlikely that operations against multiple nodes will
be supported, like an SUNIONSTORE with keys hashing in different
nodes: even if this can be made working, it will suck performance
wise, so it's better to make the application developer aware of this
by not supporting this kind of operations.
In a second stage, also MULTI/EXEC/WATCH will work as long as the
operations will be executed against keys hashing in the same hash
slot.
Cheers,
Salvatore
--
Salvatore 'antirez' Sanfilippo
http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele
Xiangrong Fang
Thanks for your explanation. Further comments/questions:
1) Most probably Redis will be used in LAN, but I think it is
possible for us to use it over WAN. However if that is the use case,
the 2 separate DCs will be operating separately, they might be
synchronized, but only asynchronously, and never be contacted in the
same query (e.g ask to do SINTER etc.)
2) I am very interested in how to use hash tags, is there any documentation?
3) For this question, I mainly concerns the plan to improve AOF and
other aspect of redis persistence...
Thanks,
Shannon
2010/10/28 Salvatore Sanfilippo <ant...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>
>
Damian Janowski
> 2) I am very interested in how to use hash tags, is there any documentation?
It's just marking your key in a way to tell Redis which part of the
string should be used to hash the key.
So if you try to do:
SINTER foo bar
There's no guarantee that those two keys will hash to the same node.
So the atomicity cannot be guaranteed either.
Using a tag:
SINTER {qux}foo {qux}bar
You're telling Redis to only use the substring "qux" to determine the hash slot.
This is already being used in the Ruby client:
http://github.com/ezmobius/redis-rb/blob/master/lib/redis/distributed.rb#L518
Xiangrong Fang
> Using a tag:
>
> SINTER {qux}foo {qux}bar
>
> You're telling Redis to only use the substring "qux" to determine the hash slot.
This means:
1) {} is part of the key, i.e. {qux}foo is NOT same as quxfoo,
2) {tag} can appear anywhere in the key, i.e. {qux}foo and foo{qux}
can achieve the same sharding effects. i.e. they hash to the same slot
(i.e. the position of the tag does NOT matter) ??
3) It is NOT a feature of any client library, but the redis-server, right?
Thank you!
Shannon
Ezra Zygmuntowicz
It is not a feature of the redis-server. As far as I know the only client lib that fully supports it is redis-rb the ruby client. And all that it does is look for /\{(.*)\}/ in the keyname so anything between curly braces is what is used to hash the key to the server. Usually when you use multiple redis servers the redis-rb client runs a CRC hash on the key to get an integer and then looks up that integer on the consisten hash ring, it then moves clockwise until it hits the first redis-server and thats where that key lives. If you include "{foo}bar" or "bar{foo}" it doesn't matter the order, the CRC hash is only run on the foo inside the curly braces and the other chars in the key name are basically ignored as far as looking up the key on the hash ring to find which redis-server owns that key.
basic logic is this:
def lookup_node_for(key)
if key =~ /\{(.+?)\}/
key = $1
end
node_for(key)
end
Cheers-
Ezra Zygmuntowicz
ezmo...@gmail.com
Damian Janowski
> This means:
>
> 1) {} is part of the key, i.e. {qux}foo is NOT same as quxfoo,
Yes.
> 2) {tag} can appear anywhere in the key, i.e. {qux}foo and foo{qux}
> can achieve the same sharding effects. i.e. they hash to the same slot
> (i.e. the position of the tag does NOT matter) ??
Salvatore should clarify, although for clarity I would suggest you
always prepend.
> 3) It is NOT a feature of any client library, but the redis-server, right?
Currently it's implemented in the client side because Redis doesn't
know about sharding. But from the presentation I assume that this
would be a feature of the Redis cluster for sure – ie clients will not
need to have this logic.
Xiangrong Fang
Regards,
Shannon
2010/10/29 Damian Janowski <djan...@dimaion.com>:
Salvatore Sanfilippo
if a key does not contain a sequence of { and then }, it is hashes as
a whole. Example "foobar" => crc16("foobar") % 4096
if a key contains {} somewhere, just the first occurrence of such
sequence is hashed, all the rest of the key discarded:
foo{bar} => crc16("bar") % 4096
foo{bar}zap{lame} => crc16("bar") % 4096
The first {} may appear everywhere.
Both the server and the client need to implement this IF the client is
smart and will cache the "hash slot" => "node" table.
The server obviously need to point you to the right instance if the
client is asking the wrong node, so of course it implements it.
The dummy client does not need to implement this: will try a random
node and will follow the advice.
The smart client does need to implement this: will hash the key and
will consult the nodes table.
Cheers,
Salvatore
--
Pedro Melo
On Sat, Oct 30, 2010 at 11:34 AM, Salvatore Sanfilippo
<ant...@gmail.com> wrote:
> Both the server and the client need to implement this IF the client is
> smart and will cache the "hash slot" => "node" table.
This table will be available with a Redis command, right?
Thanks,
--
Pedro Melo
http://www.simplicidade.org/
xmpp:me...@simplicidade.org
mailto:me...@simplicidade.org
Salvatore Sanfilippo
Inviato da iPhone