Google senior systems engineer Jeremy Cole is once again teaming with LinkedIn senior software engineer Davi Arnaut for two InnoDB-focused sessions at the upcoming Percona Live MySQL Conference and Expo 2014 this April 1-4 in Santa Clara, California.

The duo will present “InnoDB: A journey to the core II” on April 2 and “InnoDB: A  hands-on exploration of on-disk storage with innodb-ruby” on April 4. Based on Jeremy’s InnoDB blog series, both sessions will be a continuation of last year’s Percona Live 2013 lecture, “InnoDB: A journey to the core” (the slides are available by following that link).

Tom: Jeremy and Davi, your sessions seem to be evolving based on the success of last year’s presentation. What prompted you both to expand that talk into two more this year?

Jeremy: Last year in “InnoDB: A journey to the core” we wanted to give a very thorough talk but we were pretty time limited. In private sessions of a similar nature, we usually allotted 2 hours for the talk and often went another hour with questions. We had to cram pretty hard to get everything we wanted into the session, and left out a lot of useful demos and digressions.

Davi: Apart from giving us greater time flexibility, it allows for an expansion and more comprehensive overview of the topics. Last year’s talk was focused on the on-disk structure of indexes and included only passing mentions of innodb_ruby. This time we will dig further into innodb_ruby and also cover the on-disk structures associated with logging and recovery in InnoDB.

Tom:  Why did you decide to focus on redo and undo logs in your April 2 session? And what specifically about them will you explore?

Jeremy: Largely because we completely left them out of last year’s talk for lack of time. Redo and undo logging is often misunderstood and sometimes even mixed up with binary logging. They aren’t so complicated though, and a better understanding of them would be very beneficial to many DBAs.

Davi: The redo and undo logs are essential components to a functioning database and central to ensuring data integrity, yet its inner workings are often overlooked. We aim to provide an in-depth overview of the internal structure and organization of the logs, which should help DBAs acquire a greater understanding what for and how these logs are used for things ranging from crash recovery to hot backup.

Tom: How did the April 4 session come about? And what will it focus on specifically?

Jeremy: I really wanted to give a demo of some of the amazing stuff that innodb_ruby can do. We’ve put a lot of work into it now, and it has an almost complete view of everything stored inside InnoDB. I think people can put it to a lot of good use, and I’d like to show them how. I also hope to have a little fun with the audience — wait and see!

Davi: The innodb_ruby tool has evolved greatly in the past months, deserving an increased prominence. The tool now offers a wide range of new features such as data dictionary support and cursors for searching or traversing indexes, which we hope will excite and challenge the audience.

Tom: Who should attend your two sessions and what do you want them to walk away with at the end of each?

Jeremy: Really, although the topics are pretty advanced, anyone who is using InnoDB in a serious capacity could probably learn something. I’d love them to leave with a better working knowledge of the mysteries of InnoDB. The next time they see a weird message in their log they’ll be able to say “I know what that actually means!” rather than “WTF?”.

Davi: Anyone looking to explore and improve their understanding and background knowledge of InnoDB. Attendees will likely be more informed in the future when talking about or dealing with InnoDB’s logging and recovery. Some will hopefully even become interested in contributing to innodb_ruby.

Tom: Do you have any homework for folks planning to attend them?

Jeremy: Reading my entire series of blog posts at blog.jcole.us/innodb would be a great start. Since innodb_ruby is open source, they could try installing it and playing around with it a bit (perhaps while following along with the blog posts).

Davi: Glancing over last year’s slides certainly helps in providing context and insight into the topics to be discussed.

Tom: How did you come up with the initial idea for this series on InnoDB for Percona Live?

Jeremy: Basically out of necessity. We did so much original research on InnoDB to build our understanding that we had to share it.

Davi: Exposing these topics to a wider audience can yield huge benefits to the community, and as the saying goes “given enough eyeballs, all bugs are shallow”.

Tom: How did you both come together on these sessions?

Jeremy: Davi and I worked together at Twitter and initially began our InnoDB exploration to solve some very specific problems. While we have both moved on from Twitter, we still very much enjoy working together, and we do on an almost daily basis. Aside from continuing to collaborate on our InnoDB explorations, we’re good friends.

Davi: We ran into a storage efficiency issue that required a closer inspection and knowledge of InnoDB’s storage format. At the time there was no way and no tool for inspecting and visualizing size and fragmentation information for table data and indexes, thus the need for research and development of innodb_ruby. Later, it allowed us to explore and identify some bugs, including bugs we were looking for and others we weren’t expecting.

Tom: Why innodb_ruby? Why Ruby?

