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