Comments for Big DBA Head!

Comment on More Debate, More Flame, More Choosing the correct tool for the job by Mark Callaghan

Mark Callaghan — Mon, 29 Mar 2010 22:08:57 +0000

The referenced discussion is way off track. I am sure that Digg has good reasons for migrating. But their initial post described how the migration fixed their performance problem and the real problem seems to be a lousy schema — http://mysqlha.blogspot.com/2010/03/index-only.html.

Dennis has written about this too at http://www.yafla.com/dforbes/Getting_Real_about_NoSQL_and_the_SQL_Performance_Lie.

All of this has been ignored by the Digg performance guru. Maybe that is why the discussion is nothing but flames.

Insert ad for expert consulting here.

Comment on New Benchmark I am working on that tests MYSQL -vs- NOSQL by Matthew Yonkovit

Matthew Yonkovit — Mon, 29 Mar 2010 18:09:03 +0000

No I have not seen that, thanks for the link!

Comment on New Benchmark I am working on that tests MYSQL -vs- NOSQL by Sam

Sam — Mon, 29 Mar 2010 18:02:23 +0000

Have you seen this benchmark by Yahoo! for HBase, Cassandra, PNUTS and MySQL?

http://www.brianfrankcooper.net/pubs/ycsb.pdf

Comment on New Benchmark I am working on that tests MYSQL -vs- NOSQL by Matt Montgomery

Matt Montgomery — Mon, 29 Mar 2010 16:51:13 +0000

Oh, please, please include NDB in this discussion since it fits nicely between MySQL and NoSQL, bridging the two.

Comment on 5 Minute DBA – Database Server Hardware Selection by Identifying Resource Bottlenecks – Disk | MySQL Expert | MySQL Performance | MySQL Scalability

Fri, 18 Sep 2009 22:43:53 +0000

[...] 60 second take on RAID and Disk Configuration. I concur with Matt Yonkivit. You should separate your OS from your database on disk, RAID 1 (2 drives) works fine for the OS. [...]

Comment on Testing Waffle by Ronald Bradford

Ronald Bradford — Fri, 12 Jun 2009 17:38:57 +0000

It’s Bradford, not Bradform

Comment on MyISAM with key_buffer larger than 4 GB by Yves Trudeau

Yves Trudeau — Fri, 12 Jun 2009 00:08:03 +0000

Mark, of course there is one mutex per key_buffer. The application I am thinking of is using a custom key_buffer on a mainly read-only table that has more that 25 GB of indices. The table is inserted only about once per day in a batch of many millions.

Comment on MyISAM with key_buffer larger than 4 GB by Mark R

Mark R — Thu, 11 Jun 2009 21:24:16 +0000

Unfortunately the key buffer itself has a big fat mutex around it (one per key buffer, that is, just one unless you use multiple key buffers), which is taken any time anyone modifies the key buffer (which includes bringing pages in AND out of it, which is done by selects as well as updates).

This means that operations which do a large amount of key buffer work effectively block up the entire server – even if they’re operating on an entirely different table.

The example we see, is doing a lot of inserts with DELAY_KEY_WRITE on, then doing a flush table on that table. It effectively “stops the world” during the flush – no index on any table at all may be touched whatsoever.

Comment on MyISAM with key_buffer larger than 4 GB by Yves Trudeau

Yves Trudeau — Thu, 11 Jun 2009 19:31:31 +0000

Justin, I have many clients that have MyISAM tables with more than 25GB of index space. I think it can be useful even for large tables.

Comment on MyISAM with key_buffer larger than 4 GB by Justin Swanhart

Justin Swanhart — Thu, 11 Jun 2009 19:05:14 +0000

This is helpful when you have lots of tables, with total indexes > 4GB. When you have one big table, the advantage may not be so big.