I spent a half-hour this morning talking with Lance Walter, VP of Marketing for Pentaho, a leading open source Business Intelligence vendor. I wanted to see if Pentaho's experience in the market matches up with what other open source application companies are seeing.

Indeed. The good news of open source goes well beyond any one particular vendor.

Question: I hear good things about Pentaho all the time. Can you give me a high-level update?

Sure. First off, you may have seen the news that we did a big competitive replacement of Crystal Reports at Boyne Resorts the largest family run four-season resort company in North America. We also just closed a deal …

I love Marten Mickos, and it is quotations like this in a Computerworld interview that reinforce my respect for him. Asked whether MySQL would ever go partially proprietary in order to get a higher download-to-sale conversion rate, Marten replied:

We've had that debate many times. I think we might win a few new customers, but we would lose 2 million users. We're not ready for that kind of compromise. We also look at other companies who have built closed-source products on top of open-source ones. They don't seem successful.

I think we are well protected against predatory behavior by our competitors. When you download MySQL, it's just GPL code. But the code is owned by us. We have the copyright, we determine what goes into it, we put in the bug fixes. There's nobody else with that core skill.

Secondly, …

One interesting solution to scalability and HA is to implement a circular master-master replication setup directly on the frontend servers. Obviously there is a reasonable limit as to how many servers you can have in such a ring, since the lag with which changes propagate will increase linearly as you add more servers to the ring. However according to an article by Giuseppe a 10 server ring is reasonable. Especially if you make your sessions sticky on a per frontend server basis, you actually have an elegant solution against the old issue of replication lag, where a user does not see changes he has made in subsequent requests, since his changes were written to a remote master server which have not propagated to the slave he is reading in the subsequent request. Latency should also improve as you do not have to open up a remote connection in the …

So, how do you get more free time? Simple, you quit your job. I did. Yes, seriously.
Well, I was employee#25 at MySQL AB (from August 2001), that's nearly 6 years - I reckon I've done my time ;-)

What's next? That's not really the point, I haven't taken another job elsewhere.
For starters I'm taking a few months off, spending more time with my wife and daughter, getting more exercise, and catching up on some other stuff.

Here's a three interesting interviews with Marten Mickos, Brian Aker and Gary Whizin, all from MySQL.  Marten is the CEO, Brian is Director of Architecture and Gary is Director of our Enterprise tools team. 

It's an interesting juxtaposition to see the range of topics across all three.  Marten talks about the business model, Brian's focused on storage engines and Gary is all about building the right team.  But the common thread across all three is how important open source is to what we're doing at every level. Here's a quick test... see if you can match the quotes below with the right person.  No matter how varied the …

MySQL Toolkit distribution 620 updates documentation and test suites, includes some major bug fixes and functionality changes, and adds one new tool to the toolkit. This article is mostly a changelog, with some added notes.

Many of the tools have matured and I just needed to make the documentation top-notch, but there's still a lot to be done on the crucial checksumming and syncing tools. Time is in short supply for me right now, though. In fact, I actually finished this release on June 22, but wasn't able to release it till just tonight!

Just a quick heads-up - I just commited a change to the Planet MySQL code that slightly modifies how the RSS feed is being created: now the author name is put in front of each posting's title, similar to how many other feed aggregators mark the different articles. I hope you find this change useful, let me know if you experience any problems or have any other suggestions for improvements. Thanks!

What does working with large data sets in mySQL teach you ? Of course you have to learn a lot about query optimization, art of building summary tables and tricks of executing queries exactly as you want. I already wrote about development and configuration side of the problem so I will not go to details again.

Two great things you’ve got to learn when working with large data things in MySQL is patience and careful planning. Both of which relate two single property of large data sets - it can take hell a lot of time to deal with. This may sound obvious if you have some large data set experience but it is not the case for many people - I constantly run into the customers assuming it will be quick to rearrange their database or even restore from backup.

You need …

Currently I need to move a bit of data around. I like to use Kettle for this type of work rather than writing custom scripts for a number of reasons (which I won't discuss here).

Anyway here is a quick tip I want to share with whomever it may concern. It is not rocket science, and many people may go "duh!" but I hope it will still be useful to others.

Quite often, you need a batch task, like truncating a set of tables, deleting data, dropping constraints etc. In kettle, you might model this like a job. In this case, each separate action can be modelled as a step of the job.

The following screenshot illustrates this approach:

So here, each step is just an SQL statement that performs exactly the task you want and the steps are connected in order to …

I just wanted to point everybody at a recent blog post by Konstantin. In the post he discusses a solution for dealing with cache invalidation issues of very large caches under heavy load. He points out that cache invalidation can severely bog down the system. The general solution he proposes is to simply deactivate the query cache entirely during invalidation. I think this is an important caveat to be aware of and actually he is asking for feedback if this "solution" is acceptable. I think its awesome that MySQL engineers are giving us the opportunity to provide feedback on such changes. Maybe there should be a dedicated "pipeline" where such requests could be found?