MySQL to Adopt Solid Storage Engine

hmart writes "As seen on ZDNet's Open Source Blog MySQL is taking another step to defend from Oracle's recent acquisitions of InnoBase and Sleepycat. From the article: 'MySQL responds by getting Solid Information Technology, a proprietary database vendor, to take its solidDB Storage Engine for MySQL open source, under the GPL, starting in June.'"

Re:This is good news

[ScrewMaster]

Well, it's one thing to acquire a company in order to deny your customers and potential customers access to a competitive product. It's quite another to hire away a bunch of developers and keep them. That's difficult, especially if they happen to be the cream of the crop for a particular industry. As soon as you don't give them what they want (and money is only part of the picture) they'll drop you like a hot potato and look for greener pastures. I'm not slamming Oracle in particular since I don't know what the place is like for the development staff: it might be a great place to work. But job satisfaction is an important aspect to any position for a good programmer, and if you're good (and that is presumably why Ellison is hiring these guys) you have a lot of options. My bet is that a few years down the road you see some of those missing coders back on the radar.

Re:Hooray

[itunes keith]

I'm not sure I would agree 100% that everything will go to oss - even in the long-term. I've been on mainframe/db2 for three years and have inherited a lot of respect for big iron's sw abilities (and hw, of course). But, I guess, you cannot predict the future.

Re:This is good news

[NitsujTPU]

That's kind of the thing.

I don't want to offend MySQL devs, but, eh, here goes.

MyISAM isn't so hot. It doesn't support transactions... it won't enforce your referential integrity constraints... it doesn't work like, probably, it should. It indexes things so you can look them up quickly with SQL queries.

InnoDB on the other hand, sticks all of the features into MySQL that it needs in order to be considered a serious database engine.

When Oracle bought InnoDB, they bought all of the stuff that makes MySQL actually useful. In order to stay competitive, MySQL will need a new storage engine... or perhaps keep updating the GPL'd version of InnoDB. The response has been to get a new commerical engine that works out of the box open sourced, so they can keep the edge that they need in order to stay in the game.

I hope they've got a perpetual licensing agreement

[WoTG]

I guess somewhere down the line MySQL users will be pressured to move off of innodb onto this Solid DB. (At which point, we might see some community backlash and a big controversial fork where the community makes a GPL-only version of MySQL to maintain InnoDB support -- which would please Oracle greatly.)

I hope the MySQL has gotten something in paper that will make sure that this is the last time that users have to migrate. Sure, they can claim that a migration will be seamless, but who's going to be foolhardy enough to risk their data on a transition like this without significant testing?

Actually, now that I think about it, I don't know if it is reasonable to expect users to switch "just" so that MySQL will be able to sell commercial licenses to their drivers and what not. The switch to InnoDB took years (and it's probably still ongoing for many users), but in return, those who switched got a lot of new features that made it worthwhile (probably). This time around, there is not much of an incentive for end users -- assuming that the feature sets will be roughly comparable between InnoDB and Solid.

Re:Here's an idea.. . Develop your own!

[jadavis]

MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV

"Choices" is positive spin. Some might say that MySQL is all about sacrifices. Here are some examples:

(1) "MySQL has many applications written for it"
* Not if you enable strict mode, or if you use storage engines that don't support the features you need.
(2) "MySQL is optionally SQL compliant with strict mode"
* Only if you want to forego 99% of the existing MySQL applications, and start fresh.
(3) "MySQL has transactions"
* Not in MyISAM, which means no full text indexing.
(4) "MySQL is free"
* Only if your application which links against the client library is also GPL.
(5) "MySQL is fast"
* Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.

I could go on. Anyone can talk about how MySQL has a feature, but you have to make sacrifices for those features. And I think many of those are bad, unnecessary sacrifices. MySQL implements features not to give their users choice, but to give MySQL AB a marketing advantage. Their advocates and salespeople will always say "yes" to all of those features above, but it's not until later that the customer realizes that they can't use the features together.

Re:More Info?

[Antony T Curtis]

That is an obvious difference but not the most surprising difference. The non-transactional MyISAM tables can be very useful for referential (read mostly, update rarely) data for which transactions are not useful. There are other non-transactional storage engines such as CSV.

I think a more startling difference for users between the different storage engines is that of Referential Integrity - foreign keys are currently only supported within InnoDB.

This is something which I personally hope will change in the near future and become available for all (transactional) storage engines. Alas, it is not easy to do - if it was, everyone would already have multiple storage engines with it.

(disclaimer: my views are my own and not that of my employer nor anyone else)

Re:This is good news

[grasshoppa]

The problem being once these important OSS coders see oracle source, they are tainted. Any further OSS contributions will have to be heavily scrutinized for IP violations.

So oracle does not need to keep them. They just need to expose them to even bits of their db source, and they have tainted the coder.

Devious, if you ask me. I am impressed. Or I would be if it didn't damage my own interests.

Re:This is good news

[spiritraveller]

In order to stay competitive, MySQL will need a new storage engine... or perhaps keep updating the GPL'd version of InnoDB.

I don't think that is not an option. MySQL AB has a dual-licensing scheme for MySQL. They need another company (like Solid) from whom they can dual license an engine for use with MySQL.

