Open Database Alliance hedges against Oracle plans for MySQL (ars technica) [LWN.net]

Here's a look at movement in the MySQL community from ars technica. "Some key developers in the MySQL community are launching a new coalition called the Open Database Alliance which intends to coordinate collaborative MySQL development. The alliancewhich currently consists of Monty Program Ab, Percona, and OpenQueryaims to provide an inclusive, vendor-neutral environment for moving forward MySQL development. Their efforts will attempt to insulate MySQL from Oracle's competitive interests by giving the collective MySQL community enough leverage to control the project's destiny."

to post comments

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 14, 2009 20:24 UTC (Thu) by sbergman27 (guest, #10767) [Link] (8 responses)

* MySQL AB's old licensing scheme, which kept MySQL 4 out of most distros.

* The acquisition of Innodb, which cast a shadow of uncertainty over MySQL's future.

* The acquisition of Sleepycat. Ditto.

* The acquisition of MySQL AB itself, and the subsequent departure of the salient MySQL personalities. Ditto again.

* And now the acquisition of Sun.

MySQL has been in a state of turmoil for as long as I can remember. At least as far back as the 3.23 days. Why don't its users just do the smart thing and move to another RDBMS, like PostgreSQL, which doesn't have this cloud of uncertainty hanging perpetually over it. In this particular case, all the fear, uncertainty, and doubt are quite real, as the historical record confirms.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 14, 2009 21:27 UTC (Thu) by drag (guest, #31333) [Link]

Because MySQL is open source and has not been in a state of tourmoil. People can rely on it always being there becuase there it is popular and has a vibrant and healthy community around it.

Because MySQL is used by a lot of people and a lot of applications it has a massive amount of inertia. Moving to Postgresql would require somewhat of a port that would introduce bugs and sap productivity for very little actual benefit for the majority of users.

You might as well wonder outloud why people continue to use Linux in the face of FreeBSD and OpenSolaris, both of whome don't have problem including features like ZFS, Dtrace, stable driver API for supporting proprietary drivers, and proprietary software-friendly licensing and policies... All of which people cronically bitch about Linux missing.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 14, 2009 21:28 UTC (Thu) by einstein (subscriber, #2052) [Link]

Well.. there's the fact that all our production mysql databases are still running quite nicely - one can't discount little things like that. It would take more than a bit of FUD or rumors of future licensing issues to send us scrambling to find another database.

IMHO postgres is a fine db in its own right; no need for anti-mysql FUD, postgres can stand on it's own merits ;)

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 2:40 UTC (Fri) by dskoll (subscriber, #1630) [Link]

The reason people don't switch is that it's a real pain.

We're lucky in that we've used PostgreSQL from the start, so we don't have to switch. If the tables were turned and PostgreSQL were undergoing this sort of upheaval, I'd be really stuck trying to decide what to do.

That said, I'd encourage all new open-source projects to do their best to avoid locking themselves in to MySQL. Ideally, they should be as database-independent as possible, and in the worst case at least support PostgreSQL as well as MySQL.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 4:18 UTC (Fri) by pr1268 (guest, #24648) [Link]

MySQL has been in a state of turmoil for as long as I can remember.

I gather from the article that the Open Database Alliance is explicitly attempting to stop this state of turmoil and bring some stability to MySQL.

Time will tell us how successful the ODA is.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 12:45 UTC (Fri) by herodiade (guest, #52755) [Link] (1 responses)

> Why don't its users just do the smart thing and move to another RDBMS, like PostgreSQL

In my case, the single and huge blocker to migrate from MySQL to PostgreSQL is the lack of robust, native, fast and bidirectional replication. That's like having only half of the data persistence solution, when looked at the higher, datacenter level.

I'm quite sure the PostgreSQL current inability to scale horizontally with the help of a seamless replication solution is also a strong reason for the choices made by big MySQL-based websites (like flickr, linkedin, facebook, livejournal, digg, mixi, lastfm, wikipedia, twitter, etc), rather than a choice based on inertia or lack of knowledge. Neither Slony or Londiste covers the need yet (manageability + master-master ha setups + delayed replication for very fast point in time recovery + DDL replication + fast + low servers overhead ...).

Now if Simon Riggs works on native replication really make his way in PG 8.5, and is up to the promises, no doubt we'll be many to ditch MySQL away, because then it will arguably be a lesser solution on *every* aspect. This will happen, it's just a question of time.

Though by that time the BigTable-like key-value stores paradigm hype may have taken ground, at least for web shops. I can already count a large dozen of F/OSS implementation right now! (quick inventory: Project Voldemort, CoucheDB, Ringo, Scalaris, Kai, Dynomite, ThruDB, MemcacheDB, Cassandra, HBase, Hypertable, MongoDB, Neptune, SimpleDB, Redis, Tokyo Tyrant/Cabinet, Tripod, Dystopia : such a large number of options is a sign of a strong need I guess).

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 16, 2009 7:56 UTC (Sat) by job (guest, #670) [Link]

Languages such as PHP have had excellent BerkeleyDB support from the beginning. If a simple key/value store would suffice I'm sure they would have used that, saving lots of administration and portability issues compared to a full blown SQL. That's why I'm skeptical that simpler key/value stores would suddenly come back and take over. It's probably enough for some web apps but far from all.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 18:08 UTC (Fri) by agajan (guest, #7859) [Link] (1 responses)

I have been believing that PGSQL has better transaction processing and that MySQL is more efficient for storing web server data when there isn't a need for lot of transactions.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 16, 2009 20:09 UTC (Sat) by hingo (guest, #14792) [Link]

And this was indeed the case... in 1999-2000 :-)

(But the impression has persisted. For us MySQL'rs it is a common joke to say "Did you hear that MySQL supports transactions now.")

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 14, 2009 21:34 UTC (Thu) by hingo (guest, #14792) [Link] (8 responses)

"Why don't its users just do the smart thing and move to another RDBMS..."

With the 10 years of history you just recited, it's a valid question. Why don't they? There must be a reason. Think about it.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 4:01 UTC (Fri) by flewellyn (subscriber, #5047) [Link] (7 responses)

Inertia, mostly. And the incompatibilities of the non-standard MySQL syntax causing breakage everywhere.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 9:28 UTC (Fri) by vivo (subscriber, #48315) [Link] (1 responses)

The only thing which make difficult to port to postgrees (>=8.3) is the fact it uses case sensitivity in LIKE, nothing else.

Inertia may be, but IMHO the two main things that stop adoption of pg are:
1) some bigger complexity in tune it for real world cases
2) the community keep saying pg is the only the best and all others suck full stop, no reply please

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 10:19 UTC (Fri) by drag (guest, #31333) [Link]

> 2) the community keep saying pg is the only the best and all others suck full stop, no reply please

Ha.

While I wouldn't say that is a real reason why people won't adopt Postgresql more.. it certainly is annoying.

MySQL simply is not that bad as people want to believe it is.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 13:17 UTC (Fri) by marcH (subscriber, #57642) [Link] (4 responses)

> Inertia, mostly. And the incompatibilities of the non-standard MySQL syntax causing breakage everywhere.

There are no useful SQL standards actually implemented and widespread. I mean things portable yet useful enough for enterprise applications. Everyone (not just MySQL) seems oblivious to even the most basic standards [*].

For a laugh, just have a look at chapter 2 of (the excellent) "SQL in a Nutshell" (try Google books). Database products still have not converged on... defining simple data types! Can you believe this?

Databases seem like the most retarded field in the software market. Maybe even javascript is better at portability.

[*] OK, PostgreSQL looks like the only one who cares a bit. Still far from the spot.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 18:21 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

Indeed. I was told a few years back by an Oracle guy (parachuted in to
solve some nasty problems) that Oracle had no intention of ever making its
database comply with anything later than SQL92. There was 'no point'
because 'nobody cares about that stuff'.

(I suspect that giant banks running code written by
lowest-common-denominator we-just-about-know-what-SELECT-is grunt-coders
really *don't* care, and that's Oracle's target market.)

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 16, 2009 16:21 UTC (Sat) by salimma (subscriber, #34460) [Link]

I'd suspect the problem is less one of employing grunt coders (in charge of their entire business data ?!), but one of being very risk-averse. These are the same companies that still run COBOL on mainframes -- the more important your infrastructure is, the less you dare to replace it, especially if you're not a tech company at heart.

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 20:46 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

"databases are the nost retard field in the software market".

Mostly because C&D's 12 rules are an *awful* foundation for building a DBMS on. Look at them! Relational theory is good - I find it very useful. But C&D's rules are there to make designing a dbms engine easy, and absolutely cripple any engine built on them.

How do you *store* a list in a RDBMS? You can *model* it but you can't *store* it. And if you *model* it, you need to muddle up data and metadata in the database (which you shouldn't), and then the code outside the database needs to know the difference between the data and the metadata (which it shouldn't).

So you have a blatant breach of Einsteins Occams corollary - make it as simple as possible but no simpler. Your database is more complex than it needs because it has data and metadata muddled up. Your applications are more complicated than they need to be because they need to be able to separate data and metadata, and need to know what they can safely throw away and what they can't.

You get the same problem storing "bag"s, non-one-dimensional objects, etc etc. Basically, anything that you have to *model* (ie almost *everything*) is a bad fit for storing in an RDBMS.

Cheers,
Wol

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 16, 2009 17:15 UTC (Sat) by marcH (subscriber, #57642) [Link]

> You get the same problem storing "bag"s, non-one-dimensional objects, etc etc. Basically, anything that you have to *model* (ie almost *everything*) is a bad fit for storing in an RDBMS.

Maybe. But my point was that is much more retarded than this. Even if your data fits the relational model perfectly, you still face portability nightmares. So you just sigh, turn your back to portability and accept being chained to MySQL (resp. Oracle, etc.)

Actually you also have the option to ask Hibernate to deal with portability, as in: "Any problem in computer science can be solved with another layer of indirection" (and as in javascript). "But that usually will create another problem"

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 15, 2009 9:09 UTC (Fri) by sylware (guest, #35259) [Link] (17 responses)

Well. Don't use a SQL engine then all those troubles will go away.

SQL engine uses

Posted May 15, 2009 22:45 UTC (Fri) by man_ls (guest, #15091) [Link] (16 responses)

Working extensively with giant databases I have learned to love them more and hate them less. If your program stores everything in a database then any issue can be solved by manually patching said database, by definition. You can also query the data extensively to figure out what went wrong, why and where. And you have also access to the whole history so that you can learn about what people were doing some time ago. It saves literally thousands of person-hours.

Of course if we had an army of expert and experienced coders and everything was tested extensively we would have less need for the first and second points above, and the third could be solved in different ways. But we don't and so we can't. An SQL engine is a very useful safety net for your data.

SQL engine uses

Posted May 16, 2009 7:51 UTC (Sat) by job (guest, #670) [Link]

You can also trace performance for other people's applications and judge how their usage affects hardware requirements, replication etc. Lots of people have it as their primary profession.

SQL engine uses

Posted May 16, 2009 16:55 UTC (Sat) by nix (subscriber, #2304) [Link] (4 responses)

Working extensively with giant databases I have learned that SQL is crude
and unpleasant and awful and the databases are crude stone axes and often
get in the way... and everything else is worse.

(I wish there was a better syntax for SQL, in particular: it's atrocious.
I feel slightly dirty realising how rapidly I can whip stuff up in it: did
I waste so much lifetime on this? But it *is* useful, nonetheless.)

SQL engine uses

Posted May 16, 2009 17:07 UTC (Sat) by man_ls (guest, #15091) [Link] (3 responses)

I know the feeling -- once you start writing little plus signs and distinguishing inner joins from outer joins (for something which should be trivial with a couple of loops) there is no going back. PL/SQL is another useful aberration which I have crash-learned but will never list on my CV.

SQL engine uses

Posted May 16, 2009 17:40 UTC (Sat) by nix (subscriber, #2304) [Link] (2 responses)

Plus signs? Hah. Once you start using subsubsubsubqueries in the FROM
clause, and thinking 'this looks tricky, I think I'll use MODEL', there is
truly no going back.

(MODEL: because every database should incorporate a halfassed spreadsheet
with ridiculous limitations into its query engine.)

SQL engine uses

Posted May 16, 2009 18:41 UTC (Sat) by man_ls (guest, #15091) [Link] (1 responses)

Ouchie. So there are even worse horrors ahead... And yet somehow you have kept your engineer soul. You must tell us the secret one of these days.

SQL engine uses

Posted May 16, 2009 23:19 UTC (Sat) by nix (subscriber, #2304) [Link]

Kept my engineer soul? Perhaps. I found myself thinking 'keeping email in
a database, that sounds like a good idea' and then realised I'd nearly
reinvented Oracle*Mail and had to wash my brain out with carbolic soap.

(but I'm still going to try it, or actually USENET-in-a-database. I think
it could be done better than Oracle*Mail. God knows it's impossible to do
it worse.)

SQL engine uses

Posted May 16, 2009 21:14 UTC (Sat) by Wol (subscriber, #4433) [Link] (9 responses)

SQL may be a useful safety-net, but an SQL engine? WHATEVER FOR?

Pretty much EVERY post-relational database I know of (ie probably ALL of them) has a very capable SQL interpreter to access it, but they're certainly not based on a SQL engine - they're very much NFNF (non-first-normal-form) engines.

Cheers,
Wol

Database engine uses then

Posted May 16, 2009 21:34 UTC (Sat) by man_ls (guest, #15091) [Link]

I followed sylware's terminology, assuming he or she meant a database engine which accepts SQL. That is exactly what I find useful, regardless of the underlying engine. But thanks for the clarification.

SQL engine uses

Posted May 22, 2009 11:31 UTC (Fri) by sylware (guest, #35259) [Link] (7 responses)

Actually, I see a SQL engine (with its SQL shell) as a way to explore data (patch data to a certain extend), but certainly not to do the serious work since its software cost is huge (dependencies/complexity/size). That's a matter of choice and it's mine. Then I planned to connect an SQL engine (then its shell) to some of my data stores... unfornutately, they are almost all coded using C++ (the C++ compiler complexity,the C++ standard lib madness, and the C++ ABI of Hell made its use forbidden for me) and none had a clean C storage plugin interface (not even mysql). That was too much for me to bare, that's why I deciced to drop the idea of connection a SQL engine to my data stores.
The main issue I have with this Orable/mysql thing is that mysql is used in a lot of systems around the world, since I certainly do not trust Oracle whatever stuff they can say about how nice they will be to mysql, I know at the end it will hurt a lot the free software community. I'm going to look into 64bits mmaped files... does anybody know if I can extend the size of a file by remmapping it past its end?

SQL engine uses

Posted May 23, 2009 9:28 UTC (Sat) by nix (subscriber, #2304) [Link] (6 responses)

Um, PostgreSQL has clean connections between its various components and is written in C.

And yes, mmap() and extending: you're out of luck (portably). POSIX says:

The system shall always zero-fill any partial page at the end of an object. Further, the system shall never write out any modified portions of the last page of an object which are beyond its end. References within the address range starting at /pa/ and continuing for /len/ bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal.
...
Note that references beyond the end of the object do not extend the object as the new end cannot be determined precisely by most virtual memory hardware. Instead, the size can be directly manipulated by ftruncate().

Use the POSIX spec. You know you want to. (More to the point if you don't you have little chance of writing something portable).

SQL engine uses

Posted May 24, 2009 14:09 UTC (Sun) by sylware (guest, #35259) [Link] (3 responses)

POSIX mandates it's not possible to extend file size through mmap. Fine, but has Linux some syscalls to increase the size of a mmaped file? Or what would be the official way to increase the size of a file without the cost of a unmap/append data/mmap (POSIX and Linux way)? Another interesting thing would be support for sparse/mostly empty file. I remember to have read something about it... I cannot figure out where, maybe something related to ext4.

SQL engine uses

Posted May 24, 2009 14:40 UTC (Sun) by farnz (subscriber, #17727) [Link] (1 responses)

You can change the size of a file you have mmap'd. Look at ftruncate, then mremap to change the size of a mmap'd file and increase the amount you can use.

SQL engine uses

Posted May 24, 2009 16:12 UTC (Sun) by sylware (guest, #35259) [Link]

Seems great. Then the magic combo would be mmap/ftruncate/mremap. So I can expect no sigbus when ftruncating the file while mmaped. The only bad thing that could happen is a very costly mremap just after adding a few pages at the end of the file.

SQL engine uses

Posted May 25, 2009 15:36 UTC (Mon) by nix (subscriber, #2304) [Link]

You can mmap() sparse files just fine. Sparseness is invisible to
everything that talks to the VFS layer except in the results of stat().

postgresql

Posted May 24, 2009 14:17 UTC (Sun) by sylware (guest, #35259) [Link] (1 responses)

postgre has now a storage plugin interface? Last time I had a look, nothing was clear about that interface. I'm interested to see the complexity of the storage plugin interface for postgresql if you can give some pointers (if not, I'll have a look again at the code). Indeed, mysql interface (modulo its C++ dependency) seems quite easy to implement. On the opposite hand, the btree.h from sqllite is a nightmare.

postgresql

Posted May 25, 2009 15:38 UTC (Mon) by nix (subscriber, #2304) [Link]

No, the database format / storage engine of PostgreSQL is not pluggable.
However, that doesn't mean it isn't factored out in the source and thus
*separable* from the rest of PostgreSQL. (Actually I'm not sure it is: the
SQL parser and query executor are though.)

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Posted May 18, 2009 9:42 UTC (Mon) by sdumitriu (subscriber, #56869) [Link]

Am I the only one that expects something called "Open Database Alliance" to be neutral? Why is it so tied to MySQL? It is not the only database, and not even the only open database.