On Tue, 5 Apr 2011 23:51:43 +0530, Anurag Priyam <[email protected]> wrote: > I am confronted with three choices here: > 1. Start with vbuckets to provide a simple abstraction to sharding and > problems in its scope that probably pop up often (do they?) when > dealing with a cluster - failure, migration of shard, and > addition/removal of nodes. Then go for a pluggable partitioning scheme > (if needed). > 2. If the idea is to include ketama for its simplicity, it seems > simple to map ketama to vbuckets. Work on vbuckets + ketama. > 3. Start with a pluggable partitioning scheme, and later take care of > failure, migration of shard, and addition/removal of nodes.
3 is certainly keeping the initial code purely in the client - which can have its advantages, especially in getting started and having something usable to show relatively quickly. slave promotion is tricky enough in itself and I would err on the side of this being way out of scope for this project. > I think a simple solution here is to answer two questions here: > 1. Decide whether a pluggable hashing scheme is even needed or not? > - My answer is no. It shouldn't be hard to create an API that would work for any sharding/hashing scheme - if there's only one implementation you work on, that's fine too (although a simple "nosharding" scheme would be good too :) you never know when somebody is going to come up with something truly spectacular :) -- Stewart Smith _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
