At 13:38 6-10-99 -0500, Frank Livaudais wrote:
>Our issue comes from the fact we will have tables with millions and 
>millions of records and
>thousands of simultaneous users.  So we need to power that Oracle brings, 
>we are just
>looking for ways to tweak the performance

I don't think (never tried it myself, but according to the MySQL docs they
do use it at TCX) MySQL has much of a problem with millions and millions of
records. Thousands of simultaneous users might be a big problem though - for
ANY database.

Really, what you want to run depends heavily on how you'll be using the 
database.
How many concurrent sessions (not users - sessions) do you expect, will one db
server do or will there be a need for a cluster of them - and if you have to go
the cluster way, might you be able to spread database tables over database 
servers.
Will you do mostly reads, or will you need to write a lot as well. Can you use
static row sizes or is there a need for variable length fields, etc, etc. All
such have an impact on performance.

MySQL is quick, it's by far the fastest you can get at most operations. On the
other hand, you can't easily spread the load over multiple servers, you can
forget about commit/rollback, you won't have stored procedures (yet) - and
there's probably more I can't think of right now.

I wouldn't dream of running our customer database on MySQL - that kind of data
I won't trust to it simply because other databases have a lot more to offer to
ensure reliability and integrity. On the other hand, I wouldn't ask of a sloth
like Oracle or Informix to serve me the data for persistent user sessions. 
There
is not much of a need for the reliability (at a certain performance cost) the
sloths offer for such data.

Yet, don't forget that the best database is no database. :) If you can cache
data instead of running expensive queries, you'll see performance increase
significantly. It's how I'm rewriting a system with HTML::Mason and seeing some
3-4 times the performance the old system had (or lacked). Reducing the number
of queries to 1 per request instead of some 6 queries per request really makes
a difference in my test configurations. Not in the least because it will allow
your database to serve other more useful queries instead.

Grtz,
Pascal

--
Pascal Eeftinck - arcade^xs4all.nl - Perl is not a language, it's a way of 
life.

Reply via email to