Now... if they wanted to go completely GPL and quit selling MySQL for use in proprietary applications, they could keep updating the GPL version of InnoDB and keep distributing it. But then they would lose the revenue that comes from the proprietary-licensed versions of their product... and there goes their business model.

Good, but how good not known yet

[PizzaFace]

Solid's database server has a good reputation. Philip Greenspun used to recommend Solid as a cheaper alternative to Oracle, though it seems he now recommends [greenspun.com] PostgreSQL. What all three systems have in common is multi-version concurrency control, which improves concurrent data access by tracking the changing versions of data rather than locking the data when a user might change it.

I'm just worried about this quote from Solid's V.P. of Marketing:

So we're going to make available code that works only with mySQL. On the side we have a proprietary line of products.

It sounds like MySQL will use only a subset of the Solid product. So how good this news is will depend on how complete a subset of its product Solid opens.

Re:This is good news

[Anonymous Coward]

I'm not sure what you're talking about. Transactions have nothing to do with backups, auditing, or finance. In a nutshell: the way MySQL is implemented, if you're doing an update that affects more than one table, using a transaction (or LOCK TABLES, which is just rolling your own transaction engine via brute force) is the only way to prevent anyone from seeing the update while it's half-finished, i.e., the data is invalid (changed in one table but not in another). There's nothing disk-centric about the idea, except that in MySQL all database engines except InnoDB (which is disk-based) silently fail to enforce transaction semantics.

Re:This is good news

[Antony T Curtis]

You know, it may seem "obvious" that Oracle acquired Innobase and Sleepycat to hurt MySQL AB but I am not sure if MySQL really competes in the same application space as Oracle. They are two very different products.

Have you concidered that Oracle has started to acquire opensource companies because they have suddenly discovered that companies like IBM, Novell and Sun may have something profitable in their open-source strategies and wants to get a piece of that pie?

Who knows what Oracle's reasons are. Only they do. Why must people assume the most malicious reason all the time?

(disclaimer: opinions are my own and not of my employer nor anyone else)

Re:Here's an idea.. . Develop your own!

[Jimithing DMB]

MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.

This is typical LAMP programmer thinking. What do I need transactions and data integrity in a database for? I'll just code the checks into my application. I prefer instead to put checks both in the database and in the application.

(4) "MySQL is free" * Only if your application which links against the client library is also GPL. Myth used to scare people away from opensource GPL code.

This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL. Alternatively, you can purchase a license from MySQL AB. MySQL AB spins this up so much saying that they are open source but what they really mean is that they are open so long as you are open.

I'll stick with PostgreSQL. Unlike MySQL, PostgreSQL is a serious alternative to Oracle or MS SQL. It is also BSD licensed and thus there are zero restrictions on its usage within a commercial product and there is no need to purchase a commercial license.

MySQL is okay for the LAMP mentality but when you start getting in to ORM/ERM (Object/Entity relational mapping) with packages like Rails's Active Record or WebObjects's Enterprise Objects you need a more serious database. As another poster has pointed out in this thread I give it only a few more years before mainstream open source web development moves into the ORM camp.

Re:This is good news

[jizmonkey]

The problem being once these important OSS coders see oracle source, they are tainted.

That's not true, any more than someone can be "tainted" by working at one company and then getting a job at another. There's something to being cautious but it's simply not possible, especially in california which disallows non-compete agreements in almost all cases, to take away someone's open source livelihood by "tainting" him. There's nothing special about open source software.

Re:LARP

[SmashMacFly]

Postgres used to be superior to MySQL in many ways two versions ago. It was much stronger and faster and it used to allow you some actions that were imossible with MySQL like DELETE in multiple base at once. But Postgres also had some problems like the impossibility to alter a DB once it had been created, forcing you to re-create a DB if a minor modification was needed. Now MySQL has evolved a lot and is basicaly at the same level but indeed with a lot more support.

Solid(TM) and the Oracle connection

[adnonsense]

Says here [sql-info.de] that the marketing VP quoted in TFA, Paola Lubet, used to work for Oracle.

Now I wouldn't want to read anything into that, I'm guessing there's a lot of rotation between database companies, and it's a private company [solidtech.com] held by a bevvy of investors, so Larry Ellision presumably won't be able to drop it in his shopping basket when he pops out for some milk. On the other hand the investors sound like venture capitalists (I may be wrong, corporate finance is not my field) who might be interested in any short-term returns on their investment that a large, cash-rich company could offer.

Re:This is good news

[moro_666]

i agree, even for simple applications transactions are heavily needed.

you could always do

insert into A(...., complete) values (.... ,0);
insert into B..
insert into C..
#if smth went wrong, just delete the stuff
#if it went right, make A valid ...
update A set complete=1;

  and always query for A's where complete is 1 ... but this still scks :p and there's still invalid data in b's and c's :p locking is a `weird` approach in terms of performance, infact you're getting rid of the performance in most cases :D

  transactions makes your life easier and if you know what you're doing, it certainly also shortens the development time.

  after oracle got innodb, i'm not so fond of mysql anymore at all, that was indeed one of the very few useful things in mysql. i haven't checked the 5.1 branches of mysql yet, but 5.0 was still below my expectations.

