Well, thanks, but I'm afraid using UUID's (even with hex compression) is kind of a suicide, when it comes to performance. This is a good summary about the issues: http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
So, some kind of auto_increment or sequencing must be the optimal solution here. On Mon, Sep 13, 2010 at 2:05 PM, Fish Kungfu <fish.kun...@gmail.com> wrote: > I had some coffee and realized that actually, using a UUID might be > something to look at. There have been quite a few discussions about using > a > UUID as a unique id and it does have some gotchas. Just Google: mysql uuid > Have a great day.... > ~~Fish~~ > > > > > On Mon, Sep 13, 2010 at 7:30 AM, Fish Kungfu <fish.kun...@gmail.com> > wrote: > > > I could be way off here, but how about letting your unique id be a > > calculated column of the the server's MAC address concatenated with an > > auto-increment id column? > > > > I hope this helps... > > ~~Fish~~ > > > > > > On Mon, Sep 13, 2010 at 7:26 AM, Johan De Meersman <vegiv...@tuxera.be > >wrote: > > > >> Hmm, that's a very interesting scenario, indeed. > >> > >> One bad connection will break the chain, though, so in effect you'll be > >> multiplying the disconnecting rate... > >> > >> I think you'd be better of with a star topology, but MySQL unfortunately > >> only allows ring-types. This is gonna require some good thinking on your > >> part :-) > >> > >> On Mon, Sep 13, 2010 at 12:28 PM, Kiss Dániel <n...@dinagon.com> wrote: > >> > >> > This is actually more for failover scenarios where databases are > spread > >> in > >> > multiple locations with unreliable internet connections. But you want > to > >> > keep every single location working even when they are cut off from the > >> > other > >> > databases. The primary purpose is not load distribution. > >> > > >> > On Mon, Sep 13, 2010 at 12:03 PM, Johan De Meersman < > vegiv...@tuxera.be > >> > >wrote: > >> > > >> > > > >> > > > >> > > On Sun, Sep 12, 2010 at 9:45 PM, Kiss Dániel <n...@dinagon.com> > >> wrote: > >> > > > >> > >> offset + increment thingy is good if you know in advance that > you'll > >> > have > >> > >> a > >> > >> limited number of servers. But if you have no idea that you will > have > >> 2, > >> > >> 20, > >> > >> or 200 servers in your array in the future, you just can't pick an > >> > optimal > >> > >> > >> > > > >> > > What benefit do you think you will reap from that many masters ? > Don't > >> > > forget that every write still has to be done on every server, so > >> you're > >> > not > >> > > actually distributing that load; while for reads you only need > simple > >> > > slaves. > >> > > > >> > > > >> > > -- > >> > > Bier met grenadyn > >> > > Is als mosterd by den wyn > >> > > Sy die't drinkt, is eene kwezel > >> > > Hy die't drinkt, is ras een ezel > >> > > > >> > > >> > >> > >> > >> -- > >> Bier met grenadyn > >> Is als mosterd by den wyn > >> Sy die't drinkt, is eene kwezel > >> Hy die't drinkt, is ras een ezel > >> > > > > >
