So if we just use the code out of libmemcached we get both approaches (and a
couple of additional ones as well).
Cheers,
-Brian
On May 4, 2011, at 12:44 AM, Henrik Ingo wrote:
> Hi
>
> I noticed there are new blueprints for libdrizzle sharding functions
> on launchpad
> https://blueprints.launchpad.net/drizzle/+spec/libdrizzle-sharding-phase1
>
> It mentions the ketama consistent sharding technique commonly used
> with memcached. I don't think (but I don't claim to know, so please
> comment) that this is at all applicable to Drizzle.
>
> As explained in
> http://www.mikeperham.com/2009/01/14/consistent-hashing-in-memcache-client/
> ...the point in using a consistent hashing technique is to minimize
> cache misses after re-shard. But Drizzle is not a cache. Let me
> explain:
>
> In memcached, and using naive sharding [key % num_servers], when you
> have 2 servers and add a 3rd, it means that the sharding key changes
> for all your records/objects, and all data is lost. Well, in fact 1/3
> of the keys will still map to the old server, and as you add more
> servers this number decreases to 1/4, 1/5 and so on... The point with
> using consistent hashing is to minimize cache misses, so that after
> adding servers, approximately 2/3 (and then 3/4, 4/5, and so on...) of
> the keys will still map to the old server and find the old record. But
> for the remaining 1/n fraction, the records are still lost. It is a
> cache, this is acceptable behavior., and it is very simple,
> no-maintenance solution.
>
> Drizzle is a database. So we cannot just discard 1/n of the data after
> adding a server. The data has to actually be moved from old location
> to the new ones. Consistent hashing doesn't make it any easier to know
> which data should go where, in fact it makes it harder.
>
> Imho the solutions available for Drizzle are:
>
> 1) back to naive approach (which I believe the stock memcached client
> uses). When scaling out, you just move the data record, by record into
> their correct shards. I think MySQL Cluster does something similar.
> The main drawback here is that if the sharding key doesn't result in
> an even spread of data, some shards are full and some empty and you
> cannot do much about it.
>
> 2) virtual buckets.
> - You start with 1 server. There can already be data in the database.
> - You divide your data into N virtual shards. N >> max number of
> shards you'll ever have. Say N=10k or more. (Ask Facebook :-)
> - At this point all data is still physically in one and the same InnoDB table.
> - When scaling out, you add more servers and move virtual buckets one
> by one to new servers.
> - You need to maintain a mapping from virtual bucket to actual
> Drizzle instances. All clients and servers need to agree on this. This
> could be a system table on one or all Drizzle instances.
> - you can move virtual buckets back and forth to re-balance your data.
>
> In both 1 and 2 the act of moving data is complicated, it has to
> happen somehow "atomically":
> - clients use old shard layout
> - copy data to new shards
> - keep in sync old shards and new shards
> - start using new shard layout
> - discard moved data from old shards
>
> henrik
>
>
>
> --
> [email protected]
> +358-40-8211286 skype: henrik.ingo irc: hingo
> www.openlife.cc
>
> My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559
>
> _______________________________________________
> Mailing list: https://launchpad.net/~drizzle-discuss
> Post to : [email protected]
> Unsubscribe : https://launchpad.net/~drizzle-discuss
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
