Choice of MySQL table type for non-critical webapp data (MyISAM vs. InnoDB)

Question

Consider this scenario with the following assumptions:

• The database is used for a non-critical webapp.
• Query speed is of vital importance.
• The read/write patterns are roughly >95 % reads and <5 % writes.
• The database is backuped up daily using mysqldump.
• The is no need for transactions or advanced crash recovery. If the database crashes I'll simply import last night's mysqldump. This is good enough in this scenario.
• No need for full-text searching.

Pros of MyISAM under said assumptions:

• It's very fast (with one exception - see below).
• It's light-weight and has an easy-to-understand mapping between database/table to physical files in file system (.MYD/.MYI/.frm).
• Easy backup (mysqldump).

All-in-all I'm very happy with MyISAM with one major exception. MyISAM has one major shortcoming under said assumptions and that is table level locking. When UPDATEs are running towards a frequently read table all reads are blocked. Needless to say this causes major performance problems which must be solved.

My questions are:

1. Is there some way to get rid of table level locking without switching away from MyISAM?
2. If I must switch to InnoDB - how do I configure InnoDB so that it behaves as similar to MyISAM as possible (think no transactions, logical file structure, etc.). How do I configure a InnoDB to be "just like MyISAM but without table level locking"?

Answer 1

1. No, MyISAM means table level locking.
2. You can't get it "just like", but you can get it "a lot more like" by turning on the innodb_file_per_table option. InnoDB will still store critical information in its system-level data file, however, and you can't do things like casually rename a database by renaming the directory it lives in like you can with MyISAM.

Answer 2

Have you actually taken performance metrics using myisam and innodb tables? In my experience the differences in speed is not really that much when you consider all the ACID benefits you get from innodb. Just the table locking alone will affect speed such that innodb would be overall faster.

Also notice that myisam is much faster on inserts, not so much on selects. You are inserting only 5% of the time... do the math.

You can always do mysqldump using an innodb, so your backup rocess is the same.

Answer 3

I know some projects use a mirror DB for searching. It tends to be optimized for the searches and sometimes even run on a different machine, just to isolate the overhead.

The only drawback here is that keeping them in sync is a bit of a hassle. If stale data in your search table isn't too troubling, it might be the best bet. If performance is an issue that is.

It isn't my favorite solution, but it is pretty simple in theory.

Answer 4

1. When it comes to backup InnoDB doesn't prevent you from using mysqldump.
2. Are you sure that you really need to maintain the mapping between database tables and files on disk? Manual operations on database files are rarely a good idea.
3. With InnoDB you don't have to use transactions, by default it works in "autocommit" mode (every query will be commited automatically).
4. "InnoDB is slower" is mostly myth these days, but of course it depends on your workload.

In other words I think you should definitely give InnoDB a try and benchmark the performance of your application. Migration is extremely simple, so I don't see a reason not to try. For me InnoDB is a default choice for a long time.