Re: Which SQL is the best for servers?
Date: Mon, 16 Feb 2009 23:00:25 +0100
Message-ID: <6vu5vqFlkg3mU1_at_mid.individual.net>
On 16.02.2009 15:59, Walt wrote:
> pg 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.
>>
>> 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.
>>
>> I know that Oracle, MySQL and PostgreSQL are all designed for heavy
>> duty uses.
>>
>> 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?
>>
>> 2. Since the server may come with only 32GB of RAM, which SQL can run
>> the "leanest" - that is, not a memory hog?
>>
>> 3. The server might also become a web-server, which SQL can tie itself
>> to the Web-based enquiry they best?
>>
>> Please give me your suggestion / opinion. Thank you !!
> > A couple points: > > 1) You are looking for a Relational Database Management System, or > RDBMS. SQL is the *language* one uses to communicate with the RDBMS, > it's not the system itself. Try Googling on the correct terms and > you'll get better results.
Full ack!
> 2) You are going about it backwards by speccing the hardware and then > trying to find software to run on it. The correct approach is to define > your business needs, then find the software that solves your problems, > and only at that point do you decide on the hardware.
And more specifically: in these performance regions you need to have a clear understanding of your data and your query load (what SELECTs, how many modifying operations etc.).
> 3) Don't run the webserver and the database server on the same hardware > (although you might be able to get away with it through virtualization). > It's just very bad from a security standpoint.
One reasonable approach for this would be to choose a RDBMS which allows scaling by adding more hardware. A clustered DB does not only help in scaling but it will often give you added robustness.
Another approach is to partition your data and have several DB servers which host only part of the data. Whether this is feasible depends of course on your data and business needs. If you have highly interconnected data then chances are that this is not an option.
Good luck!
robert
PS: Please do not cross post to so many groups. F'up to comp.databases Received on Mon Feb 16 2009 - 16:00:25 CST