> 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
