tag:blogger.com,1999:blog-9149523927864751087.post7257149461112222134..comments2024-03-26T09:43:01.052-07:00Comments on Small Datum: Write Amplification: write-optimized versus update-in-placeMark Callaghanhttp://www.blogger.com/profile/09590445221922043181noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-9149523927864751087.post-70995232441545324722014-02-28T06:23:44.502-08:002014-02-28T06:23:44.502-08:00Sunny,
Its heartening to see that finally we are ...Sunny,<br /><br />Its heartening to see that finally we are coming around to work towards reducing the number of knobs.inaamhttps://www.blogger.com/profile/05554751735187425653noreply@blogger.comtag:blogger.com,1999:blog-9149523927864751087.post-49540464212130767912014-02-26T16:29:50.047-08:002014-02-26T16:29:50.047-08:00I should have been more clear that the FB team mig...I should have been more clear that the FB team might have added a few tuning options. They are OK for us as we like to test and tune and want to help other companies get more consulting.Mark Callaghanhttps://www.blogger.com/profile/09590445221922043181noreply@blogger.comtag:blogger.com,1999:blog-9149523927864751087.post-3719831193044126362014-02-26T16:26:09.948-08:002014-02-26T16:26:09.948-08:00We are very keen to reduce the complexity around I...We are very keen to reduce the complexity around InnoDB IO tuning. I agree it takes a certain level of expertise to get it right for the given context. After the CPU fixes around transaction life cycle management the next thing on my radar is IO. It needs the same level of treatment as the kernel mutex split. Serious hard look and close to a rewrite if it comes to that. <br /><br />As usual great post, please keep them coming!Sunny Bainshttps://www.blogger.com/profile/03202312916091066986noreply@blogger.comtag:blogger.com,1999:blog-9149523927864751087.post-55648381988546448112014-02-26T16:19:48.641-08:002014-02-26T16:19:48.641-08:00I think that is a better question for the experts ...I think that is a better question for the experts at http://percona.com and http://skysql.comMark Callaghanhttps://www.blogger.com/profile/09590445221922043181noreply@blogger.comtag:blogger.com,1999:blog-9149523927864751087.post-658178734787588172014-02-26T16:16:07.980-08:002014-02-26T16:16:07.980-08:00I have a query that is a large data set needed for...I have a query that is a large data set needed for reporting purposes. Currently, the "duration" showing in MySQL workbench which I'm assuming to be execution time is about 7 seconds, so it is fairly optimized. It returns a measly 6000 rows, but it takes nearly 150 seconds to return them according to the "fetch" time.<br /><br />Now, there are over 50 columns, which may explain some of the speed, but when I extracted the data set into a spreadsheet, it turned out to be about 4MB. I'm certainly not an expert, but I didn't expect 4MB to take 150 seconds to return over the pipe. I went ahead and performed the same query on a localhost setup to eliminate networking issues. Same result! It took about 7 seconds to execute, and 150 seconds to return the data on the same machine.<br /><br />This report is expected to run real-time on demand, so having the end user wait 2 minutes is unacceptable for this use case. How can I improve the time it takes to return the data from MySQL?Anonymoushttps://www.blogger.com/profile/15001183007438989981noreply@blogger.com