kaj on SWiK

MySQL?s cloudy new database project

Wed, 23 Jul 2008 08:50:45 -0700

When Sun acquired MySQL and announced that it would invest the resources necessary to position the open source database for mission-critical deployments, I think everyone assumed that the database would eventually become bigger and heavier.

Few would have predicted that we would also see a project that would make the database smaller and lighter, but that is exactly what Drizzle, a new project from Sun’s MySQL director of architecture Brian Aker, is all about.

Drizzle is taking a back-to-the-drawing-board approach to refactoring MySQL by ripping out much of the additional enterprise functionality that has gone into it since version 4.1 and focusing on the demands of a core set of applications.

As Brian explains : “Stored Procedures, Views, Triggers, Query Cache, and Prepared Statements are gone for now. The field types have been simplified and there is an open debate about the SHOW commands (I am falling into the camp that think they may just belong in the client application but not in the server). Will any of this go back in? It is hard to say. The goal right now is to target a certain class of applications/developers and see if this is useful. As an example:

1) Web based apps.
2) Cloud components.
3) Databases without business logic (aka stored procedures).
4) Multi-Core architecture.”

The project also has a more community-centric development philosophy, although it is not clear from the FAQ what the copyright implications are for would-be contributors.

Brian announced the project with the caveat that it is “not looking to be 100% compatible with MySQL” and “certainly not a replacement for MySQL” which is important to consider, but the project clearly has the blessing of MySQL CTO Monty Widenius who has stated that “Drizzle solves many of the problems that MySQL’s development has had for years.”

Among the benefits noted by Monty are:

* “It opens up MySQL development for the community; You no longer have to wait years to get your patches and reasonable extensions into the server.

* Critical bugs that have existed for years can finally get fixed as the development is no longer constrained by unrealistic release schedules that put artificial constraints on things that can be fixed.

* Drizzle will put some MySQL server differentiation on a true test; A bit like Fedora does to Red Hat.

* Drizzle has created new excitement in the MySQL developer community; A lot of people seem to be very enthusiastic to work on it in a true community-oriented manner.

* Developers working on Drizzle is doing drastic refactoring of the server, something that MySQL planned to do years ago but never happened.

* Development decisions is again driven by people that are using the server daily; This will ensure that Drizzle will be faster and more stable than what can be done with current MySQL development model

* Drizzle will target the MySQL core users, the web users, whose requirements have been ignored for years while the core MySQL developers have added features that they don’t need.

* In addition Drizzle will include the latest InnoDB code; You don’t have to wait for MySQL 6.0 or go to the trouble of annually downloadoing and installing the InnoDB plugin from Oracle just to get access to the latest and fastest InnoDB version.”

It is interesting to see Monty mention Drizzle as a potential Fedora-like project, especially given his link to ProvenScaling’s publication of MySQL sources and binaries and a blog post from Peter Zaitsev wondering whether it makes MySQL Community redundant.

It would be wrong to claim that as an official endorsement, but MySQL is clearly not trying to discourage community-led projects while it has also moved its sources to Bazaar and Launchpad to (as Kaj Arno puts it) “expand our external contributor base”.

All in all it is fascinating to see that MySQL, which many would consider one of the more mature open source projects, continues to evolve and experiment, especially now it has more freedom to do so as part of Sun. As Monty says:

“Drizzle is one of the good things that have been made possible by Sun acquiring MySQL. Brian has been working on Drizzle with the blessing and encouragement from Sun’s upper management. We are finding Sun to be open and encouraging of innovation, this has been a good aspect of the acquisition.”

MySQL 6.2 is GA, but 5.1 is RC and 6.0 is alpha

Fri, 23 May 2008 21:13:58 -0700

MySQL’s version numbering is getting harder and harder to understand. In fact, it’s getting surreal.

Let me state up front that there’s probably a lot I don’t know here. But if I don’t know, how on earth can the general public figure it out?

Before we begin, let’s define terms: GA is completely done, ready for use. RC is a release candidate: don’t change anything, just fix bugs because we’re charging towards a release here. Beta is possibly unsafe code, use at your own risk. Alpha is known to have significant bugs, but if you’re curious please play with it.

Now for the releases/versions game. Let’s recap:

