On 4/30/06, Tony Lausin <[EMAIL PROTECTED]> wrote:
Hello all,
I'm working on a CMS which requires an open source database capable of
handling hundreds of thousands of users simultaneously, with a high
rate of database writes, and without buckling. We're talking somewhere
between nerve.com/catch27.com and xanga.com/friendster.com
PostgreSQL is a personal favorite of mine, and my gut instinct is that
it's the best choice for a large scale CMS serving many users;
however, I'm getting antsy. I keep getting suggestions that Postgres
is really only suited to small and medium projects, and that I should
be looking at MySQL for a large scale database drive site. I'm not
really a fan of MySQL, but I'll consider it if it truly is the better
choice in this case. I just don't understand how it would be. I'm
thinking this is solely in reference to VACUUM. Even with autovacuum
suport, I tend to agree there is at least one handicap.
I could really use some enlightenment on just where PostgreSQL fits in
a single-server, highly-trafficked web site serving mostly text,
pictures and possibly streaming media.
http://people.planetpostgresql.org/xzilla/index.php?/archives/151-Sean-Chittenden-on-RubyOnRails-Podcast.html
http://www.postgresql.org/about/casestudies/
http://www.postgresql.org/about/users
are all good places to start.
TBH it depends a lot on your data and how you structure it. I wrote a
small tute on how to get rid of left-join type queries and use
triggers to keep count(*) type queries to a minimum..
http://www.designmagick.com/article/36/Forum-Project/Database-Design-Issues
It's not always possible, but there are ways to minimize count(*),
min(field), max(field) type queries where postgresql isn't able to
optimize fully due to mvcc issues.
--
Postgresql & php tutorials
http://www.designmagick.com/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
