A look at the MySQL forksSun's sudden acquisition by Oracle triggered a deluge of speculation about the future of the company's free software projects: Java, OpenOffice, VirtualBox, OpenSolaris, and, most of all, MySQL. Will Oracle kill it? Spin it off? Keep its hands off? In light of this uncertainty, the discussion soon shifted to the trickier question of what branch constitutes the MySQL. The project has been forked multiple times — several even in the past year. Considering that each competitor is led by a heavyweight MySQL developer and has its own goals, how is a humble database administrator supposed to choose?
Patch sets and proto-forks
The seeds of this confusion predate MySQL's acquisition by Sun, when MySQL developers began to lose patience with MySQL AB's governance of the project. Management had announced two branches, "enterprise" and "community," in 2006, but soon began to miss scheduled binary and source releases of the community branch. Worse still, community developers complained that the company was trying to hide the enterprise branch code — changing the release location between iterations.
In 2007, Jeremy Cole of Proven Scaling took matters into his own hands, and set up a public mirror of the official "enterprise" releases as they appeared. Cole does not make changes to the code released by Sun, although Proven Scaling does publicly maintain its own set of patches and tools for MySQL — as do several other database consulting firms and MySQL users, including Google.
PerconaOne of those consulting firms is Percona, a web-development consulting business that emphasizes its expertise in MySQL. Percona develops a pluggable storage engine for MySQL called XtraDB. XtraDB is an enhancement to the popular InnoDB engine, designed to work as a drop-in replacement. It adds the ability to scale better on multi-core hardware, use memory more efficiently, and adds more tune-ability and metrics.
Percona's MySQL releases do not remove InnoDB to replace it with XtraDB, but do include patches to InnoDB. They also incorporate patches from other sources, including Proven Scaling, Google, and Open Query. Source and binary releases, as well as RPMs for Red Hat Enterprise Linux, are available for MySQL 5.0 and MySQL 5.1.
Percona's patch set is documented on the company's wiki. The patches include changes that add status variables, more configuration parameters, additional I/O settings, dynamic memory allocation, and alters mutexes and locks to improve performance on SMP systems.
OurDeltaOurDelta was launched in October of 2008 by former MySQL employee Arjen Lentz (now at Open Query), and describes its mission as providing "enhanced" MySQL builds for common production platforms. Its releases build on Percona's, adding additional patches (some from Google and other third-parties, some original work) and including additional storage engines.
OurDelta maintains two builds, one stable and one bleeding-edge. All stable releases so far have been for MySQL 5.0, and include the full-text-search-capable Sphinx storage engine. Upcoming work for MySQL 5.1 and MySQL 6.0 will add an enhanced version of InnoDB from Innobase, PBXT, and FederatedX storage engines. OurDelta makes source code releases available as tar archives, and runs binary repositories for Red Hat Enterprise Linux and CentOS, Debian, and Ubuntu.
OurDelta also documents its significant patches. In addition to the Percona patch set, OurDelta includes activity monitoring and reporting (per table, index, account, and machine), improved logging, an option to kill idle database connections, the ability to temporarily freeze InnoDB for backup purposes, and improvements to speed up failover.
MariaDBMySQL founder Michael "Monty" Widenius started his own fork in February of 2009 after leaving Sun. At the time, he said his reason for departing was dissatisfaction with Sun's development and community processes for MySQL, which was not "a true open development environment" that encouraged outside participation.
Widenius's fork is called MariaDB, and the only major change is that it uses the Maria storage engine, which is the focus of development. The rest of the code is regularly synchronized with MySQL releases from Sun, and is intended to be one hundred percent interoperable.
The Maria storage engine is an evolution of MySQL's default MyISAM storage engine, and is designed to duplicate the features found in InnoDB, notably crash recovery and full transactional support. Maria and MariaDB are being developed against MySQL 5.1. Widenius expects the Maria engine to be a standard part of Sun's MySQL 6.0 releases, but intends to keep developing MariaDB even after MySQL 6.0 is stable. So far, the project has released source code packages and generic x86 binaries for Linux.
Widenius maintains a wiki page documenting the advantages of MariaDB over Sun's unmodified MySQL, focusing on the features of the Maria storage engine. Aside from the larger goals of crash-safety and transactional support, he notes that using Maria as a storage engine should speed up complex queries. In addition, MariaDB contains speed improvements, the ability to use a pool of threads to handle queries (rather than one thread per connection), and bugfixes not accepted by Sun.
DrizzleDrizzle is the most distinctive MySQL fork, perhaps better described as a complete refactoring. Drizzle is the work of Brian Aker, long a preeminent MySQL developer. He announced the project in July of 2008, saying that he disliked many of the changes made to MySQL after version 4.1, and felt that there was a large market of users that did not want them. Despite launching the fork, Aker continues to work in the MySQL group at Sun.
Drizzle cuts the core of MySQL down to the bare minimum, using a microkernel-and-modules approach. The goal is to create a slimmed-down, optimized database targeting web infrastructure and cloud components.
Aker said that Drizzle will question the foundations of database design, and is not intended to be SQL compliant. The FAQ emphasizes a "look forward, not back" philosophy. For example, Drizzle targets modern, multi-core hardware, modern compilers, and modern operating systems. Similarly, the development team is not interested in feature requests or in adding excised MySQL features back in. Thus far, the project had made only source code releases, and has noted that they are not yet stable for production use.
ConclusionThe major Linux distributions all package Sun's "community" version of MySQL. Sun itself provides free downloads of the community edition from the web, evidently having learned a lesson from the 2007 uproar. Sun's official packages are likely to be newer, given the release cycles of most distributions, and to its credit Sun makes binary builds available for a wide variety of processor architectures and distributions, including older releases of those distributions. For most users, such a supported build is usually the best choice. The Percona and OurDelta packages represent the work of in-the-field MySQL consultants, and MariaDB is focused on the Maria engine, but only experienced database administrators are likely to be able to take advantage of the additional features they offer.
Still, it is telling that so much of the work done by the forks centers around the InnoDB storage engine: the patches written by Percona and OurDelta, Percona's replacement engine XtraDB, and MariaDB's replacement engine Maria. InnoDB is GPLv2-licensed, but the copyright is owned by ... Oracle. Oracle acquired InnoDB's creator Innobase in 2005. That acquisition sparked a flurry of concern that the database giant would kill the product, take it proprietary, or somehow use it against MySQL — many of the same nightmare scenarios now speculated about the Sun purchase. It is worth noting that in the intervening years two things have occurred: Oracle has not killed or maimed InnoDB, and the open source community has preemptively created its own innovative solutions, thereby insulating open source users and customers from disaster should Oracle take a step in the wrong direction.
The real question is not which fork is the MySQL, but whether the multiple patch sets and forks indicate sickness or health for MySQL as a whole. Excluding Drizzle, all of the projects were started because someone who cared a great deal about the future of MySQL saw something wrong with MySQL's development process (and for its part, Drizzle was spawned by even deeper dissatisfaction with the technical direction of MySQL). Surely that much concern on the part of the community signifies health. There is no telling which forks will prosper and which will fizzle out, but that depends to a large degree on Oracle, and how it governs the project in the future.
Source
Envoyé par Apen_