5.0 has version numbers that leapfrog each other in features and functionality. SHOW PROFILES — now you see it, now you don’t.
5.1 has been “… released to general availability [as] a near-final release candidate,” whatever that means.
5.1 has just had drastic changes in the RC stage. (Remove Federated in 5.1.24, remove RENAME DATABASE, remove Cluster.) And it’s going to have more changes before it’s released, too: Federated will be added back in 5.1.25.
5.2 doesn’t exist. Last year at the MySQL conference, someone made an abrupt decision to skip 5.2 and inflate the version numbers to 6.0, which has big changes in the query optimizer and other areas.
6.0 is alpha, but it includes Falcon, which is beta even though Falcon has extremely bad bugs that its developers claim are not bugs.
6.1 doesn’t exist as far as I know.
6.2 not only exists, but it is GA. Not only that, but it just… appeared as GA, as far as I know. No RC stage, no nothing — at least, nothing on the MySQL website that I see (certainly no manual version). It went from nonexistent to GA instantaneously as far as I know. It was created by extracting the Cluster code from 5.1.
6.2 is GA, but 5.1 is RC.
6.2 is GA, but 6.1 doesn’t exist as far as I know.
6.2 is GA, but 6.0 is alpha. (Hopefully you see the pattern here.)
6.2 is GA, but presumably does not include the changes made in 6.0, since it was derived from 5.1’s code.

What is going on here?

How is this an improved release model? What is improved about this?

How in the world can anyone figure out what versions of the software have what features? Who can make an educated decision about what product to use in this situation? Are people supposed to just rely on the sales people to help them figure out what to use? Boy, is that trusting the fox to guard the henhouse.

Why didn’t they just release 5.1 Cluster as GA separately, if that reflected the reality in the code? They certainly missed an opportunity to show some progress on 5.1. As it is, 5.1 got robbed of its chance to have at least some of its code go GA after more than 2.5 years in development. Now 5.1 looks like even more of an embarrassment — hey 5.1 team, how come you can’t get anything out the door when these 6.2 people are releasing GA products? Not to mention 6.0 — you guys look bad now too! (Just kidding.)

I tried to draw a timeline of MySQL’s release history, in some detail in the 5.0 history and in very basic detail in the 5.1 and 6.0 and 6.2 trees. You can take a look at that. It’s worth studying for 5 minutes or so, even though it’s kind of ugly. There are lots of oddities to notice about it. Enjoy:

The inmates are running the asylum. This gets more and more amusing as time goes on.

humor, Kaj Arno, mysql, MySQL Cluster

MySQL licensing redux

Wed, 07 May 2008 05:12:18 -0700

After all the fuss it appears that MySQL will be remaining open source after all. As Kaj Arno and Monty Widenius report, Marten Mickos announced at CommunityOne that the MySQL Server will stay open source, as well as the forthcoming encryption and compression backup features, which MySQL had considered making available only to paying customers.

“The change comes from MySQL now being part of Sun Microsystems. Our initial plans were made for a company considering an IPO, but made less sense in the context of Sun, a large company with a whole family of complementary open source software and hardware products,” writes Kaj.

“My hope is that the experiment when it comes to closed source extensions developed by Sun is now ended. As far as I know, there is no existing plans for any closed source extensions to the MySQL server,” adds Monty.

While that seems pretty clear cut, there is still room for a little confusion. Kaj writes: “To financially support MySQL?s free and open source platform, we have a business model which allows both community and commercial add-ons, and we remain committed to it.”

Monty clarifies: “I interpret this, in the context of Mårten’s and Jonathan’s announcements, that we will continue to support and make available commercial addons to the MySQL server from third party, like the Infobright storage engine. Things that we develop ourselves at Sun, at least on the server, will continue to be open source.”

UPDATE - The phrase “at least on the server” is revealing, however. Matt Asay points out that MySQL will continue to develop commercial add-ons above the server, which is the direction as I understand it, and - as I noted two weeks ago - has been the direction for some time. - UPDATE

While we’re on the subject of MySQL (again) it’s also worth taking a look at the slides (PDF) from Monty Widenius’s “Future Design Hurdles to Tackle in the MySQL Server” presentation at the recent MySQL Conference and Expo.

The slides provide a fascinating insight into the technical challenges Sun and MySQL face in positioning MySQL for wider adoption, as well as evidence of the intention to be more open, both about the nature of the challenges and in accepting more contributions from outside the company.

As slide 18 states, the fact that the MySQL community is not currently contributing to development means that the project is not benefiting from the experience of real-world users and that the user base is growing slowly.

The suggested solution is to open up the development process to give outside developers commit and decision rights and to learn from how PostgreSQL is developed. I previously wrote that “if MySQL does choose to develop closed source extensions to the GPL code it will probably have to find some way of balancing that with providing more value to the community.”

It would appear that the development of close source extensions is no longer an issue, but that providing more value to the user community remains a priority. Sun has gained a lot in acquiring MySQL, but one thing it hasn’t gained is an understanding of building a wider developer community. In fact, MySQL has a lot to learn from Sun in that regard - both its successes and its failures.

Kaj Arnö’s blog

Sun, 11 Feb 2007 07:45:27 -0800