|
|
 | | From: | Merlin Moncure | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 15:21:18 -0500 |
|
|
 | > Dealing about the hardware, for the moment we have only a bi-pentium Xeon
> 2.8Ghz with 4 Gb of RAM ... and we saw we had bad performance results ...
> so
> we are thinking about a new solution with maybe several servers (server
> design may vary from one to other) ... to get a kind of cluster to get
> better
> performance ...
>
> Am I clear ?
yes. Clustering is not the answer to your problem. You need to build a bigger, faster box with lots of storage.
Clustering is
A: a headache
B: will cost you more, not less
C: not designed for what you are trying to do.
Going the x86 route, for about 20k$ you can get quad Opteron with 1-2 terabytes of storage (SATA), depending on how you configure your raid. This is the best bang for the buck you are going to get, period. Replicate for redundancy, not performance.
If you are doing fair amount of writes, you will not be able to make a faster system than this for similar amount of cash. You can drop the price a bit by pushing optional upgrades out to the future...
If this is not good enough for you, it's time to start thinking about a mid range server.
Merlin
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
| | From: | Ron Mayer | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 13:46:06 -0800 |
|
|
| Merlin Moncure wrote:
> ...You need to build a bigger, faster box with lots of storage...
> Clustering ...
> B: will cost you more, not less
Is this still true when you get to 5-way or 17-way systems?
My (somewhat outdated) impression is that up to about 4-way systems
they're price competitive; but beyond that, I thought multiple cheap
servers scales much more afordably than large servers. Certainly
at the point of a 129-CPU system I bet you're better off with a
network of cheap servers.
> A: a headache
Agreed if you mean clustering as-in making it look like one single
database to the end user. However in my experience a few years ago, if
you can partition the data in a way managed by the application, it'll
not only be less of a headache, but probably provide a more flexable
solution. Currently I'm working on a pretty big GIS database, that
we're looking to partition our data in a manner similar to the microsoft
whitepaper on scaling terraserver that can be found here:
http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2002-53
I think this paper is a very nice analysis of many aspects of
larger-server&SAN vs. application-partitioned-clusters, including
looking at cost, reliability, managability, etc. After reading that
paper, we started very seriously looking into application-level
partitioning.
|
|
| | From: | Ron Mayer | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 13:49:53 -0800 |
|
|
| Ron Mayer wrote:
> http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2002-53
Wrong link...
http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=812
This is the one that discusses scalability, price, performance,
failover, power consumption, hardware components, etc.
Bottom line was that the large server with SAN had $1877K hardware costs
while the application-partitioned cluster had $110K hardware costs --
but it's apples-to-oranges since they were deployed in different years.
Still a big advantage for the small systems.
|
|
| | From: | Christopher Browne | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Sun, 23 Jan 2005 01:08:26 -0500 |
|
|
| Quoth Ron Mayer :
> Merlin Moncure wrote:
>> ...You need to build a bigger, faster box with lots of storage...
>> Clustering ... B: will cost you more, not less
>
>
> Is this still true when you get to 5-way or 17-way systems?
>
> My (somewhat outdated) impression is that up to about 4-way systems
> they're price competitive; but beyond that, I thought multiple cheap
> servers scales much more afordably than large servers. Certainly
> at the point of a 129-CPU system I bet you're better off with a
> network of cheap servers.
Not necessarily.
If you have 129 boxes that you're trying to keep synced, it is likely
that the cost of syncing them will be greater than the other write
load.
If the problem being addressed is that a 4-way box won't handle the
transaction load, it is unlikely that building a cluster of _smaller_
machines will help terribly much.
The reason to "cluster" in the context of a transactional system is
that you need improved _reliability_.
Since communications between servers is _thousands_ of times slower
than communicating with local memory, you have to be willing to live
with an ENORMOUS degradation of performance when hosts are
synchronized.
And if "real estate" has a cost, where you have to pay for rack space,
having _fewer_ machines is preferable to having more.
--
output = ("cbbrowne" "@" "gmail.com")
http://www.ntlug.org/~cbbrowne/postgresql.html
If con is the opposite of pro, is Congress the opposite of progress?
|
|
|
