On Falcon and the need to feel wanted

MySQL has a new section on their site about MySQL 6.0, which they are now calling “ready for pre-production testing”. I’m not sure when this section appeared, but I don’t spend much time on the MySQL site outside of the manual and downloads sections. Browsing around this new section I found a real gem: “Top Reasons Falcon is Cool” (or, as alternately titled on the page itself, “Top Reasons to use Falcon for Online Applications”1 … did someone forget to rename one or the other?). This page gives a top ten list2 of reasons why one should consider using Falcon, the new “not an InnoDB replacement, not at all!” but “really, you should try migrating your InnoDB application to it” storage engine.

I do think that Falcon will eventually be quite interesting, and it will hopefully have a bunch of nice tricks and whatnot, but MySQL’s marketing folks are really pushing it way too early and losing a lot of credibility in the process. Do they not realize we (as MySQL users) and a lot of others (as analysts, Oracle, DB2, and yes, even MS-SQL users) are laughing at them? I know it’s hard work to come up with 10 things sometimes, but if you get stuck at 7, make it a “Top 7” instead of a “Top 10”. Don’t add a bunch of crap to fill it out. There are some minor chuckles in the first 7, but here’s the last 3, with my commentary:

8. Simplified Configuration

There is no complexity whatsoever in terms of configuration as only a handful of variables exist to control the behavior of the Falcon engine.

Hmm, s/bug/feature/ and you’re done! It’s so easy to configure!

9. High Availability

Extreme degrees of high availability are easily accomplished for a Falcon-driven system by using either MySQL replication or supported third-party high availability solutions such as DRBD.

This has nothing to do with Falcon, whatsoever.

10. Parallel Execution

Falcon’s design takes advantage of multi-core systems to provide parallel execution of user and service threads. Falcon uses fine-grained multi-threading to increase parallelism with locking on internal structures being done at a low level. In some cases, two threads can change different attributes of the structure at once, because the attributes are separately lockable.

Yay! Awesome! Parallel execution! It’s finally here!!!

Oh, wait, they don’t mean parallel execution of queries they mean parallel execution of internal threads. That’s nothing new, and InnoDB is already doing that. Maybe Falcon has finer-grained locking and can do this better, but that doesn’t make for a big bold title of “Parallel Execution”.

Come on, folks. Try harder.

1 Who else gets a headache from American rules for capitalization of titles?

2 How trite, yet another top ten list.

Netflix pricing disparity

I’m a little confused as to the unit pricing for Netflix. Their “unlimited” plans are as follows:

  • 1 at a time = $8.99/mo = $8.9900 each
  • 2 at a time = $13.99/mo = $6.9950 each
  • 3 at a time = $16.99/mo = $5.6633 each
  • 4 at a time = $23.99/mo = $5.9975 each
  • 5 at a time = $29.99/mo = $5.9980 each
  • 6 at a time = $35.99/mo = $5.9983 each
  • 7 at a time = $41.99/mo = $5.9985 each
  • 8 at a time = $47.99/mo = $5.9987 each

Clearly the best deal is the 3-at-a-time plan, but why give the customer a slightly worse deal for each level they go up? Currently, upgrading to the 4-at-a-time plan has quite a premium, $7, for the additional movie. Each additional movie after that is a negligible but still annoying bump in price. The 6-at-a-time plan is the worst deal, since you can get two 3-at-a-time plans for $2.01 less per month.

Going to MySQL Camp II, Brooklyn, NY

In case you live in the dark ages (that is, before RSS) and haven’t heard, MySQL Camp II is next week at Polytechnic University in Brooklyn, NY. Sign up and head over there, slackers!

I will be there to talk about Proven Scaling, HiveDB, DorsalSource, and much more! Send me a note if you’d like to meet up or talk about something specific. I will also have ample Proven Scaling bottle openers (photo thanks to Colin Charles) to be distributed!

On serving two markets and mistakes

Zack Urlocker wrote an article today on InfoWorld titled Serving Two Markets where he comments on Matt Asay’s The open-source community’s double standard on MySQL (which is a piece of work itself) and says:

