Been at the MySQL conference the last few days, and I have to say, I’m really blown away by MySQL 5.5.4‘s improvements. Last year I keynoted and I begged Oracle on stage to realize that MySQL and InnoDB under one roof represented opportunity. It’s clear they heard the community – this is some serious progress, and right when we needed it.
Jeremy Zawodny’s blog post covers most of the stuff I’m really excited about, and there are some great detailed technical slides here and here, but I wanted to go into a little more detail on one important improvment: We’ve been plagued by MySQL’s undo slot limits for an awfully long time. Basically, you could have 512 INSERT transactions and 512 UPDATE transactions running at once, for a grand total of 1024. If you use INSERT … ON DUPLICATE KEY UPDATE, though, it takes two of those spots, meaning you get 512 concurrent transactions. On modern hardware, it’s trivially easy to hit this limit.
I’ve had an Enterprise support ticket open for years on the issue, there’s been a MySQL bug for a long time, and there was basically no movement. In fact, I’d gotten so frustrated about this issue, I’d basically decided this year was our last year of Enterprise MySQL support. It was one of the sole reasons we paid for support for the last few years – the promise that a fix was just around the corner. I felt good about voting with my dollars, and contributing back to a core technology we depend on, but enough was enough.
Lo and behold, it’s fixed! You can now have a whopping 128K transactions in flight. Best of all, it’s far more performant than it used to be! And craziest of all? If you run 5.5.4 on a database, then roll back to some older release, the change still takes effect. Backwards bug and performance fixing – that’s a new one on me.
THANK YOU ORACLE!
Shameless plug – we’re hiring. And it’s a blast.
Been asked a few times in the last few days about where my slides are from my MySQL keynote from *last* year.
Um, yeah. Sorry about that. Here’s a link to ‘The SmugMug Tale’ slides, and you can watch the video below:
Sorry for the extreme lag. I suck.
The important highlights go something like this:
- Use transactional replication. Without it, you’re dead in the water. You have no idea where a crashed slave was.
- Use a filesystem that lets you do snapshots. Easily the best way to do backups, spin up new slaves, etc. I love ZFS. You’ll need transactional replication to really make this painless.
- Use SSDs if you can. We can’t afford to be fully deployed on SSDs (terabytes are expensive), but putting them in the write path to lower latency is awesome. The read path might help, too, depending on how much caching you’re already doing. Love hybrid storage pools.
- Use Fishworks (aka Open Storage) if you can. The analytics are unbeatable, plus you get SSDs, snapshots, ZFS, and tons of other goodies.
- Use transactional replication. This is so important I’m repeating it. Patch it into MySQL (Google, Facebook, and Percona have patches) or use XtraDB if you use replication. We use the Percona patch.
Holler in the comments if something in the presentation isn’t clear, I’ll answer. Apologies again.
Shameless plug – we’re hiring. And it’s a blast.
I like both Adobe (Lightroom rocks!) and Apple (iPad rocks!), but I’ve been asked over and over again what I think about Apple’s new 3.3.1 policy. You know, the one that basically bans cross-platform development frameworks. And, in particular, basically nails the Flash coffin shut on iPhone/iPod/iPad. So, what do I think?
I love it.
And I’m surprised more developers, end users, business leaders, and general web standards lovers everywhere aren’t posting about how great this is.
It’s good for end users.
The App Store already has a signal-to-noise problem. With hundreds of thousands of apps, finding the good stuff is tough. Bear in mind that every single one of those Apps was built by someone intentionally designing for these devices – and we’ve still got plenty of junk in amongst the gems. Now imagine a bunch of developers just cross-publishing to lots of devices – ignoring all of the strengths of each of those devices. The signal to noise ratio gets worse, fast. Ugh.
It’s good for the web.
For me, this one is the biggie. These devices are a dual-platform: iPhone SDK and HTML. Don’t like the iPhone SDK? Build for HTML. And finally, finally, someone has stepped up and done something about the de-facto Flash monopoly. Flash has helped the web and HTML standards to stagnate. It’s sorta like a drug. It’s whizzy and slick, granted. But it’s a nightmare, too. Flash crashes constantly. Its performance is terrible (when a 1Ghz mobile processor in the iPad plays video more smoothly than Flash on a 16-core Mac Pro with a hefty GPU, that’s a problem). And it smashes through web paradigms left and right. Why? Because there’s no competition.
Look at the browser world, on the other hand. With Microsoft, Mozilla, Google, and Apple duking it out, we’re seeing a breathtaking pace of innovation. Browser stability and performance is improving at an astonishing rate. There’s no reason Flash shouldn’t be super-stable and fast by now – but it isn’t. It’s like the Internet Explorer doldrums all over again – Flash is holding us back, just like IE used to. I’d rather be building for something with a scary fast pace of innovation than something stale.
The iPad is already spurring HTML5 adoption even faster than before. Witness all the video and games sites that are already scrambling to announce and ship their HTML5 interfaces. Bring it on!
I want to build for the web, not for Flash.
It’s good for developers.
And by that, I mean “good developers.”
Good developers are language agnostic. They’ll write in whatever language is worth the effort.
Good developers love great toolsets and great platforms. The iPhone SDK is amazing.
Good developers want their creations to be perfectly tuned to their purpose. The iPhone/iPod/iPad interfaces demand and deserve lots of individual attention, not to be marginalized by some middleware cross-platform publisher.
Good developers want their products found and used. The App Store signal-to-noise issue is a daunting one – more shovelware won’t help.
Good developers want a stable community, with lots of advice, sample code, libraries, etc. A fragmented development landscape prohibits that – a unified one encourages it.
I could go on – you get the point. Best of all? It weeds out poor developers. And if the iPhone SDK and HTML5 aren’t your thing – go build somewhere else. I’m sure there’ll be another computing revolution in a decade or two that you can ignore yet again.
(and if you’re a good developer – we’re hiring and we’re having more fun than you can possibly imagine)
It’s good for Apple.
They get better apps. Happier end users. More productive good developers. Fewer bad developers. And, of course, they make more money. They did invent the software, devices, and App Store, afterall. Why should they marginalize themselves out of their own business?
It’s even good for Adobe
Granted, not quite as good for Adobe as having Flash on these devices. But lets not forget that Adobe has a stable of great applications, like Illustrator and Photoshop, which aid iPhone development. Their sales will still boom.
Finally, Adobe is incentivized, finally, to actually improve Flash. I’ll bet if Adobe actually made Flash stable, fast, and power efficient, it could get added to the iPhone for use in-browser. It’s not like Apple enjoys seeing half rendered web pages in their browser – they just enjoy customer complaints about crashing and poor performance less. Believe me – I know all about customer complaints due to poor Flash behavior.
But that window of opportunity is closing – the owners of those web pages don’t enjoy their stuff being half-rendered either. They’ll rush to fix that problem – without Flash – if Adobe doesn’t fix it for them.
So there you have it. Thanks, Apple, for doing what’s best for the web, your customers, and developers like me. The future is bright. Long live web standards!
(this post written on an iPad in WordPress’ excellent app)
I understand many disagree, and have their own reasons. Go write for Android, another great platform that’s more open. Maybe if you do, Android will ‘win’. I think you’re confusing platform choice and development choice here. Personally, I’d love to have more platform choice. Who wouldn’t? But Apple did invent this thing. They certainly deserve to make whatever decisions they want about it. If you’re right, and I’m wrong, those decisions will kill the platform. I happen to think I’m right, and I happen to think Flash needs to seriously improve – and the Apple’s the only way that’s gonna happen.
Note that I don’t have an opinion on things like MonoTouch, which I know nothing about. It could very well be that Apple painted with too wide of a brush here and excluded some things that should really be included. I just don’t know. I do know, though, that history has shown that cross-platform languages and frameworks have an abysmal success rate. The last thing we need is watered down apps built for the lowest common denominator.
Finally, yes, SmugMug uses Flash. I’m sure we’ll continue to use it. Like I said, it’s slick and whizzy and like a drug. We used it because it was the only tool for the job. Adobe did a great thing with their h.264 support, and we love our Flash apps – when they work. But it’s been awfully frustrating to watch Flash continue to crash and perform poorly for our customers, especially because Adobe doesn’t seem to care. They certainly don’t respond to us when we ask for help, and they certainly haven’t fixed their issues with multiple releases. I’m hopeful that this sudden pressure and increased competition will cause them to bring Flash up to the level of their other superb products like Lightroom. If not, you’ll certainly see us move away from Flash as HTML5 support and performance continues to improve, just like everyone else on the web. We can play Quake II in HTML5, for heaven’s sake!
Steve Jobs on Adobe. Amen, brother.