i will stay postgresql fanboy for a while. it's cheaper to buy 1 extra machine into the cluster to handle the performance than to spend more and more time on weird code that achieves the same result in mysql.

MySQL tries to play catch up ...

[Tetard]

... while others (PostgreSQL) have all one needs. I guess that's an unavoidable dynamic of free software (and a good one as well -- just like in other competing open source projects). So probably one day MySQL will have everything that PostgreSQL has today, but why wait ? It's mostly transparent to move from one to the other, and there are tons of guides and scripts to convert from MySQL to PgSQL. Even PhpMyAdmin has its Pg pendent (PhpPgAdmin).

And it's painful to go back when you've learned to do proper logic separation using stored procedures, triggers, views and transactions, things that way too many projects duplicate in the PHP or Ruby front-end, relegating the DB to the "simple" role of being a storage backend (even Ruby on Rails forces you to think that way via the MVC architecture).

For that purpose, use SQLite -- it does what you need, is very high performance (on-disk, non-concurrent access -- can't get any faster than that). For real solid DB work, with garanteed integrity, just the way RDBMS were meant to be, go for PgSQL.

Re:This is good news

[killjoe]

"People who choose database vendors and make other such big IT decisions for companies like GM, Boeing, Wal-Mart and such, think "Open source = toy for the geeks"."

Yes that's why no large corporation in the world uses mysql. Hey wait a minute that's a complete lie isn't it? There are lots of fortune 500 corporations using mysql aren't there. Never mind.

"They want top notch support, perhaps even an Oracle team to be on-site for a couple of months during deployment, they want someone to blame and to complain to when things don't work right. MySQL provides support but it is just not going to be the same quality."

Spoken like somebody who has never bought support from oracle or mysql. If you pay mysql half of what you pay oracle for support they will give you the phone number of a developer. How is that for support?

Mysql offers some of the best support of any database vendor. Go ask any of their big costomers. Then compare what they say to the customers of oracle.

I don't mean to be a cheerleader for mysql but I really really get tired of the same old "you can't get support or blame somebody" FUD about open source.

It's over, strike that item from your big book of FUD and find something else to complain about mkay?

Re:This is good news

[kpharmer]

> Replication is important to oracle users and that's one area where mysql is a bigger threat then
> postgres. Clustering is another by the way.

No, replication isn't that big of a deal to most enterprise databases. About the only people who really think it's important seem to be MySQL content-management users that want failover. That's fine, but enterprise data management is more likely to focus on hot or cold standby solutions for failover, or ETL for copying to a reporting database.

As a side-note, I'm currently yanking a bunch of replication out of a db2 architecture that some fool put in. It makes life much more complicated when you've got multiple replication interfaces all over the place. It'll be replaced by Federation - which simply redirects queries against original database, instead of copies data.

And clustering? Although a very small number of Oracle users are using their product for clustering at least there they can handle more than a few gbytes of data. The solution that MySQL purchased a few years ago is limited to the amount of data that will fit into memory. This is pretty much a useless feature for most enterprise projects. Obviously any that have tens of gbytes of data or any that get frequent writes.

The one thing that MySQL has over Postgresql is third-party support: due to its huge lead over postgresql 4+ years ago most developers based their apps on it. So, now it's ubiquitous. That's a genuine advantage. No real technical advantages that I can imagine however.

Re:This is good news

[ErikZ]

IBM, Novell and Sun are actually contributing to open source.

I haven't heard of Oracle doing anything like that. What have they contributed to? Have they changed the licence of anything they own to GPL?

If not, it doesn't sound good to me.

Re:Here's an idea.. . Develop your own!

[kpharmer]

> Isn't it better to have a choice of technologies?

uh, better than what? If the answer is stability, then no.

So, MySQL has the following storage plug-ins: MyISAM, Innodb, Sleepycat, etc, etc, etc. as an enterprise data architect (ok, sounds pompous, how about someone that implements a *lot* of database solutions) I really don't care about a wide variety of storage engines that mostly don't meet my needs. Of all of the above, only Innodb is a good general-purpose solution. The others are useful only in specialized circumstances or are obsolete.

The idea that multiple storage engines is a great idea is just market spin.

Oracle, DB2, Informix, Sybase, SQL Server, Teradata, Postgresql, Firebird, etc - all have their own. There is no risk to the user that another company is going to buy out their storage engine, force the database vendor to perform an expensive switch and possibly impact functionality or licensing for my applications.

If MySQL wants to support multiple storage engines that's fine. Not terribly attractive to me, but fine. But first - it needs to own its own. And its own needs to support ACID as well as non-logged activity. This shouldn't be news to anyone: this is what every single commercial database provides and has been the way to do it for 20+ years. It's still the way to do it.

> Freedom of choice is always a good thing.
> MySQL is not about having cheap database... MySQL is about Freedom of choice.

How about cheap, full-featured, standards compliant & stable RDBMS? Why isn't this a possibility? This is what I want, not freedom to pick from a pack of obsolete, special-purpose or dead-end storage options.