Part of the issue is that often discussions about the business of open source is seen as a “zero sum game” between community users and paying customers, meaning that in order for one group to benefit, the other group must lose. To me this polarizes the discussion in an unhealthy way.

I have to admit, I haven’t seen it that way at all. And I don’t see why anyone would. When RedHat split into Fedora and RHEL, I evaluated the design of the split and said “OK”. It made sense to me. These days, I use Fedora quite a bit for personal projects, desktop machines, toying around, and testing the newest things. On the business side, I often recommend RHEL1 to customers because it “just works” and has proven itself to be quite stable. RedHat produced not one, but two products I found to be useful for different purposes.

With RedHat, there was absolutely some discontent initially—largely from the casual users who didn’t understand the RHEL issues anyway, whining because something was being “taken away” from them. Nonetheless, the split has been by all accounts highly successful. Nothing was in fact taken away from the community, actually I think Fedora is much stronger and more promising now than RedHat ever was. At the same time, they’ve also managed to appease the commercial side of things with RHEL being a fantastic and very stable server OS.

When MySQL originally discussed the split into Community and Enterprise with me, I told them all of my concerns, which apparently were in large part identical to the concerns of several other key MySQL players that they asked. Nonetheless, they went ahead with things exactly as they had discussed, with none of our concerns addressed or even acknowledged. One of the key concerns we all had was actually not that they were taking anything away from Community. Rather it was that the release structure between Community and Enterprise made no sense for Enterprise. That is, we were (and still are) concerned that MySQL is spinning its wheels and not creating a useful product we would buy or recommend our customers to buy. And I, at least, told them as much.

Jump forward to the most recent announcements. Once again we got an early look at the changes, and once again, we voiced our concerns. This time it basically amounted to “Is taking away the Enterprise source supposed to convince people to buy Enterprise?” Their answer was “Yep”. Our only response could be “Uh, good luck with that.” Once again, our concerns mostly centered around whether the Enterprise product made sense, and once again we said that it didn’t. We told them flat out that a single person mirroring the code would nullify all the “force people to buy” effects of their removal of the source, while nullifying none of the good will they lose by hiding it.

The issues around Community this time around were basically moot because nothing had really changed. We get a similar number of actual Community builds as before, and new stuff gets pushed into a far future version, when basically nothing new was being accepted anyway.

I find it ironic that Zack ends his article with:

At this stage, I think we’re all exploring different approaches to building open source businesses and communities. But the good news is, if we make mistakes along the way, folks will tell us.

Yes, we’ll certainly tell you when you make mistakes. That doesn’t mean you’ll listen or try to correct them. Horses and water and all that.

1 More accurately, I generally recommend RHEL if you’re interested in the support part of the equation, and CentOS if you’re not. Quite a lot of our customers choose RHEL, if for nothing else than to give back to RedHat for creating a great product. Let’s not talk about up2date for now. ;)

MySQL Community split officially a failure

A few days ago, I got the opportunity to hear about some upcoming changes in MySQL Community and MySQL Enterprise. I’ve been waiting for an official announcement before commenting on the changes, and Kaj has finally posted the official announcement on his blog in Refining MySQL Community Server.

In summary, the changes are:

  • Community gets no new features in any version once that version becomes GA — This effectively means that the difference between the content of Community and Enterprise approaches nil, since the addition of “Community Enhancements” was the major selling point for MySQL Community; In addition, it means that as of today, any new actual features go into MySQL 5.2, aka never-never land
  • Some changes in the policy as to frequency of Community builds, which amounts to no change in the status quo — MySQL has changed its promise for Community releases from 2 per year to 4 per year, despite the fact that we have had 4 releases already in the first half of 2007
  • MySQL will start to hide their Enterprise source releases from the public — A reaction to several Linux distributions using Enterprise releases for their bundled packages, Dorsal Source building binaries of Enterprise, and other issues; this doesn’t really solve any problems, however, as those who need or want the files will still get them all the same

So, what are my thoughts on the matter?

The “MySQL Community” concept has failed

As Kaj admits on IRC after a bit of prodding:

<kaj> JeremyC: Our past 10 months since Oct has been a struggle to make that work, and we’ve failed.

