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 v
On Mon, Sep 13, 2010 at 8:59 PM, Johnny Withers wrote:
>
> 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 incarnation of NoSQL are you
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
> -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:
> http
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,
M
> >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 not own all the databases. Some o
artz
> >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
>-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 data
;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 multip
>-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
>-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 w
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 optima
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. T
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
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 wrote:
> Hmm, that's a very interesting scenario,
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
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,
On Sun, Sep 12, 2010 at 9:45 PM, Kiss Dániel 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 b
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
limit
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:http://lists.mysql.com/mysql?unsub=
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
21 matches
Mail list logo
