Hi Anurag,
On 24/03/11 19:49, Anurag Priyam wrote:
On Wed, Mar 23, 2011 at 2:49 PM, Andrew Hutchings
<[email protected]> wrote:
[...]
No, in almost every app I have ever worked on the app is passing something
like:
SELECT * FROM t1 WHERE pkey = $somevalue;
In essence you shard on primary key, and its the application
developer's responsibility to choose an appropriate primary key. If
you don't query based on that key the advantages of sharding is lost
as you will have to query each node. IMO, any kind of partitioning is
advantageous only if you stick to a particular query model.
In fact this is similar to what MySQL Cluster does. On a primary key
equality lookup it knows exactly which node has the data due to a
hashing algorithm. When a secondary index is used all nodes get the
query and then a single node collects and sends back the result.
Although this is way beyond scope of what we are trying to achieve I think.
The flaw comes with inserts relying on auto_increment, but I don't know of
many scaling apps that use auto_increment. Would also be interested if
someone came up with a workaround for this (I'm guessing a proxy?)
To auto_increment you would have to know the last value which could be
residing on any shard. IMO, neither pinging all the shards won't do
any good, nor storing the state at a central point. Would it not be
just better to discourage auto_increment practice in a sharded
environment?
I think certainly the use case for this would be no auto-inc. Although
there are several work arounds possible in the future.
Kind Regards
--
Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
