From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1G95rU-0000Hb-Sw for garchives@archives.gentoo.org; Fri, 04 Aug 2006 20:01:37 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k74K0Qij011768; Fri, 4 Aug 2006 20:00:26 GMT Received: from mail.isohunt.com (mail.isohunt.com [69.64.61.20]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k74JwFMD016728 for ; Fri, 4 Aug 2006 19:58:15 GMT Received: (qmail 5693 invoked from network); 4 Aug 2006 14:58:12 -0500 X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,BAYES_50,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: mail.isohunt.com Received: from Unknown (HELO curie.orbis-terrarum.net) (24.81.201.182) (smtp-auth username robbat2@isohunt.com, mechanism login) by mail.isohunt.com (qpsmtpd/0.33-dev on w2.isohunt.com) with (AES256-SHA encrypted) ESMTP; Fri, 04 Aug 2006 14:58:09 -0500 Received: (qmail 9110 invoked by uid 10000); 4 Aug 2006 12:56:59 -0700 Date: Fri, 4 Aug 2006 12:56:59 -0700 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Monthly Gentoo Council Reminder for August Message-ID: <20060804195659.GB5021@curie-int.orbis-terrarum.net> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20060801093001.C97C864465@smtp.gentoo.org> <44D1BFFD.4040303@gentoo.org> <1154607828.23292.5.camel@localhost> <44D1F4EF.3000209@gentoo.org> <1154612153.17538.26.camel@onyx> <44D30BE8.8060909@gentoo.org> <44D34753.6090604@gentoo.org> <44D36D6E.3060705@gentoo.org> <44D38CF0.9010909@badapple.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: <44D38CF0.9010909@badapple.net> User-Agent: Mutt/1.5.11 X-Archives-Salt: c6dde879-0818-4d47-9591-3b528fa7891e X-Archives-Hash: aa78be3a84b51390f876e971d9b3ff0e --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 04, 2006 at 11:07:44AM -0700, kashani wrote: > Another technique is to change high transaction tables to Innodb=20 > table format. Innodb is going to be roughly 30% slower than MyISAM for= =20 > selects and take up much more space on disk approx 3-5x larger. However i= t=20 > has row locking which solves the contention issue. A good example of mixe= d=20 > table types is actually Mediawiki which uses Memory for hitcounters,=20 > Innodb for pages and revisions, and MyISAM for everything else. =46rom 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=20 > 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).=20 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). --=20 Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFE06aLPpIsIjIzwiwRAuFjAKD2iB1tGCt5dkhbjXWD17W0CBVhLgCghfVm 78OWfQ09xcjpcU+4z4WBx3U= =qa84 -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- -- gentoo-dev@gentoo.org mailing list