Re: Which SQL is the best for servers?

From: Michael Austin <maustin_at_firstdbasource.com>
Date: Mon, 16 Feb 2009 15:09:54 -0600
Message-ID: <FCkml.12592$W06.9975_at_flpi148.ffdc.sbc.com>

Paulie wrote:
>
> On Feb 16, 6:09 am, pg <pen..._at_catholic.org> 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...). Received on Mon Feb 16 2009 - 15:09:54 CST