Обсуждение: PHP + PostgreSQL

..............................................
A Question...
Since before your sun burned hot in space
and before your race was born,
I have awaited a question.

Elielson Fontanezi
DBA Technical Support - PRODAM
Parque do Ibirapuera s/n - SP - BRAZIL
+55 11 5080 9493

On Thu, Sep 19, 2002 at 01:52:31PM -0300, Elielson Fontanezi wrote:
[ . . . ]
>        I doing a research about Apache Web Server + PHP + PostgreSQL.
[ . . . ]
>    reliable or not. The pros and set backs about it.

That is a, well, hm . . . rather extremely general question. Could you
be a little more specific?

Regards, Frank

On Thu, Sep 19, 2002 at 07:14:23PM +0200, Frank Joerdens wrote:
> On Thu, Sep 19, 2002 at 01:52:31PM -0300, Elielson Fontanezi wrote:
> [ . . . ]
> >        I doing a research about Apache Web Server + PHP + PostgreSQL.
> [ . . . ]
> >    reliable or not. The pros and set backs about it.

Here's fairly good article:

http://www.phpbuilder.com/columns/tim20000705.php3

Regards, Frank

On Thu, 19 Sep 2002, Elielson Fontanezi wrote:

> Hi everybody!
>
>     I doing a research about Apache Web Server + PHP + PostgreSQL. If it is
> reliable or not. The pros and set backs about it.
>     From you what do you have to tell me about it?

If all you need is a little catalogue or poll system, MySQL is a winner,
Pg is a luser.:-)
In other cases it depends. Pg has a few very useful features such as
transactions, construction like "delete where from(select)" and soon
so for sophisticated project it's more suitable.

--
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.

Good:
* postgres is really good for concurrent accesses (in part because of it's
better-than-row-level-locking)
* postgres is stable. I don't think I've heard of many non-hardware crashes
for a while now
* php has good support for postgres
* good feature set, won't hold you back
* good with a huge amount of data, and/or many table joins

Bad:
* no replication (I suppose if you really need it, there are replication
soultions, but maybe not as good as oracle or db2), which means if you're
talking intense queries, you'll need to get a really big box that can handle
all those requests by itself.

Regards,
    Jeff Davis


On Thursday 19 September 2002 09:52 am, Elielson Fontanezi wrote:
> Hi everybody!
>
>     I doing a research about Apache Web Server + PHP + PostgreSQL. If it is
> reliable or not. The pros and set backs about it.
>     From you what do you have to tell me about it?
>
> ..............................................
> A Question...
> Since before your sun burned hot in space
> and before your race was born,
> I have awaited a question.
>
> Elielson Fontanezi
> DBA Technical Support - PRODAM
> Parque do Ibirapuera s/n - SP - BRAZIL
> +55 11 5080 9493

>Good:
>* postgres is really good for concurrent accesses (in part because of it's
>better-than-row-level-locking)
>* postgres is stable. I don't think I've heard of many non-hardware crashes
>for a while now
>* php has good support for postgres
>* good feature set, won't hold you back
>* good with a huge amount of data, and/or many table joins
>
>Bad:
>* no replication (I suppose if you really need it, there are replication
>soultions, but maybe not as good as oracle or db2), which means if you're
>talking intense queries, you'll need to get a really big box that can handle
>all those requests by itself.
>
>Regards,
>    Jeff Davis

Of course, a bigger box running PostgreSQL is still cheaper and
easier to maintain than multiple replicated servers. However, if you
need to have super-high reliability, such that you've got mulitple
servers in different areas of the country running concurrently, all
accepting insert/update requests from users, then you'd need real
replication. The PostgreSQL solutions around are good enough for a
quick swap to a backup server.

Elaine Lindelef
>
>
>On Thursday 19 September 2002 09:52 am, Elielson Fontanezi wrote:
> > Hi everybody!
> >
> >     I doing a research about Apache Web Server + PHP + PostgreSQL. If it is
> > reliable or not. The pros and set backs about it.
> >     From you what do you have to tell me about it?
> >
> > ..............................................
> > A Question...
> > Since before your sun burned hot in space
> > and before your race was born,
> > I have awaited a question.
> >
> > Elielson Fontanezi
> > DBA Technical Support - PRODAM
> > Parque do Ibirapuera s/n - SP - BRAZIL
> > +55 11 5080 9493
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster

> Of course, a bigger box running PostgreSQL is still cheaper and
> easier to maintain than multiple replicated servers.

  Cheaper?  Look at the prices for two 2-cpu machines, and compare that to
the price of one 4-cpu machine.  You can get nicely equipped dual-CPU
machines for what, $4,000 or $5,000 total?  When you get into the 4-way
machines, you'll pay that much just for the motherboard and chassis - and
you still have thousands left to spend on the processers themselves.

  Besides that, two 2-CPU machines can perform much, much better than a
single 4-way machine, because you only have half of the processers
fighting for I/O.

steve

>  You can get nicely equipped dual-CPU
> machines for what, $4,000 or $5,000 total?

  - That should have read "You can get a PAIR of nicely equipped...."

steve

Steve Wolfe wrote:
>
> > Of course, a bigger box running PostgreSQL is still cheaper and
> > easier to maintain than multiple replicated servers.
>
>   Cheaper?  Look at the prices for two 2-cpu machines, and compare that to
> the price of one 4-cpu machine.  You can get nicely equipped dual-CPU
> machines for what, $4,000 or $5,000 total?  When you get into the 4-way
> machines, you'll pay that much just for the motherboard and chassis - and
> you still have thousands left to spend on the processers themselves.
>
>   Besides that, two 2-CPU machines can perform much, much better than a
> single 4-way machine, because you only have half of the processers
> fighting for I/O.

It's not only the cost of hardware, you have to look at. Unless you know
good developers that do the porting of your application into a
distributed version for a cup of rice per day, install and configure the
replication and load balancing for free because that's so cool and so
much fun, you have to add all these costs to the cheaper 2-way machines
before comparision. If it's not the Joelooser Web page hitcount
"application" kind of thing, you spend a good number of days ensuring
that your application doesn't run into problems when you go multimaster.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

> > Of course, a bigger box running PostgreSQL is still cheaper and
> > easier to maintain than multiple replicated servers.
>
>  Cheaper?  Look at the prices for two 2-cpu machines, and compare that to
>the price of one 4-cpu machine.  You can get nicely equipped dual-CPU
>machines for what, $4,000 or $5,000 total?  When you get into the 4-way
>machines, you'll pay that much just for the motherboard and chassis - and
>you still have thousands left to spend on the processers themselves.
>
>  Besides that, two 2-CPU machines can perform much, much better than a
>single 4-way machine, because you only have half of the processers
>fighting for I/O.
>
>steve
>

Yes - but the cost of the TOTAL SOLUTION - which includes replication
software, sysadmin time, programming time and testing, etc - is still
in my experience cheaper with one big database box than two smaller
boxes, if your only purpose is to get more thruput for the $$. This
is subject to change, of course.

Hardware is cheap. People are expensive. :^)

My preferred approach has been a big DB box and an array of
webservers connecting to it.

Elaine Lindelef