Xaprb

If you haven’t seen it, Josh Berkus has a very concise way to look at the confusing mess that is database “clustering” from the point of view of three distinct types of users: transactional, analytic, and online. I think that using this kind of distinction could help keep discussions clear — I’ve seen a lot of conversations around clustering run off the rails due to disagreements about what clustering means. MySQL Cluster, for example, is a huge red herring for a lot of people, but it seems to be a difficult process to learn it well enough to decide. If we called it a clustering solution for transactional users, but not for analytic or online users, it might help a lot.

Ever been around a group of people discussing some technology and heard Cool-Whip phrases like this?

It’s not about MySQL versus PostgreSQL, it’s about using the right tool for the job.

Or how about this one?

You need to take the important factors into account before you decide whether [hot new fad] or [trusty old solution] is best suited for your application.

Both are signs that someone might be trying to sound important. In situations like this, I’ve noticed that the people I look up to usually don’t make weighty-sounding statements about other people’s systems. They talk about what they are qualified to talk about: either they say something about their own systems, or if it’s warranted and invited, they ask intelligent questions about other people’s systems.

People who only have vacuous generalities to contribute don’t talk about their own systems, because if they actually worked on systems that qualified them to contribute to the conversation, they’d have something of substance to say. And they don’t ask questions, because they don’t know what to ask. (The third option — say nothing — seems unacceptable, I guess.)

For the love of all that is good, please do not look back through my blog archives. I don’t want to know.

I was at OpenSQL Camp 2009 in Portland last weekend. I thought the event was very well done. On Friday we had a pizza party at Old Town Pizza, which was awesome. Saturday and Sunday were breakfast, sessions, lunch (yum), and sessions and hacking. These were held at souk, a co-working space. After 5PM, people got together for dinner, beer, etc.

I presented on mk-query-digest — a live demo of features requested by the audience. Sessions from others that I thought were particularly good included ones on CouchDB and MongoDB. I mixed up the time and missed the session from Tokutek on how fractal tree indexes work. I’ll try to watch the video if that one was taped.

During the hackathons, Daniel and I worked on Maatkit. We are laying groundwork for a more powerful mk-query-digest.

As you may know, I created OpenSQL Camp. But I was not involved in organizing this or the previous event in Germany, which I think is great. I talked briefly with Eric and Selena about seeing if we could put together a recipe to make the process easy for folks to organize their own. We should be able to lay out checklists and timelines of major things — location, shirts, sponsorship, budgeting, food. Eric and Selena got great food, much better than the Panera catering I had for the first event. Those kinds of decisions and results should be recorded. It would be great to be able to treat it like a franchise so anyone could just add water and make their own.

I also might be willing to help organize another on the East Coast, perhaps as soon as next year if I can reduce my workload enough to have the time. I’d probably want to do something in or near Washington DC, which is a more convenient location with better public transport than my hometown of Charlottesville.

It all started out as a response to complaints about MySQL’s annual conference not being a user’s conference, but nobody actually doing anything about it. I decided to do something about it, in a more inclusive way. And judging by the attendees and talks at the two I’ve gone to, people were happy to say yes to that. I think if there are continued events, that’s the ultimate measure of success.