I may have missed what you are trying to do here. NoSQL is really a bad name
and should really be renamed to NoREL instead. NoSQL implementations are not
used just because of limitations of traditional RDBMS when it comes to sheer
traffic volume, they are also used because they scale horizontally
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
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,
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
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.bewrote:
Hmm, that's a very
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
Hell, yeah. :)
Actually, the ID system I described below works quite well according to my
tests. I feel very comfortable with it both from primary key size and
dynamically increasable database number point of views.
What I actually don't like in it is the concatenated unique ID (ID + SID)
pairs.
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
-Original Message-
From: Kiss Dániel [mailto:n...@dinagon.com]
Sent: Sunday, September 12, 2010 1:47 PM
To: mysql@lists.mysql.com; replicat...@lists.mysql.com
Subject: Unique ID's across multiple databases
Hi,
I'm designing a master-to-master replication architecture.
I wonder what the
-Original Message-
From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De
Meersman
Sent: Monday, September 13, 2010 7:27 AM
To: Kiss Dániel
Cc: Max Schubert; mysql@lists.mysql.com; replicat...@lists.mysql.com
Subject: Re: Unique ID's across multiple databases
Hmm
-Original Message-
From: Kiss Dániel [mailto:n...@dinagon.com]
Sent: Monday, September 13, 2010 11:49 AM
To: Jerry Schwartz
Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
replicat...@lists.mysql.com
Subject: Re: Unique ID's across multiple databases
Well, not exactly.
I do
Schubert; mysql@lists.mysql.com;
replicat...@lists.mysql.com
Subject: Re: Unique ID's across multiple databases
Well, not exactly.
I do not own all the databases. Some of them are placed at customers, some
of them are at my data warehouse. So, neither NAS or Fibre Channel is a
solution
Schwartz
Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
replicat...@lists.mysql.com
Subject: Re: Unique ID's across multiple databases
Well, not exactly.
I do not own all the databases. Some of them are placed at customers, some
of them are at my data warehouse. So, neither NAS
From: Kiss Dániel [mailto:n...@dinagon.com]
Sent: Monday, September 13, 2010 3:17 PM
To: Jerry Schwartz
Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
replicat...@lists.mysql.com
Subject: Re: Unique ID's across multiple databases
Well, that would be the plan, yes. :-)
Anyway, I'll
-Original Message-
From: Kiss Dániel [mailto:n...@dinagon.com]
Sent: Monday, September 13, 2010 5:59 AM
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:
On Mon, September 13, 2010 15:37, Daevid Vincent wrote:
-Original Message-
From: Kiss D�niel
[mailto:n...@dinagon.com]
Sent: Monday, September 13, 2010
5:59 AM
Well, thanks, but I'm afraid using
UUID's (even with hex
compression) is
kind of
a suicide, when it comes to performance.
On Mon, Sep 13, 2010 at 8:59 PM, Johnny Withers joh...@pixelated.netwrote:
This sounds like a good job for a 'NoSQL' system. Maybe?
I can't help but blink at that. How exactly is NoSQL going to fix issues
that are related to topology, not inherent SQL limitations ? Which
particular
On 12 Sep 2010, at 19:47, Kiss Dániel wrote:
- SID adds only 2 bytes in this case to the size of the primary key item.
It can be even 1 byte if I'm sure I'll never exceed maximum 255 servers. But
anyhow, it is still way smaller than the 16 byte of a UUID field, even if
using BIGINT's.
Server offset + increment works really well, is simple, and well
documented and reliable - not sure why you would want to re-invent
something that works so well :).
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
You may be right. I'm not arguing that offset + increment is working.
I'm just wondering if that's the optimal solution when you do not know how
many servers you will have in your array in the future. In my view, the
offset + increment thingy is good if you know in advance that you'll have a
20 matches
Mail list logo
