Home
Arjen's Journal
Moved to http://openquery.com/blog/

Arjen Lentz
Date: 2009-04-22 08:50
Subject: Move to Open Query blog
Security: Public
Tags:arjen, blog, lentz, livejournal, mysql, openquery

I'm shifting away from LiveJournal. It lacks ability to search and otherwise peruse archived blog posts. And of course it's only me, while Open Query has more people.

From now on the posts will be at http://openquery.com/blog/ and this is aggregated to Planet MySQL as a group blog. You may have already seen Walter posting from his seat at the MySQL Conf. All posts and comments from my LJ blog have been migrated to WordPress, thanks to magic performed by young Akash Mehta. Unfortunately the comment threading can't be exported.

The full export means that my personal posts are now also present at Open Query, although I may move those elsewhere later. The existing blog entries on LJ will stay for a while at least, although I do have to pay for the LiveJournal subdomain to keep the URLs alive.

A little sidenote on the export... it actually to considerable effort and script hacking and possibly even some screen scraping. Consider this is my own data... Remember, LJ used to have a perfect export, which actually enticed one to stay put. Funny, isn't it. But that was in the Danga days, and we're two owners down the line from that (SixApart and then the spinoff-sale to the Russians). Lock-in makes people want to leave more.

Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-04-20 23:02
Subject: Oracle agrees to buy Sun
Security: Public
Tags:mysql, mysqlconf09, oracle, sun

See Oracle Agrees to Acquire Sun Microsystems (NY Times, 20 April 2009). Wellwell, that's quite interesting, isn't it... as to what it means for MySQL, ZFS, OpenSolaris, OpenOffice.org, VirtualBox, Java, and numerous other tidbits, that remains to be seen.

It must be a buzzy kind of day at the MySQL Users Conference 2009, with this news coming in just before the opening... and it's only been a year since Sun bought MySQL and Jonathan Schwartz did a key note at the conference. I'm sure we'll hear a lot more from a lot of people, not necessarily content but definitely conjecture and pre-emptive opinions ;-)

Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-04-20 13:44
Subject: Open Query at MySQL Users Conference 2009
Security: Public
Tags:mysql, mysqlconf09, openquery

I'm not personally there this year, but Walter Heck will be. In case you haven't met Walter yet, photo enclosed ;-)

Photo of WalterHe's a techie, like you, and he'd love to meet you and hear how you're using MySQL and surrounding technologies and what things might make your life easier in terms of application architecture, development, deployment, maintenance, and so on.

This may or may not fit with the services that Open Query provides, but the key point is to listen, not sell. If there's a good match, of course that's fine too!

As a sidenote, just to pre-empt the inevitable question of "Arjen why are you not here?": flying over to the US has always been fine, but coming back is a pile of grief every time taking multiple weeks to recover. I've never had that issue with for instance trips to Europe. That's not just grief in terms of personal discomfort or lost work time, but it means my daughter really loses out on her papa for about 3 weeks.

Before I made the decision to note make the trip this year, I did enter various items into the session submission process months back - they didn't get accepted, but I'm not unique in that respect. Many well known speakers from previous years did not get a slot this year. No worries. There's plenty of things going on in the surroundings, including Sheeri's game day and community conference and Percona's performance sessions, as well as all the excellent encounters in the corridors and in the evenings.

Having been absent in 2007 as well, I would like to add a little bit of outside perspective on the event... while for this week everything appears to be focused on the conference (at least when you look at Planet MySQL), most MySQL users around the world will of course not be at the conf, and have the same needs like the rest of the year. I believe it's really important to tell about insights and developments all year round, as well as being active in the various interaction media (such as forums, user groups and events).

Anyway, have a great time at the conference, and do have a chat with Walter!

Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-04-18 09:14
Subject: InnoDB lock timeout before query execution
Security: Public
Tags:innodb, mysql

