tag:blogger.com,1999:blog-5412150273415696914.post7946475909404940157..comments2009-02-13T18:42:57.575-05:00Comments on Jay Janssen -- MySQL Guy: Fairness in Storage Engine BenchmarkingJay Janssennoreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5412150273415696914.post-58250429694388429502007-11-07T14:59:00.000-05:002007-11-07T14:59:00.000-05:00in response to dude from mangalore...Most of this ...in response to dude from mangalore...<BR/><BR/>Most of this is off-topic, but a 24G table means nothing without knowing the server you're trying to run it on as well and what your query/schema looks like. <BR/><BR/>As an example, I can get over 6,000 selects a second on a 25G table on a pretty powerful server with 8G of RAM. I'm selecting by primary key (always faster in innodb), and by innodb_buffer_pool is 6G. My test script is also only selecting 10% of the rows 75% of the time, roughly simulating normal production traffic.<BR/><BR/>Sounds like you are doing some kind of secondary index scan (hopefully it's an index!) because you are finding multiple rows per user, hence user isn't the primary (unique) key. <BR/><BR/>I find the worst thing people try to do is build their application/query in MyISAM and then give Innodb a shot by just 'alter table Engine=Innodb' w/o touching anything else and considering how innodb will behave differently from MyISAM. It's not uncommon that a completely different schema would make better sense when moving to Innodb just because of how it is different from MyISAM.Jay Janssenhttps://www.blogger.com/profile/07146539825543443554noreply@blogger.comtag:blogger.com,1999:blog-5412150273415696914.post-165057615559545122007-11-07T14:49:00.000-05:002007-11-07T14:49:00.000-05:00In response to JayCan you quote size of Wikipedia ...In response to Jay<BR/><BR/>Can you quote size of Wikipedia (number of tables, size of tables, indexes) & usage model. <BR/><BR/>Last I checked the whole Wikipedia text itself was less than 15 Gig (compressed), I am not sure how large is the database so its difficult to judge your response in comparison to the 'guy from mangalore' whose table is 24GBShirish Jamthehttps://www.blogger.com/profile/17893764367028156108noreply@blogger.comtag:blogger.com,1999:blog-5412150273415696914.post-43086271127398024132007-11-06T10:07:00.000-05:002007-11-06T10:07:00.000-05:00In response to dude from mangalore,Such generaliza...In response to dude from mangalore,<BR/><BR/>Such generalizations are typically just that: generalizations, and not particularly useful when not coupled with specifics about application usage, schema, etc...<BR/><BR/>InnoDB certainly performs very well on large installations (look at Wikipedia), so it's not as simple as you say... More likely, it is your schema or application that needs tuning.<BR/><BR/>In response to Jay,<BR/><BR/>I think what *is* fair is to have a benchmark that tests a specific workload (heavy concurrent writes, large datawarehouse, mixed environment, etc) and then tweak the engine for the best performance you can get out of it.<BR/><BR/>But, sure, you will always need to put requirements and guidelines in place for each benchmark to ensure the reader of the benchmark understands any assumptions made during the running of said benchmarks...<BR/><BR/>Cheers!<BR/><BR/>jayjaypipeshttps://www.blogger.com/profile/16581538991015419636noreply@blogger.comtag:blogger.com,1999:blog-5412150273415696914.post-10274656370771731192007-11-06T03:24:00.000-05:002007-11-06T03:24:00.000-05:00InnoDB is very slow when table size is big. We hav...InnoDB is very slow when table size is big. We have 24G table. Querying for the records of a user (having few thousdand results ) take more than a minute. Even having a limit clause is of no use. MyISAM performs muych better by more than 10 folds.Dude From Mangalorehttps://www.blogger.com/profile/11648794788677197501noreply@blogger.com