On Fri, Aug 04, 2006 at 11:07:44AM -0700, kashani wrote: > Another technique is to change high transaction tables to Innodb > table format. Innodb is going to be roughly 30% slower than MyISAM for > selects and take up much more space on disk approx 3-5x larger. However it > has row locking which solves the contention issue. A good example of mixed > table types is actually Mediawiki which uses Memory for hitcounters, > Innodb for pages and revisions, and MyISAM for everything else. From professional deployments, InnoDB is only slower when your hardware isn't up to the task of keeping the entire DB in the kernel disk cache (needs 8Gb+ of RAM for some databases). BUT...
This path WAS explored, and a major stumbling block is that Bugzilla makes very large use of FULLTEXT indices, which InnoDB does not support. There is an open bug in Bugzilla's bugzilla requesting people to work on it, but it would entail huge changes to the bugzilla DB structure, moving away from proper normalization and adding a split to allow keeping either duplicate MyISAM for indices, or splitting existing tables simply based on the indices needed. We are in good hands (I'm involved as well, I started the mysql team, and I'm one of the upstream developers of phpMyAdmin) and slowly getting there, the powerful hardware is actually really needed. > Here's a paper on general Mysql scaling that's pretty interesting and > easy to read if you don't have much db background. > http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf I am fully aware of the DB systems layout of LiveJournal, and believe me, we are taking large parts of it into consideration, where applicable (Bugzilla SQL queries are a LOT more complicated than those of LiveJournal). Using the 2 DB boxes, there will be 2 slave instances that get reads balanced between them, and a migratable master instance (in case one DB box has to go down, the actual master DB content is on the SAN, and the other box can take over the master instance). There's some glue work needed to make all of this transparent to Bugzilla as well, due to it's existing limitations (the glue is faster to develop, more stable, and much easier to debug than hacking on the Bugzilla codebase). -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpvvqzstYJDL.pgp
Description: PGP signature