I found this yesterday while tracking down a locking issue for a client. They had a connection time out on a lock, but before it times out, SHOW PROCESSLIST had the status 'statistics' so it wasn't actually executing the query yet. So, what was it doing and why did it time out there?

The answer actually was remarkably simple, but I did have to take a peek in the MySQL server source code (horay for Open Source!) The server sets the thd_proc_info to 'statistics' when calling the join optimiser, that's the part of the optimiser that works out the best join order.

A lesser known feature of the join optimiser is that if it works out that only one row can match (lookup on primary or unique key field), it'll try to retrieve the row. If there's no match, there's an "impossible WHERE clause" and essentially the entire query is optimised away and 0 rows returned.

If there is a match, all references to columns in that table can be replaced with the values that were just retrieved, turning them into constants. After all, there's only one row matching! This can optimise away tables, removing the need to execute some or all joins. You don't actually see this directly if you do EXPLAIN EXTENDED and then SHOW WARNINGS, because that output is from the parse tree which does not know about the join structure. But what you will see there is that the columns were replaced with constants, so from that you can deduce what's going on.

For a query
EXPLAIN EXTENDED SELECT name from Country where code='AUS'
you would see access type const in the explain (which is the indicator for this optimisation), and SHOW WARNINGS brings up
select 'Australia' AS `name` from `world`.`country` where 1
so you see the WHERE clause is gone completely and the name column in the SELECT has been fed the value Australia so it's all constants.

Back to the original issue... if another connection holds an exclusive (write) lock on that particular row, the join optimiser will be waiting for the lock to be released and that's how you can actually get a lock timeout at this stage. It's a perfectly normal thing to happen.

2 Comments | Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-04-03 09:51
Subject: What a Google data center really looks like
Security: Public

Google has fessed up: apparently it looks like a bunch of shipping containers, since 2005. And it does not use the usual rack stuff or centralised backup power. See Google uncloaks once-secret server for a decent overview, plus pictures.

I think there's quite a lof of good information in there, with important lessons. Just a few:

  • It's not fancy-brand stuff, they're simple Gigabyte mainboards
  • An open frame rather than enclosures.
  • 12V battery on the frame, rather than a centralised UPS. More energy efficient, and no single point of failure.
  • Heatsinks, not lots of fans (mechanical stuff fails). There'll be airflow-creating foo for the whole container, but since it's a single enclosed space there's neat separation between hot/cold already. Efficient!
  • Two regular SATA harddisks
So, it's mostly commodity stuff in a custom frame and and other minor tidbits. There's 1160 servers per container, and by the looks of it it should work out pretty cheap to buy, build and operate.

The energy efficiency has more aspects... if you use less power, you're also generating less heat that then needs to be got rid of. Cool machines are more reliable and live longer, and even fractions of a degree can make a significant difference.

You can see it all from a monetary perspective, but it also makes sense in terms of maintenance effort, waste/disposal and other environmental impact aspects. Of course these containers still eat a lot of electricity, but there's a lot in there and it will be way "greener" than most data centers.

2 Comments | Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-04-02 09:30
Subject: The problem with April Fools in the MySQL/web space...
Security: Public
Tags:aprilfools, mysql, openquery, ourdelta

...is that truth is stranger than fiction. Reality does not appear any more plausible than plain nonsense.

We were discussing this yesterday on #ourdelta (Freenode IRC) in the context of How MySQL really executes a query by Baron. Antony Curtis noted that if he'd write a truthful post on that topic, people would think it was made-up regardless of the day of the year!

Another proof of the premise: Baron has now put a giant banner above/below his post, explaining that it was a joke. Apparently that's necessary?

I tend to come up with neat ideas for April Fools throughout the year, neglect to write them down, and come the day I have a blank. But, given the above, there's another option: you just write a truthful story, still leaving people wondering whether it's for real. I reckon the main issue is probably with the rest of the year, where lots of people still write nonsense, and the truth remains weird as usual. At least on April 1st you know to question. I hope.

