On Tue, 5 Apr 2011 22:58:14 +0530, Anurag Priyam <[email protected]> wrote: > Hi Stewart, > > On Mon, Apr 4, 2011 at 6:16 PM, Stewart Smith <[email protected]> > wrote: > [...] > > NDB chose 240 as the number to map to as it's quite factorable. e.g. if > > you had 2 machines, 120 partitions each. This makes going up to 240 > > machines rather easy, you just relocate a partition. > > You mean, the data is mapped to 240 partitions? What happens when you > have more than 240 nodes? I could not find anything relevant to read > on it. Any links?
generally speaking at that point you should have started with a larger number :) 240 was picked for NDB as this is huge compared to both the average number of data nodes and the total number of data nodes in a typical NDB setup. We could pick a larger number... but as default... the number of places growing to 240 shards... rather minimal. (remember, this is *excluding* any read only slaves for any of these shards). So 240 could easily map to at least 480 physical database servers (or more). > At the surface, this looks quite similar to vbucket. Data maps to a > vbucket (a partition) and any server can host that partition. To add > machines, you just relocate the vbucket. yep. > I think the big idea here is a two stage mapping. Data does not > directly map to a node, rather a virtual bucket/node/server, and that > maps to the actual server/node. yes. > > considering that machines running clients connect regularly, caching the > > sharding information on them is certainly not out of the question (it > > wouldn't be large). > > Just to be sure, by sharding information do you mean what shard does a > key map to? should have said what vBucket maps to what machine, the number of vBuckets and the list of machines. i.e. all the information needed to work out which machine to talk to. > > The mapping can also change, and could quite easily be implemented for > > moving a shard to a new machine. We'd just need a way in the server to > > return that a database is read only (attempt r/w op on a shard, get back > > "currently read only") while doing the migration. After migration, > > ideally we could use an error saying "shard has relocated" at which > > point the client could update its mapping and connect to the correct > > server. > > That seems a bit inconsistent with your liking for round-trips > reduction :). Why do we need to query a server to know if the shard > has moved or not? Client side can (or, should) hold that information. > vbucket scheme would. it should hold it, but in the event of moving a vBucket, we have to update the clients information somehow as their data structures mapping vBuckets to machines will no longer reflect reality. > Why do you want to make the entire database read/write only? Is there > anything wrong with a read, write state being associated with a data > partition (here vbucket)? that's what i was meaning - assuming the vbucket would be represented by a different schema in the db server. > > I say "database" but in future this could be CATALOG (and this would > > enforce the no-cross-shard queries rule). > > A catalog can have multiple tables. And I can have half of it on one > machine, and half of it on the other. How does it avoid > cross-shard-queries? no, not in the way we have them. CATALOG/SCHEMA/TABLE is the "path" to a DB table in Drizzle. You connect to a Catalog and once having done so, only see things in that catalog. essentially it's like a whole different DB server to the user. > > I also don't like a mechanism that would require another round trip to > > find out which server to connect to in order to run the actual query (it > > also pretty much just moves your scaling and availability problem around > > rather than solving it at all). > > vbucket does that :). yep. > Definitely :). I hope that is not a part of your signature so that I > have to say yes/no everytime :P. no, not .sig :) -- 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
