Paulie wrote:
On Feb 16, 6:09 am, pg <pen...@xxxxxxxxxxxx> wrote:
I am involved with a SQL server project. The server would be used in a
very heavy duty environment, with hundreds of thousands, if not
millions of database enquiries per minutes.
Perhaps you should clarify here - what exactly do you mean by
millions of "database enquiries per minutes"?
Will these be reads? Or will there be lots of updating going on?
What is the nature of these database "enquiries"?
The server would run Linux or one of the BSD variant, with at least
32GB of RAM. We are not very certain of the hardware specs yet because
we haven't decided on which SQL to use.
Fine - Oracle won't be supported on *BSD.
I know that Oracle, MySQL and PostgreSQL are all designed for heavy
duty uses.
Yes - but what sort of heavy duty use? MySQL will be better IMHO for
reading - less transactional overhead - which is both good and bad!
And I checked all available online resources for a SQL comparison and
all I could find is some articles dated 2005 or so !
So, here's my questions:
1. Are there any recent SQL comparison article available?
All of the commercial vendors specifically forbid benchmarks - except
the
ones they choose to publish themselves!
2. Since the server may come with only 32GB of RAM, which SQL can run
the "leanest" - that is, not a memory hog?
32GB of RAM is a large system - but RAM isn't everything! What is the
OS going to be? That's your first decision.
Huh... 32GB of RAM is NOT a large system - more of a smallish-medium
size. :)
<snip>
First: You really do need to define your database and transaction model
before figuring out what engine to use.
Your enemy is going to be scalability in the I/O bus unless everyone is
querying the same information constantly. Oracle's cache or MySQL Query
Cache could handle a lot of that - Most db engines have some sort of
caching feature you *may* want to use.
Should you choose an open-source, make sure your code AND your DDL uses
as much ANSI standards as possible so when you do need to move to
something else, it won't be as painful. (auto-incrementing columns vs.
sequences etc...).
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
