> 1) ACID compliant transaction support. There is
> concern as to whether InnoDB is ready for prime time,
> especially as regards backups and our 24X7 needs. Our
> databases can grow very rapidly and we can't afford to
> bounce the database just to add datafiles as is
> currently required for InnoDB.

If you need to add new datafiles, start them small and flag them
autoextend. Should take InnoDB no time at all to initialize them.
Or flag them autoextend to begin with.

We tax Innobase -very- heavily and it has proven to be
both fast (much faster than MyISAM for our purposes) and
*extremely* reliable.

The support we've received has also been outstanding.
See the list archives, even people with Oracle support
contracts claim to receive far better service from this
list.

> 2) Excessive code to work around non-support for
> subselects. While subselects are scheduled for stable
> release in mid 2003, we can't wait that long and,
> based on past delivery of MySQL promised features, the
> current view is that subselects won't really be tested
> and supported (in stable production) until mid 2004.

I hate to say it, but this sounds more like egotistical
bellyaching than a severe development crisis.  Alternatives
to subselects are so easy to string together that I seriously
question the motives or abilities of people who CANNOT survive
without them.  Don't get me wrong, they're neat to have, but I
really don't mind waiting, given how fast, simple, and well
supported MySQL is.

> Is anyone willing and able to help me provide some
> defense for MySQL on this?

Try MySQL Myths Debunked:

http://m.bacarella.com/projects/mysqlmyths/

> History: 
> We have experienced dramatic growth and our software
> is somewhat mature being maintained and enhanced by
> over 2 dozen fulltime developers and 7 sysadmins.
> Generally there is one database for each customer and
> each customer may have 10,000's of endusers who access
> our hosted databases. Currently we host our web
> application to about 1000 customers/databases on
> several large multiprocessor database servers with a
> coule EMC disk farms. We have multiple data centers in
> multiple locations. We have many database.tables with
> multi-million rows and a lot of concurrent enduser
> query access. Larger customers have occasionally
> sustained peak loads of 200 queries per second and on
> a few rare occasions we have neared 1000 queries per
> second for a single database for relatively brief
> periods. There are a significant number of
> inserts/updates that have created table locking
> problems and future software releases will be even
> more transaction intensive. 
> 
> Management thinks we have outgrown MySQL and need a
> "better" database. I need some MySQL ammunition to
> defend against changing databases. HELP...

Migrating databases isn't something to undertake lightly.

Make sure some egomaniac isn't pushing for it just because
of prejudices.  Migrating a system such as this simply because
of lack of subselects sounds insane (how have you coped
up until now?)

Are there other factors?

-- 
Michael Bacarella  | Netgraft Corp
                   | 545 Eighth Ave #401
 Systems Analysis  | New York, NY 10018
Technical Support  | 212 946-1038 | 917 670-6982
 Managed Services  | http://netgraft.com/


---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to