Only 10 months ago in October 2006, MySQL rocked the world a bit with Kaj’s announcement of the split between Community and Enterprise. For MySQL Community, Kaj promised:

  • early access to MySQL features under development — this hasn’t happened, and I don’t see how it could have, as Community was intended to be released infrequently
  • that MySQL AB will listen to their input — nothing has changed in this regard
  • timely corrections to bug fixes they report — nothing has changed in this regard
  • help with enhancing MySQL for their particular needs — nothing has changed in this regard
  • channels to communicate with the rest of community for getting assistance — some nice changes here with the establishment of the FreeNode #mysql-dev IRC channel and the appointment of Chad Miller as community liaison
  • an easier process for having contributions accepted in MySQL — very little has changed in this regard
  • commitment to Open Source — including free, unrestricted availability of source code — uh, ok, kind of assumed

Has the above happened? No, not really. Other than a reduction in frequency for the Community tree, nothing has changed compared to how things used to be.

The fundamental idea behind the Community and Enterprise split is a reasonable one. It’s a model that has worked very well for RedHat with their Fedora / RHEL split (in fact I often recommend RHEL to our customers, because it has worked so well1 for most of them), and I think given the right implementation this model could work nicely for MySQL as well.

MySQL fundamentally misunderstands their community

Generally speaking, any contributions to the server will be to address specific problems, mostly in larger systems. That means that any possible contributions against the server are needed because either of bugs or deficiencies in MySQL that are already affecting production systems. Very few, if any, of the features we’re writing are just because it would be fun. That means we need those features in a version of MySQL we can actually use.

The promise with MySQL Community was that those contributions, small fixes, etc., would be accepted so that we could get on with using them in our production systems if we’re willing to use the Community releases. Eventually, after the changes are vetted and proven stable, they would possibly be pushed into Enterprise. This didn’t really work at all… since the releases of Community are so infrequent, very little vetting happens, and there is no real feedback loop with the users, due to the delay in seeing actual fixes implemented.

The split was confusing from the start

The version numbering scheme makes very little sense, even once you understand it. Case in point, since profiling was added in 5.0.37, does 5.0.44 have it? No? Huh?

Why try to keep the version numbers the same while fundamentally changing the release structure and content of each half of the split? This has confused users beyond anything else. In addition, the documentation has suffered tremendously from the change as well.

Back in my discussions before the actual split with Jay et al, I correctly predicted serious quality control issues in Enterprise given the more frequent release cycle compared to Community. Back in May, I pointed out a perfect example of this in Breakdown in MySQL Enterprise process; A bug fix was applied to Enterprise which had received no testing at all in Community or anywhere, and later had to be reverted. The new changes to Community and Enterprise do absolutely nothing to address these concerns.

What are we doing about it?

Dorsal Source — Community MySQL Builds

As you know, Proven Scaling has sponsored and worked with Solid to bring you Dorsal Source, which in its current incarnation is just scratching the surface of what we hope to make available. Dorsal Source has been and will continue to provide the source packages for Enterprise, as well as community-built binaries of the even-numbered Enterprise releases. In fact, we have just posted source and binaries for MySQL 5.0.46.

If you’re handy with PHP, MySQL, XML, and/or Drupal, and you’re passionate about MySQL or the MySQL community, and interested in helping Solid and Proven Scaling develop Dorsal Source, let me know. We’d love to have you on board.

Announcing a free and open mirror for the community

Proven Scaling immediately announces a new initiative to address the needs of our customers and the rest of the MySQL community: mirror.provenscaling.com/mysql, where we will provide a few unique—and we hope useful—things:

We will provide standard rsync access for anyone else who wants to mirror this content… just send me a note.

Commitment to continuing development of MySQL 5.0

Proven Scaling has developed quite a few patches against MySQL 5.0, and we will continue to provide useful patches and do our development against the version of MySQL that our customers use… which means MySQL 5.0 for some time to come.

As Dorsal Source matures, you will see a whole slew of new features associated with patch management—keep an eye out for that.

1 Ugh, other than the fact up2date in RHEL4 sucks. Long live yum.