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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
