Guy Kawasaki is a prominent blogger who writes about the technology and business world, and usually has some dead-on commentary about working in the corporate world, about technology in general, and about the jungle that is the venture capital world.

Today, he published a ten-question interview with Marten Mickos, MySQL's CEO, which has some great information that shows not only the kind of person that Marten is, but also how he (and others at MySQL) view MySQL's emerging role in the enterprise DBMS community, and the open source community in general.

One of the things I really liked in the article was the following (duh, I am a community guy, after all!):

At MySQL we LOVE users who never pay us money. They are our evangelists. No marketing could do for us what a …

Guy Kawasaki has an interesting interview over on his blog with Marten Mickos, CEO of MySQL.

Here are a few gems, with my commentary:

In response to the question, "How do you make money with an Open Source product?":

We start by not making money at all - but by making users. The vast community of MySQL users and developers is what drives our business.

Then we sell an enterprise offering to those who need to scale and cannot afford to fail. The enterprise offering consists of certified binaries, updates and upgrades, automated DBA services, 7x24 error resolution, etc. You pay by service level and the number of servers. No nonsense, no special math. Enterprise software buyers are tired of complex pricing models (per core, per cpu, per power unit, per user, per whatever the vendor feels like that day) - models that are still …

In my last post MySQL Benchmarking 1, I was installing Sysbench on a Solaris 10 machine. However I stopped at

./configure

because I was getting compiler errors due to the SUNWsprot and SUNWsprot Sun OS packages not being installed.

After getting them installed on the server I tried to run the ./configure again and this time although the compile process went a little further, it stopped after throwing the following errors.

checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

Elvis has left the building, and yes we have removed the BDB engine from MySQL.

Last night I saw a blog post about the removal before I went to bed. Link to the post is here, along with my response:
http://www.webyog.com/forums//index.php?automodule=blog&blogid=3&showentry=68

Removing the BDB engine, aka Sleepycat's Berkeley database, from the list of internal engines has been on my list to do for a while. If you follow the way I went about removing it, it should be easy to transform it into a plugin now.

Why as a plugin?

Right now we don't spend energy on keeping the BDB engine up to date. Which makes us look bad, and it makes Oracle look bad. What is worse is that the BDB engine used a forked version of the Sleepycat code. The BDB engine should not be using …

I went through elementary school in the 1980s. As such, I was taught that there are winners and losers. My kids learn that "We are all SPECIAL!!!" but I quickly disabuse them of that notion at home. Kill or be killed. Eat that hamburger or your wily 15-month old sister will. The Asay house is quintessentially Hobbesian as we live out our nasty, brutish, and short lives. :-)

I'm kidding, but my 80s mentality has me wondering: with all the open source momentum (and it is real), who is losing? See, it's not possible for everyone to win together all the time. It's not exactly zero sum, but in a relatively finite market, my success may well correlate to your failure.

So who is losing?

Apparently not Oracle. Not yet, anyway. Jason Maynard of CSFB has ORCL at an "Outperform" rating, writing this morning:

For Q1, we are estimating $3.47B in total …

I'll be on holidays from the 25th of August till the 5th of September. Therefore, I thought it would be a good idea to give an update on the current status of SQLbusRT.

Coding has almost finished. With almost finished, I mean it is almost ready for the first test runs. It is still a very simple implementation. It will give me some baseline figures when I execute my first performance tests, but it does not have all the planned functionality yet.

I'm not publishing the code yet. I want to have the code reviewed by some collegues first, and perhaps it's better to wait for the results of the first test runs to see whether the taken approach is a good one.

I've finished setting up a network of computers to run my tests on. All computers run linux, with the possibility of choosing a patched or an unpatched kernel on boot. The patched kernel offers preemption. This will be used to give real time priority to the …

I was just skimming over Santos' Post about SDO, and was saddened to see more anecdotes and less facts.

Here are two points that you should take note of:

• PDO is an "ultra fast direct layer to the database".

• The benchmarks I think you're referring to do not include the magic turbo switch I talk about here, that highlights performance problems when using prepared statements, which are on by default.

I'd love to see someone run some fair comparisons and publish the numbers.

No, it’s not a bedtime story, is a serious system’s design concept and I’m amazing that people don’t know about this.
As I mentioned in If you don?t know your data, you don?t know your application I was doing a Java Code Review, and I found a clear case of a much simplier solution. How simple you ask?

Well, without completing the task 100%, I achieved in less then 1 day (and lets say for the argument 1 more day of work), what is being worked on by somebody else for a week, with an estimate of 2 more weeks to complete. So let’s add 50% to my estimate, that’s a total of 3 days verses 15 days. You do the math. and yes that was last week and that task is still being worked on the same way, even with reference to my working code. Not to mention the code is a similiar magnitude of simplicity, and simplicity means cost savings in support, people so quickly forget …

This article explains how to tune a MySQL database for use with eZ publish. MySQL is a database engine used by eZ publish to store content. While other databases are supported by eZ publish (such as PostgreSQL and Oracle), for performance reasons we recommend MySQL.

This article has suggestions for optimizing for either read or write operations, and also discusses some other optimization techniques such as DNS and filesystem configuration.

One of the things I don't see much discussion on in distributed system research is the advantage that using batching and streaming can have on scalability.

Batching

Lets cover batching first. Say you have 1000 objects you need to fetch from the database. Now lets say this time is instantaneous on the database side (which is seldom the case). If you fetch all 1000 items one at a time this will end up killing your performance. Each operation will take about 1-2 ms which isn't very long for an individual fetch but it all adds up. If this was a page load on behalf of an HTTP client it would load in the 1-2 second range with is pathetic.

If you could somehow batch these up into one operation you'd see a 1000x performance boost. Not bad. This isn't a theoretical situation btw. Memcached has a getMulti method for just this reason. Unfortunately, there is no putMulti …