This week is a REALLY good time to actively strengthen the MySQL forkers
As my first three posts on the Oracle/Sun merger suggested, I think Oracle will do a better job with MySQL product development than Sun has. But of course that’s a low hurdle. And so it leaves open the questions:
What should and/or will be the most widely adopted code lines of MySQL (or other open source DBMS),
especially for the types of users and vendors who are engaged with MySQL (as opposed to principal alternative PostgreSQL) today?
As much as I’ve bashed MySQL/MyISAM and MySQL/InnoDB for being low-quality general-purpose DBMS, I’d still hate to see MySQL-based development stall out. There are a number of MySQL engine providers with rather unique technology, that deserve a good front-end partner to build their products with. The high-volume sharding guys deserve the chance to continue down their current path as well. And so does the low-end mass market — although I’m least worried about them, as I can’t imagine any realistic scenario in which Oracle doesn’t offer a version of MySQL fully suited to support 10s of millions of WordPress and Joomla installations.
So far as I can tell, there are only four real and currently active candidates for MySQL code coordinator:
- MySQL itself, soon to be owned by Oracle.
- MariaDB, Monty Widenius’ proposed mainstream MySQL alternative
- Percona, which seems to have some fans as a superior alternative to vendor-supplied MySQL/InnoDB
- Drizzle, which is directly focused at web-centric MySQL users who never wanted a robust DBMS in the first place.
Patrick Galbraith and Steven Vaughan-Nichols did good jobs of illustrating the turmoil.
Oracle isn’t a very comfortable partner long term for the storage engine vendors, and Drizzle doesn’t seem to be what they need. So I think that Infobright, Kickfire, Tokutek, Calpont, et al. need to get aligned in a hurry with an outside MySQL provider such as Percona or MariaDB or a newcomer, preferably all with the same one. Yes, I understand that Infobright is getting a lot of marketing help from Sun these days, that Kickfire just got a nice-sounding Sun marketing announcement as well, and so on. But the time to start working toward the inevitable future is now.
And by “now” I mean “right now,” since the MySQL community is at this moment gathered together for its annual conference.
Comments
12 Responses to “This week is a REALLY good time to actively strengthen the MySQL forkers”
Leave a Reply
The problem I see is that for many years the community based development of MySQL has been falling so now most of the code for MySQL is done by MySQL/Sun. So the community supporting a fork isn’t nessecarily giving that fork development support. Forking the code and adding your own stuff is very different to forking the code and taking the entire code base development forward from that point.
Drizzle is community based development, but (as I understand it) funded and supported largely by Sun.
MariaDB currently is a branch which means compatiability with Sun’s MySQL releases, but if push comes to shove I can see MariaDB becoming a true fork. And while I don’t know exactly what % of the $1b MySQL buyout Monty got, I imagine out of the lot of them he is the one with the funds needed to do that. I can also guess that a lot of MySQL developers currently working at Sun will not at all be happy working for Oracle and will look to re-join their original founder at MariaDB if possible.
Tony,
Good distinctions.
Thanks,
CAM
Actually, Kickfire announced partnerships with a number of major system integrators and consultancy groups, including among them Percona.
See the press release:
http://www.kickfire.com/media/press_releases/SI_Press_Release.pdf
As mentioned in a comment on your first post regarding this acquisition, I’m uneasy about the future for Percona, MariaDB, et. al. Then again, you definitely are correct that jumping ship to, say, Postgresql is much more difficult.
It looks like MySQL will be a source of intersting stories for the forseeable future.
[…] posted suggesting that substantial elements of the MySQL community should throw their weight behind MySQL forks. Mike Olson of Cloudera helpfully pointed out, on Twitter and by email, how the GPL could appear to […]
[…] screw it up. (That’s one of the biggest reasons I think viable escape-from-Oracle MySQL forks are needed.) Conversely, Oracle/MySQL can try to have it both ways, encouraging the MySQL ecosystem […]
Curt,
What is your basis for claiming that MySQL is low quality?
Lack of full datatype extensibility, lack of broad SQL 2003 support, reports of poor performance on constraint checks, historical scalability issues for the most popular transactional engine, reports (that you dispute) of poor performance by the most popular transactional engine.
But that’s just tonight’s list. Ask me a different time and I’ll give a whole other set of reasons.
Curt,
That is a low-quality list for making such an assertion.
A missing feature is not a low quality feature and a historical problem might not be a current one.
From your list datatype extensibility, broad SQL 2003 support and constraints are missing features.
and there is no demand for datatype extensibility.
If we are to dispute MySQL performance then you should make clear that you know more about it than what your clients and/or contacts have told you unless your clients are experts in it.
Why should Oracle kill MySQL, when they will do it themselves?…
I’ve been out at the Percona Performance Conference / MySQL Users Conference this week, and as you can imagine a lot of the talk about Oracle’s purchase of Sun/MySQL. As someone who runs Oracle and MySQL, and perverbial elephant in the room Postgres,…
[…] ＞＞對MySQL影響的分析 […]
Several software engineers I know who have worked intensively with MySQL say that there’s a serious problem: the interface that connects the main generic MySQL to the back-end storage engine is (a) not stable from release to release of MySQL, (b) not well documented, and (c) not placed at the best possible point in the abstraction/implementation architecture.
I only know about point (c) because software engineers whom I greatly respect have told me so.
But points (a) and (b) are very easy to appreciate, even without knowing all the technical details. Things like this arise in computer software architectures all the time. There are plug-ins for Apache’s web server, for Firefox and Thunderbird, and dozens of other widely-used software systems.
It’s good for customers, for storage engine providers, and for anyone involved in MySQL for there to be a long-term, flourishing ecosystem of storage engines for MySQL. To make this happen, it would be extremely valuable to fix (a) and (b): have a well-documented and stable software interface to MySQL storage engines. This will function as a de facto industry standard.
The question is, who is going to be the one to establish this new standard? Does Oracle want a flourishing ecosystem of storage engines, coming from non-Oracle companies? I hope they realize that this would be a good thing, and they do not “kill the goose that lays the golden eggs.” I hope they do not suffer from the classic “Innovator’s Dilemma” mistake, trying to suppress the quality and power of MySQL in order to prevent it from competing with their main Oracle DB product.
We’ll see…