1 Comment | Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-04-01 11:27
Subject: Predictive caching in a MySQL-backed infrastructure
Security: Public
Tags:mysql, openquery, predictive caching, scaling

Sounds a bit far fetched (pun intended ;-), but we're doing it. This is not inside of the MySQL server, but rather the overall application design. Let me run you through the logic...

Some key aspects to scaling are: not doing unnecessary queries, and caching what you can. Just a quick baseline. The fastest query is the one you don't do, or the one you've already done before - the latter being caching.

A simple yet brilliant example of this is the Youtube trick where a script reads the relay log, converting updates into appropriate selects and running them so that the InnoDB cache will have the blocks in memory when the slave SQL thread executes the actual update. Maatkit now has a tool for this, so it's publically available. It's not quite predictive, but it's a neat trick anyway that sometimes comes in handy. Search engines use similar tricks.

Extending on this, with certain applications you actually tell what is likely to happen next, sometimes for a particular user and often for many users. Individual user behaviour may sometimes appear random, but as a group it can be highly predictable. The analysis needs to be done properly though, otherwise averaging will make certain interesting behavioural patterns disappear.

Anyway, if you can identify these patterns you can take appropriate measures, such as do some queries so they get cached, and/or schedule other relevant actions (so it's more than just caching, but it's a reasonably suitable name anyway). This allows the app to deal with higher peak load, as well as improving response time for individual user.

I might do a talk or article on the predictive caching concept some time, as I appreciate that the short description may appear a bit abstract or obscure. But I assure you it's entirely practical and real.

It's one example of how Open Query helps its clients scale well, by design. We focus on preventing emergencies, which includes not just scenarios where stuff fails (and does a safe failover), but also the "oh dear we suddenly have so many more users than a minute ago" type of happening, which should actually be an occasion to enjoy, not stress about.

Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-03-27 11:20
Subject: Relax! A Failure is NOT an Emergency - a talk in Melbourne
Security: Public
Tags:melbourne, mysql, openquery, talk, training

While I'm in Melbourne in a few weeks for training I'm once again visiting my friends at Linux Users of Victoria (LUV). It's been a while since my schedule coincided with their meeting schedule!

I've been invited to do one of the talks (Sandrine Balbo doing the other), and my topic is "Relax! A Failure is NOT an Emergency." which is although somewhat MySQL-related not actually MySQL-specific.

This will be on Tuesday April 7th. You can find more detailed description and location/time info in the LUV announcement.

Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-03-19 21:40
Subject: Arjen also on twitter & identi.ca
Security: Public
Tags:arjen, bluehackers, identi.ca, mysql, openquery, ourdelta, twitter

If you'd like to follow shorter scribbles of what I get up to, like my work at Open Query, OurDelta and of course the BlueHackers initiative, I've got myself organised at http://twitter.com/arjenlentz or http://identi.ca/arjenlentz (you can pick one, they have the same feed).

Post A Comment | Add to Memories | Tell a Friend | Link



Arjen Lentz
Date: 2009-03-16 20:53
Subject: Open Query is now a DotCom
Security: Public
Tags:mysql

Yes, Open Query is now a DotCom. In the sense of the domain name, that is (openquery.com). It just took us quite a while to "catch" the domain off a hog that was somehow really attached to it!

Other than that, we are

  • not moving to Silicon Valley; the world is a big place with lots of beautiful places to live and work from. Different OQ people are in different such places.
  • not seeking or accepting any venture capital; self-funded organic growth works well for us.
  • not aiming to get bought, or float...
Just in case anybody was wondering! ;-)

Email to either the .com or .com.au will work, and the website simply redirects so it's zero-fuss for everybody. If you experience any hassles, do let me know.

Post A Comment | Add to Memories | Tell a Friend | Link



browse
my journal
links
April 2009
High Performance MySQL (2nd ed.)
summary