Re: Which SQL is the best for servers?
От | Michael Austin |
---|---|
Тема | Re: Which SQL is the best for servers? |
Дата | |
Msg-id | FCkml.12592$W06.9975@flpi148.ffdc.sbc.com обсуждение исходный текст |
Ответ на | Re: Which SQL is the best for servers? (Paulie <linehan.paul@gmail.com>) |
Список | pgsql-general |
Paulie wrote: > > On Feb 16, 6:09 am, pg <pen...@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...).
В списке pgsql-general по дате отправления: