The one thing that puts me off Redis sharding is that it breaks cross-key operations, like sunion and sinter. I get a lot of use out of those.<p>I wonder if it would make sense for Redis to support cross key operations where you can tell it another Redis server to retrieve the keys from?<p><pre><code> # Connect to redis server 1
r = Redis('server1.dev', 6379)
# Tell it to perform an intersection with a key on server 2
r.sinterremote('my-key', 'server2.dev:6379/remote-key')
# Same, but store the result on server 1
r.sinterremotestore('local-storage-key', 'my-key', 'server2.dev:6379/remote-key')</code></pre>
So if I understand correctly this is just a neat trick using existing Redis features (and relying on it's low memory footprint) to easily implement sharding today?<p>But in an ideal world (Redis cluster) you would run a single node per machine, and Redis would automatically handle sharding, replication etc?
See also: How we've been doing this in memcached and membase<p><a href="http://dustin.github.com/2010/06/29/memcached-vbuckets.html" rel="nofollow">http://dustin.github.com/2010/06/29/memcached-vbuckets.html</a>
Process migration (moving instance) is not easy. In the simplest level, you still want to have some kind of naming/binding scheme such that the migration will be transparent in application layer (well, DNS, maybe). Besides, with your proposal in "Moving Instance", there are still race conditions. For example, when you "slaveof no one"ed on the new instance, which instance (old or new) will handle the incoming request? It seems to me either way, you will end up in an inconsistent state (or handle some request faultily). Well, I need to lookup the underlying mechanism of "slaveof" to be confident about that, but it is worth to point out.<p>I'd like to be able to use Redis Cluster as soon as it is available, here is my question: how can I help? Recently, I want to start write some script for rehashing, but there are some problems, namely, I cannot just "get/set" everything (e.g., I cannot "get/set" a list with some serialized format). Do you have recommended way of doing that?
How about just using consistent hashing? <a href="http://en.wikipedia.org/wiki/Consistent_hashing" rel="nofollow">http://en.wikipedia.org/wiki/Consistent_hashing</a><p>In this scheme, you can add and remove servers without mving all your data.<p>There is apparently a memcached plugin to do this: <a href="http://www.mikeperham.com/2009/01/14/consistent-hashing-in-memcache-client/" rel="nofollow">http://www.mikeperham.com/2009/01/14/consistent-hashing-in-m...</a>
Personally, I would prefer to hash my fields like this:<p>1. Hash each field in the key in some fashion<p>2. Concatenate the hashes, for example implode(".", $hashes)<p>3. Now you've got a point in the space of all possible concatenated hashes. On each client, have a partition like this for each key:<p>["", "abf34.9f8c7.92833", ...]<p>4. go through the partition and find the last point that is smaller than your point. That point maps to your shard.<p>5. Monitor your machines. If one of your shards becomes too full, or too much action is going, SPLIT IT. You do this simply by replicating the data to one or more new shards (like it says in the article) introducing one or more points in the partition right after the point mapping to the shard. Point them to the new shards. And update all the clients!<p>That's all
Greg