Sun does Google's dirty work on MySQL
Sun Microsystems will fine tune MySQL for some big-name customers unwilling to get their hands dirty supporting the open source database themselves.
Google, a MySQL user, will be among those benefiting from Sun's engineering expertise and resourcing to help improve the database's scalability and performance of its storage engine in multi-core and multi-threaded environments.
Zack Urlocker, executive vice president of products for MySQL, told Reg Dev that Google had suggested improvements, but "in some areas we haven't responded as we'd have liked". Urlocker was speaking as Sun's $1bn acquisition of MySQL officially closed this week.
There has been a suggestion in the community that Google was unwilling to make the necessary changes to the open source database to meet its high-performance needs itself, as it would then have been compelled to support them.
That was a problem for MySQL, potentially limiting its uptake in really large environments.
Urlocker said: "Anyone can take part in open source but you have to be really good. And things are more complicated on the inside to make sure you don't destabilise the performance of the database.
"MySQL couldn't dedicate what Sun could with its resources... Now we have the opportunity to go from planning and to make it a priority."
Already planned in MySQL 6.0 for the fourth quarter is the storage engine codenamed Falcon, targeting the kinds of multi-core processors that have become the hallmark of large-scale systems. But that isn't quick enough for some customers.
"We have a sense on some architectures that when you get to a large number of multi core and multi threaded situations, some of the storage engines don't scale as you'd like them to. If you are on the leading edge of performance then that top one or two per cent of customers is not waiting to get some release," Urlocker said.
He is, meanwhile, optimistic Sun's sales and channel reach can help MySQL make more money from large, multinational companies that tiny MySQL could barely touch on its own.
According to Urlocker, direct sales are becoming more important as he claimed MySQL's traditional OEM business represented just 40 per cent of trade last year, down from 60 per cent two years ago.
While this sounds great for MySQL, the clear concern is its continued independence and development as a core component of the Linux, Apache, and PHP/Perl/Python stack, given Sun offers Solaris as an alternative to Linux and, with Solaris, Postgres - a substitute for MySQL.
Sources at Sun have indicated the firm is at pains to do nothing that would alienate developers, lest this destroy Sun's vicarious relationship with them.
Urlocker promised there would be no platform agenda, pushing Solaris over Linux - particularly Red Hat, which has been "great" for MySQL. "We've got more people helping us on Linux today then I had prior to the close [of the acquisition]. If we do integration for Solaris or Java it's not coming at the expense of Linux, Windows, PHP, Ruby or anything else." ®
And have you seen the initial memory requirements for MySQL?
Last time I compiled from source, PostgreSQL used 22Meg (including VM needs) of memory - MySQL? 115Meg! Given several hours, I was able to get that trimmed down to about 35Meg... but still. The reason for MySQL way back when was "small & fast." Now it has neither...
Makes me glad I started with Postgres all those years ago, and stuck with it; for me, MySQL has nothing but disadvantages now.
Large Enterprises tend to make strategic database decisions, and these are usually driven by the apps that run on them. People buy Oracle not just because it's fast, but also because it's so popular they know there will be several apps in a particular solution area capable of running on them, giving them a choice of vendor.
I can't help but think Sun should be going after Enterprise Software Developers in the Information Management camp in order to make inroads into Large Enterprises. E.g. ERP, BI, MI, ECM type vendors to help reduce their price point in the required underlying database, but give MySQL at the same time Enterprise credentials in the market. (I.e. the JBoss vs. WebLogic/WebSphere argument)
The software we sell at work runs on MS SQL Server (Enterprise vs. Ubiquitous, anyone? ;o) ), Oracle and DB2. I don't think I've ever heard of a deal being lost because we didn't support MySQL/Postgres. Funnily enough, this is probably because our customers realise that no Enterprise solution vendor for our type of software supports those two DBs.
Nice comment, but I would have thought it would be much easier to take up Postgres as an Oracle beater, as thats what its made to be.