On Mon, Apr 4, 2011 at 6:20 PM, Stewart Smith <[email protected]> wrote:
> On Fri, 25 Mar 2011 02:00:44 +0530, Anurag Priyam <[email protected]>
> wrote:
>> Have not yet thought of it implementation, or API wise. It would be
>> great however to have some general feedback on it.
>
> I would think it'd appear something like:
> - here's where to get sharding information from
> - connect to a shard key
> (this would get a connection to whatever server is needed)
And that exactly is what I am trying to do with vbuckets.
A pseudocode implementation would be:
shard = get_shard(key)
node = get_node(key) #node probably translates to drizzle_con_st
result = query(node, query)
Don't directly map data to the server. Lets map it to intermediate
virtual nodes (here, vbuckets). And then map those virtual nodes to
actual nodes.
get_shard returns the sharding information. It just returns an index
into some another table that maps these vbuckets to actual server. Its
implementation can be anything. Its a blanks slate. This is where I
want to couple libhashkit
uint_32 get_shard(key){
return md5(key) % NO_OF_SERVER;
// return (my_random(5));
// return my_own_hash(key)
// return ketama(key)
}
Where ketama() would return the id of a virtual server. And the
vbucket table, would make sure that each virtual node actually maps to
a real node.
This looks to me inherently pluggable, flexible (that I have been
crying about in all my mails :P). The entire ideas was to highlight a
two stage map, and not vbuckets.
--
Anurag Priyam
http://about.me/yeban/
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
