

Redis can now batch operations and execute them atomically - xal
http://groups.google.com/group/redis-db/msg/c644795685ee024f

======
orph
Of course, like everything else in Redis, this only works when all the keys in
question are located on a single host.

~~~
antirez
Yes indeed, the plan with redis-cluster is to support multi-key operations
only if all they keys hash the same (the user can enforce this by using the
special key-tags, for instance 1234.{foo} and 4567.{foo} will be guaranteed to
hash the same).

So it will be up to the application logic to make sure that all the keys that
are required to be used with multi-keys operations will be on the same node.

But what I think is that if one wants to write a really distributed and
scalable application that can use already some form of application-level
partitioning, or that can will use redis-cluster in the future, the way to go
is to just use Redis single-key atomic operations, and try to make the
application resistent against minor inconsistencies that can be calculated
before hand.

For instance in the email linked in the story we are talking about a very
common pattern. Example: for X be put in category Y it's needed to have two
sets, one is like X.categories where there is the Y category ID, and one is
Y.objects where there is the X object ID. Writing a distributed application
that is designed to scale with multiple nodes using redis-cluster or any other
solution, the best thing to do is that the application itself is able to deal
with the case of Y id being in X and X id not in Y or the contrary.

~~~
orph
Do you have a reply this redis list mail raising the limitations of client-
side sharding?

[http://groups.google.com/group/redis-
db/browse_thread/thread...](http://groups.google.com/group/redis-
db/browse_thread/thread/a0b74a92c09f9d96)

(Basically, if the key space of a server is being altered, the server needs to
know about it so as not to return false results.)

