 | | From: | Merlin Moncure | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 10:16:21 -0500 |
|
|
 | > No please do not talk about this again ... I'm looking about a PostgreSQL
> solution ... I know RAC ... and I'm not able to pay for a RAC certify
> hardware configuration plus a RAC Licence.
Are you totally certain you can't solve your problem with a single server solution?
How about:
Price out a 4 way Opteron 4u rackmount server with 64 bit linux, stuffed with hard drives (like 40) set up in a complex raid configuration (multiple raid controllers) allowing you (with tablespaces) to divide up your database.
You can drop in dual core opterons at some later point for an easy upgrade. Let's say this server costs 20k$...are you sure this will not be enough to handle your load?
Merlin
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
|
|
| | From: | Hervé_Piedvache | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 16:31:06 +0100 |
|
|
| Le Jeudi 20 Janvier 2005 16:16, Merlin Moncure a écrit :
> > No please do not talk about this again ... I'm looking about a PostgreSQL
> > solution ... I know RAC ... and I'm not able to pay for a RAC certify
> > hardware configuration plus a RAC Licence.
>
> Are you totally certain you can't solve your problem with a single server
> solution?
>
> How about:
> Price out a 4 way Opteron 4u rackmount server with 64 bit linux, stuffed
> with hard drives (like 40) set up in a complex raid configuration (multiple
> raid controllers) allowing you (with tablespaces) to divide up your
> database.
>
> You can drop in dual core opterons at some later point for an easy upgrade.
> Let's say this server costs 20k$...are you sure this will not be enough to
> handle your load?
I'm not as I said ibn my mail I want to do a Cluster of servers ... :o)
--
Hervé Piedvache
Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
|
|
| | From: | Bruno Almeida do Lago | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 16:09:57 -0200 |
|
|
| Could you explain us what do you have in mind for that solution? I mean,
forget the PostgreSQL (or any other database) restrictions and explain us
how this hardware would be. Where the data would be stored?
I've something in mind for you, but first I need to understand your needs!
C ya.
Bruno Almeida do Lago
-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Hervé Piedvache
Sent: Thursday, January 20, 2005 1:31 PM
To: Merlin Moncure
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] PostgreSQL clustering VS MySQL clustering
Le Jeudi 20 Janvier 2005 16:16, Merlin Moncure a écrit :
> > No please do not talk about this again ... I'm looking about a
PostgreSQL
> > solution ... I know RAC ... and I'm not able to pay for a RAC certify
> > hardware configuration plus a RAC Licence.
>
> Are you totally certain you can't solve your problem with a single server
> solution?
>
> How about:
> Price out a 4 way Opteron 4u rackmount server with 64 bit linux, stuffed
> with hard drives (like 40) set up in a complex raid configuration
(multiple
> raid controllers) allowing you (with tablespaces) to divide up your
> database.
>
> You can drop in dual core opterons at some later point for an easy
upgrade.
> Let's say this server costs 20k$...are you sure this will not be enough
to
> handle your load?
I'm not as I said ibn my mail I want to do a Cluster of servers ... :o)
--
Hervé Piedvache
Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
|
|
| | From: | Greg Stark | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | 20 Jan 2005 15:00:17 -0500 |
|
|
| Hervé Piedvache writes:
> Le Jeudi 20 Janvier 2005 19:09, Bruno Almeida do Lago a écrit :
> > Could you explain us what do you have in mind for that solution? I mean,
> > forget the PostgreSQL (or any other database) restrictions and explain us
> > how this hardware would be. Where the data would be stored?
> >
> > I've something in mind for you, but first I need to understand your needs!
>
> I just want to make a big database as explained in my first mail ... At the
> beginning we will have aprox. 150 000 000 records ... each month we will add
> about 4/8 millions new rows in constant flow during the day ... and in same
> time web users will access to the database in order to read those data.
> Stored data are quite close to data stored by google ... (we are not making a
> google clone ... just a lot of data many small values and some big ones ...
> that's why I'm comparing with google for data storage).
> Then we will have a search engine searching into those data ...
You're concentrating on the data within the database. That's only half the
picture. What are you going to *do* with the data in the database? You need to
analyze what "we will have a search engine searching into those data" means in
more detail.
Postgres is more than capable of storing 150Gb of data. There are people with
terabyte databases on this list. You need to define what types of queries you
need to perform, how many data they need to manipulate, and what your
performance requirements are for those queries.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
|
|
| | From: | Hervé_Piedvache | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 20:00:03 +0100 |
|
|
| Le Jeudi 20 Janvier 2005 19:09, Bruno Almeida do Lago a écrit :
> Could you explain us what do you have in mind for that solution? I mean,
> forget the PostgreSQL (or any other database) restrictions and explain us
> how this hardware would be. Where the data would be stored?
>
> I've something in mind for you, but first I need to understand your needs!
I just want to make a big database as explained in my first mail ... At the
beginning we will have aprox. 150 000 000 records ... each month we will add
about 4/8 millions new rows in constant flow during the day ... and in same
time web users will access to the database in order to read those data.
Stored data are quite close to data stored by google ... (we are not making a
google clone ... just a lot of data many small values and some big ones ...
that's why I'm comparing with google for data storage).
Then we will have a search engine searching into those data ...
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 ?
Regards,
--
Hervé Piedvache
Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
|
|
| | From: | Dave Cramer | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 15:03:41 -0500 |
|
|
| This is a multi-part message in MIME format.
--------------020303070708040809020305
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Two way xeon's are as fast as a single opteron, 150M rows isn't a big deal.
Clustering isn't really the solution, I fail to see how clustering
actually helps since it has to slow down file access.
Dave
Hervé Piedvache wrote:
>Le Jeudi 20 Janvier 2005 19:09, Bruno Almeida do Lago a écrit :
>
>
>>Could you explain us what do you have in mind for that solution? I mean,
>>forget the PostgreSQL (or any other database) restrictions and explain us
>>how this hardware would be. Where the data would be stored?
>>
>>I've something in mind for you, but first I need to understand your needs!
>>
>>
>
>I just want to make a big database as explained in my first mail ... At the
>beginning we will have aprox. 150 000 000 records ... each month we will add
>about 4/8 millions new rows in constant flow during the day ... and in same
>time web users will access to the database in order to read those data.
>Stored data are quite close to data stored by google ... (we are not making a
>google clone ... just a lot of data many small values and some big ones ...
>that's why I'm comparing with google for data storage).
>Then we will have a search engine searching into those data ...
>
>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 ?
>
>Regards,
>
>
--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
--------------020303070708040809020305
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
http-equiv="Content-Type">
Two way xeon's are as fast as a single opteron, 150M rows isn't a big
deal.
Clustering isn't really the solution, I fail to see how clustering
actually helps since it has to slow down file access.
Dave
Hervé Piedvache wrote:
Le Jeudi 20 Janvier 2005 19:09, Bruno Almeida do Lago a écrit :
Could you explain us what do you have in mind for that solution? I mean,
forget the PostgreSQL (or any other database) restrictions and explain us
how this hardware would be. Where the data would be stored?
I've something in mind for you, but first I need to understand your needs!
I just want to make a big database as explained in my first mail ... At the
beginning we will have aprox. 150 000 000 records ... each month we will add
about 4/8 millions new rows in constant flow during the day ... and in same
time web users will access to the database in order to read those data.
Stored data are quite close to data stored by google ... (we are not making a
google clone ... just a lot of data many small values and some big ones ...
that's why I'm comparing with google for data storage).
Then we will have a search engine searching into those data ...
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 ?
Regards,
--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
--------------020303070708040809020305--
|
|
| | From: | Mark Kirkwood | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Fri, 21 Jan 2005 10:05:47 +1300 |
|
|
| Hervé Piedvache wrote:
>
>
> 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 ...
>
The poor performance may not necessarily be:
i) attributable to the hardware or,
ii) solved by clustering.
I would recommend determining *why* you got the slowdown. A few possible
reasons are:
i) not vacuuming often enough, freespacemap settings too small.
ii) postgresql.conf setting very non optimal.
iii) index and/or data design not optimal for PG.
My suspicions would start at iii).
Other posters have pointed out that 250000000 records in itself is not
necessarily a problem, so this sort of data size is manageable.
regards
Mark
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
