Percona Live, NYC

Yesterday, Percona held Percona Live NYC, which they describe as an “intensive one-day MySQL summit.” They meant it. It was like drinking from a firehose. There was too much for me to give a complete report, so I’d like to highlight two sessions that stuck out for me.

Why SQL Wins

Sergei Tsarev (Clustrix) gave a great overview of the last 50 years of database development. He talked about the early days, in which what we now think of as database functionality had to be implemented in each application. Programmer productivity was therefore low.

As modern SQL databases emerged, productivity shot up since databases bundled up common functionality with an easy-to-code interface. This now seems like a golden age of databases, in which transactional semantics were hashed out.

Fast forward to today. Database performance has failed to keep up with database demands. Sergei didn’t talk much about why this is. Personally, I have my own take on what caused this problem. The demand side is due to the success of SQL semantics. Relational databases capture what many (most?) people want to do with a database. So they keep pounding harder on the database. On the performance side, the data structures that drive databases (B-trees) were invented in early ’70s, when computers had a very different balance of resources. As the decades went by they grew to be more and more out of balance with each new generation of hardware, creating many of today’s performance bottlenecks. And now, back to Sergei’s talk.

Sergei talked about how NoSQL was a reaction to these performance issues. He pointed out that what NoSQL does is kill off chunks of database functionality. That doesn’t make those requirements go away. It just makes the database appear to go faster — but, it’s important to note, not the system. It means that the “slow code” gets moved to the application layer. So the performance problem isn’t solved and programmer productivity goes down.

He predicts a move back to SQL solutions, as these performance problems get solved. (And since our TokuDB storage engine solves a bunch of them, I agree!)

Migrating From MyISAM to InnoDB

Matt Yonkovit (Percona) gave a very detailed talk on moving MyISAM tables to InnoDB. The audience was really into it, and the questions were coming fast and furious. As someone interested in transactional databases, I don’t think that much about MyISAM, but it was clearly on a lot of people’s minds.

The most striking thing about this talk was the contrast with Sergei’s talk. Matt did a great job of detailing all the parameters you need to worry about when running InnoDB — parameters you don’t need for MyISAM. I expected this to be the source of some disappointment. After all, databases, in Sergei’s conception, are supposed to abstract away common problems so that the application programmer can work on their problem-specific code.

Instead, InnoDB comes with a large number of tuning parameters, some of which are set by default to values that have to be changed to make InnoDB useable at all. The odd part for me is that there was a consensus in the room that the large number of parameters was a strength of InnoDB, and the lack of tunability was a weakness of MyISAM. Call me old fashioned, but this kind of resetting of defaults is computer work, not work for humans.

I came away from this talk more proud that ever that TokuDB has almost no tuning parameters. Expect this to continue. We even have the math for why this no-tuning approach works.

Loads of other talks

There were loads of other great talks — on solid state drives, on replication, on many of the topics that are critical to the care and feeding of a MySQL database. Maybe I can wrangle a trip to Percona Live London so I can report on those.

Tags: , , , .

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>