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.
Jeremy – excellent post! I agree 100%. Falcon looks cool and promising, but you get the feeling MySQL may be pinning an inordinate amount of hope on it.
Falcoln in the belly « from Oracle to MySQL
I too dislike these kinds of lists (I saw this a while ago, though I too mostly stay in the manual). And there’s more than a minor chuckle in the first 7 items. For example, item 7 itself… if Falcon doesn’t need to be configured, why the heck do I need to tune it?
Number two, just for another one… rollbacks should be relatively infrequent. I’d be more interested in hearing about the performance of commits. I’ve never had a server need to do thousands of rollbacks per second, but commits are another matter.
I agree. Tests just a month ago showed that Falcon is far from production ready. It’s unstable and performs much worst than InnoDB. Either a *lot* of work has been done since than, or…
I could have commented on most every entry, but given that it appeared that they just gave up and made up the last 3, I figured I would focus on them. So there may be varying degrees of “chuckle” involved in the first 7. :)
Hi Jeremy and hello MySQL fans,
By no means I’m trying to raise a flag of war here, but working as a DBA with MySQL on daily basis for a long time by now and reading the Falcon white paper (including the “Top Reasons Falcon is Cool” section), I can only say one thing: I can’t wait start working with Oracle, whatever the version might be.
MySQL and “enterprise database” notion don’t fit together, no matter how much the MySQL marketing geniuses are touting that. I got sick and tired of MySQL’s “new and different paradigm of database management”. The best paradigm they were able to provide so far is s/bug/feature/g, like you said.
For me, it’s end of the story.
We will be testing new Falcon version soon to see if there was any significant improvements.
But so far I see to much marketing push and too little technical work done on actually making it work good.
Also I would like to see MySQL taking even remotely honest approach and highlighting benefits and drawbacks falcon design has