Jeremy: Davi initially thought it (and by virtue, I) was crazy trying to implement InnoDB data structures in Ruby, but happily it has turned out to have been (in our opinion) a very good idea. In the end it doesn’t matter that it was Ruby — it could’ve been Python, Perl, PHP, or even Javascript. The key was that it be done in a language substantially different than InnoDB itself, and ideally much easier to develop in than C or C++. This forced us to really understand the InnoDB code to re-implement the data structures, which is always a very valuable learning experience.

Initially Davi tried the obvious thing: hacking something together using the actual InnoDB code. At the same time, I wrote an InnoDB page reader in C++ from scratch. They both proved difficult to develop and slow to make progress on, which also made them a lot less fun to work on. So I (very) quickly hacked together a copy of my page reader in Ruby and it has since morphed into the full innodb_ruby project.

Additionally, against some odds, Ruby has proven to be a very efficient (for the programmer — but horribly inefficient at run time) and flexible language for working with InnoDB data.

Davi: Hum, I don’t mind Ruby… anything but JavaScript.

Tom: Are you guys planning a Part III for Percona Live 2015?

Jeremy: I hope so! It mostly depends on the audience’s appetite for it and our ongoing research. We’re also still working on refining the format and delivery of the material. And of course, MySQL is changing all the time.

Davi: Certainly, and perhaps even expanding to other (often unexplored) topics such as InnoDB locking internals. I wish there was a greater focus on internals related topics at the conference. We need more people with MySQL internals knowledge.

Tom: Jeremy, you’ve had an illustrious career up to this point – all related to MySQL. Prior to Google, you were an early employee at MySQL, organized and led the MySQL Geeks at Yahoo, and at Twitter you built and led the DBA team. How did you get interested in MySQL?

Jeremy: Illustrious? I don’t know. It’s been a lot of hard work, and mostly accidental. I owe most of my successes to my teammates, and I’ve made a lot of mistakes along the way. I originally got into MySQL by using it at a couple of web development startups. Of course I hit bugs, I saw typos in the manual, I needed features that weren’t there.

I joined the mailing list, and at first started sending fixes (not even diffs!) for easy stuff, especially in the manual. Those fixes were often accepted quickly and I came up to speed on the proper Open Source etiquette of emailing diffs, and since this drastically reduced the work required by the recipient, I got a lot bolder with changes and sent bigger and bigger diffs. I eventually realized that working there would be fun and make things easier, so I asked Monty, and then the real adventure began.

Tom: Davi, same question to you.  Your career has also been immersed in MySQL. Prior to joining the MySQL development team at LinkedIn, you were a lead software engineer in the MySQL development teams at Oracle and also at Twitter, where I assume you worked with Jeremy. What is your MySQL story?

Davi: Right after college I was looking for a (open source related) job and MySQL had a few job openings at the time. After some interviews and fixing a couple of bugs, I was hired into the runtime team (responsible for locking, SQL parsing, prepared statements, stored procedures, etc) and started working on bug fixing for the then upcoming MySQL 5.1 release. This continued for a few more years as focus shifted to the 5.5 and 5.6 releases. I literally spent years fixing bugs in MySQL (such as infamous MySQL Bug #989) and this allowed me to gain intimate knowledge (and perhaps hatred) of various MySQL components.

Tom: Did either of you have a specific mentor who made a difference in your career path?

Jeremy: I don’t think I’ve had a single overarching mentor, but rather a series of them who all contributed a small part. I wrote up my story and named a few names on my blog when I was awarded the MySQL Community Contributor of the Year 2013 but overall I try to learn what I can from everyone I encounter. In recent years I have learned an awful lot from (and with!) Davi.

Davi: My current career path is in large part thanks to the great people I worked with at MySQL. They were and have been awesome colleagues and friends that taught me the nuances of working on MySQL. Working with Jeremy in particular has been a great experience.

Tom: What other Percona Live sessions are you interested in attending?

Jeremy: Aside from actual sessions, one of the things I look forward to most each year the social aspects: This conference is the only place where nearly every other member of the MySQL community comes together all at once. I am excited about Oracle’s participation and their sessions about MySQL 5.7, and the many talks from those who have deployed MySQL 5.6 in production.

Davi: Sessions from the Twitter and Facebook teams are a must as usual and I’m eager to hear more about the new developments happening in Oracle MySQL and MariaDB. The session about how GitHub manages MySQL also sounds interesting.

Tom: Jeremy and Davi, thanks very much for your time and I look forward to seeing you in April!

Jeremy: Thanks for the opportunity! I am definitely looking forward to the conference, too!

Davi: It’s my pleasure.

The post Engineer duo from Google, LinkedIn join again for InnoDB talks appeared first on MySQL Performance Blog.