MySQL Falcon Storage Engine Open Sourced
An anonymous reader writes "The code for the Falcon Storage Engine for MySQL has been released as open source. Jim Starkey, known as the father of Interbase, is behind its creation; previously he was involved with the Firebird SQL database project. Falcon looks to be the long-awaited open source storage engine that may become the primary choice for MySQL, and along the way offer some innovation and performance improvements over current alternatives." This is an alpha release for Windows (32-bit) and Linux (32- and 64-bit) only, and is available only in a specially forked release of MySQL 5.1.
Get developed by a company that doesn't hate MySQL, for starters.
Dewey, what part of this looks like authorities should be involved?
OK, although I don't agree with it, I know that a lot of people use MySQL because it's the most common database supported by web hosts. Isn't it almost as likely for a hosting company to have PostgreSQL, though, as to upgrade to a bleeding-edge version of MySQL when this is finally readied for public consumption? Will this new backend give any extra functionality that PostgreSQL doesn't offer?
Dewey, what part of this looks like authorities should be involved?
Like others said already .. First of all, Falcon allows MySQL to not be as dependent on InnoDB as it is right now. When Oracle got hold of InnoDB, people had serious doubts about MySQL's future. For a solution like MySQL, it's always good to have competing (Even if similar) engines for it's own survival / growth.
But in something as mission-critical as a database, of all things, reliability trumps everything. I don't think they could have developed PostgreSQL any other way and still supported its primary goal of safety.
What gave you the (wrong) impression that PostgreSQL folks have been sitting around twiddling their thumbs? Version 8.2 just came out within the month and includes several performance boosts that make it fly on our production systems.
Dewey, what part of this looks like authorities should be involved?
Apparently, MySQL is a mish-mash of all kinds of different code. Heck, even the part that handles esoteric stuff such as stored procedures (note tongue in cheek) is part of some external module. I can't imagine that having multiple layers of API's is a good thing, considering how critical databases can be. Personally, I want my database to be consistent, and thoroughly tested, but the best being when the whole thing is designed to work together. Call me crazy, but it certainly does not give me a warm fuzzy feeling to know that stuff as critical as my database's file system is tacked on as an afterthought. (No, I don't use MySQL, primarily for these reasons).
This is easy and one of the tenants of so-called dual licensing setups...
Basically, if you don't want to pay to use the software, you are bound to the terms of the GPL. If you don't want to be bound to the terms of the GPL, you gotta pay.
Ron Gage - Westland, MI
Find Escorts, Strippers, Massage Parlours, Swingers
Microsoft SQL Server has had almost all of these features since its first release in the early 90s. MVCC was just introduced in Microsoft SQL Server 2005. There is no row-level compression in SQL Server (or Oracle, or DB2, or PostGreSQL... which is probably a *good thing* from a performance perspective).
This is a nice step forward for MySQL, but for the most part it is just a means for catching up to the other commercial DBs and PostgreSQL. ACID compliance, granular locking, MVCC, and multithreading are *not* differentiating features in the database world.
Actually, compression can improve performance. Often disk I/O can slow you down more than the extra CPU work to compress/decompress. I have written some flat-file processing code at my work and it runs much faster reading from and writing to zipped text files instead of uncompressed text files. The space savings are just a bonus.
Why would you be concerned about the license for a database? The licence is only important if you are modifying the code AND distributing the modified code. Most database users I know just install the binary and use that in which case you don't care if it's BSD or GPL licenced.
evil is as evil does
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
But in something as mission-critical as a database, of all things, reliability trumps everything. I don't think they could have developed PostgreSQL any other way and still supported its primary goal of safety.
...
I agree that reliability trumps all, but it sounds like you're saying Postgres was always super-stable. Not so, sadly
If you want to make crappy code into good code, you can. You just need to decide that you want to.
The MySQL guys *could* decide that version N+1 will be ACID-compliant, 100%, with every backend, and then work to make that happen.
Perhaps the damning thing about MySQL is not that they can't, but that they haven't chosen to.
InnoDB is licensed under the GPL. InnoDB is no more dependent on Oracle then Linux is on Red Hat. MySQL could if need be develop InnoDB themselves.
Except that a large chunk of MySQL AB's revenue would disappear as they'd no longer be able to sell a commercial version of their database with InnoDB support. And believe me, few people are going to buy the commercial version if the preferred storage engine is MyISAM. MySQL pay InnoSoft for the right to distribute the InnoDB engine as part of their commercial version - whether Oracle allows them to renew this agreement when it expires is somewhat doubtful.
It doesn't support foreign keys
Here's what gets me about MySQL. They say they have "pluggable" storage engines, but there's no clean abstraction. Each engine supports some things and not others.
Pluggable engines might be useful if the only differences are in the implementation, storage requirements, performance, and other administrative aspects. However, a constraint violation that will cause an error in one storage engine passes right through another storage engine. So, it's not like you can just swap one storage engine for another.
Social scientists are inspired by theories; scientists are humbled by facts.