![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
I put together the following diagram to explain what the origin of the current MySQL forks and deltas looks like:
But in the distributed revision control world we live in, it's never really that simple. Here are some other notes:
- XtraDB is an InnoDB fork and "mostly" only a storage engine. It has a future in MariaDB and Drizzle, but may not make it into MySQL (about to be owned by Oracle, who also owns InnoDB).
- OurDelta collects more patches than just the Percona patches, and enables the PBXT storage engine. There's also a repository of OurDelta for 5.1 - binaries just aren't out yet.
- Like XtraDB, PBXT has a future in Drizzle, MariaDB and *maybe* also MySQL (Oracle may be more friendly towards PBXT than XtraDB, but Oracle is not known to be friendly so who knows!). I left PBXT absent from the diagram for not having much of a lineage with previous MySQL releases (flames welcome if you disagree).
- XtraDB draws a lot from the Google patches for MySQL/InnoDB (not present on the diagram either).
- Drizzle is now incompatible with everything else in MySQL-land terms (replication, partitioning, etc), and they're happy to be. In storage engine terms, they're still compatible though, which leads me to describe Drizzle as a completely new "userland", with storage engine options still remaining very similar.
- MariaDB is both a new storage engine (Maria) and a userland "delta" of MySQL. I call it a delta since it is trying to keep binary-format compatibility with MySQL wherever it can. This means that it makes a good retrofit, but it limits what they can do without changing things like the .frm format, etc.
- The InnoDB plugin has a weird history. Oracle announced it as an optional replacement for the 5.1 InnoDB but not much has become of it since introduction. I would have expected 5.4 to be based off the plugin, but it's not (at least at this point).
- MySQL is the real loser in the direction the patches are moving. While all other forks are free to share amongst themselves (where compatible) and take from MySQL, MySQL will only accept a patch if the author signs a Contributor's License Agreement. They need to do this - otherwise they can't sell OEM copies, which still make a large chunk of sales. Until recently, MySQL didn't accept any InnoDB patches unless they came downstream from Oracle, and Oracle keeps InnoDB development as a closely guarded secret - which makes influencing it very difficult.
Comments welcome.
Anonymous
August 7 2009, 20:06:25 UTC 2 years ago
InnoDB plugin
Can InnoDB plugin be used as a plugin for 5.4?When 5.4 comes out, will there be XtraDB based on that?
August 7 2009, 20:49:55 UTC 2 years ago
Re: InnoDB plugin
"Can InnoDB plugin be used as a plugin for 5.4?"In theory, yes. According to the MySQL manual it is planned - " a future version of MySQL 5.4, the InnoDB Plugin will replace the (built-in) version of InnoDB currently distributed with MySQL."
http://dev.mysql.com/doc/refman/5.4/e
"When 5.4 comes out, will there be XtraDB based on that?"
5.4 and XtraDB have a strange relationship, since they are both (in many ways) the downstream product of the Google patches. So, to put it another way "XtraDB already has 5.4 in it." There were a few cases where the Sun 5.4 implementation showed better performance than XtraDB, but Percona started backporting straight away:
http://www.mysqlperformanceblog.com/200
There are some diagnostic tools like slow query log enhancements and INDEX_STATISTICS that won't make it into 5.4 - which means 'no deal' from my perspective.
When customers demand it though, I'd expect Percona will upgrade to 5.4 since it will contain other userland fixes (like RESIGNAL and subquery optimizations).
(Disclosure: I work for Percona, but this blog reflects my personal opinions, not their's).
Anonymous
August 7 2009, 21:12:04 UTC 2 years ago
libdrizzle is extra compatible..
Great write-up Morgan.I just wanted to follow-up to "Drizzle is now incompatible with everything else in MySQL-land terms (replication, partitioning, etc), and they're happy to be." That statement is pretty darned true from a systems level, but I'd like to point out for folks that our new client library, libdrizzle, speaks MySQL as well. This means that things written with it, or its wrappers (such as DBD::drizzle) can happily talk to both MySQL and to Drizzle.
Just didn't want folks to think we don't care... :)
August 7 2009, 22:53:18 UTC 2 years ago
Re: libdrizzle is extra compatible..
Thanks... for some reason thinking about drivers and protocols escaped me when I wrote this!August 13 2009, 16:04:03 UTC 2 years ago Edited: August 13 2009, 16:06:53 UTC
Cool Article. A couple of points:
1) We find that most MySQL applications "just work" with Drizzle. We are not 100% compatible, but if you are just using ANSI SQL there shouldn't be an issue.
2) BlitzDB is a fork from Drizzle (and we have distributions which are are for PBXT as well).
3) I would put up "distributions" and "forks". Many of the above are just repackaging (though I believe long term they will all be forks).
4) I would list "InfoBright" as a fork of MySQL as well. I am not sure how compatible they are, but they deserve some mention because of their own adoption. I believe it was forked from 5.0.
5) MySQL Carrier Grade is a fork as well (I think from 5.1... they are now on 7?).
This would make for a great Wikipedia article :)
Cheers,
-Brian
August 13 2009, 18:18:16 UTC 2 years ago
Thanks!
You gave quite a lot of feedback there, so I just wanted to comment on it:"1) We find that most MySQL applications "just work" with Drizzle. We are not 100% compatible, but if you are just using ANSI SQL there shouldn't be an issue."
Point taken. From my perspective I drew the picture to explain to users that it isn't forking in every direction with a lot of lost development effort - I completely omitted user experience.
"2) BlitzDB is a fork from Drizzle (and we have distributions which are are for PBXT as well)."
Great!
"3) I would put up "distributions" and "forks". Many of the above are just repackaging (though I believe long term they will all be forks)."
How much has to change to be a fork is always a sensitive issue. I'm not sure if you meant to include Linux distributions as "distributions", but that's how IceWeasel started, etc.
I think distributions is a better word than Deltas.
"4) I would list "InfoBright" as a fork of MySQL as well. I am not sure how compatible they are, but they deserve some mention because of their own adoption. I believe it was forked from 5.0."
Acknowledged. Kickfire probably counts here too - I know a lot of the data warehouse SEs all had to change quite a few things.
"5) MySQL Carrier Grade is a fork as well (I think from 5.1... they are now on 7?)."
I think MySQL would like to think of it as a Delta, but sure ;)
"This would make for a great Wikipedia article :)"
I had no intention of it - but maybe that's not a bad idea. If anyone reading this blog wants to build off my work, then I grant permission to do so.
August 13 2009, 18:38:34 UTC 2 years ago
Re: Thanks!
The difference between distribution and fork I believe is intention. For Drizzle, we are a fork. We keep some compatibility, but far from all. MariaDB/Percona are shooting for a high degree of compatibility and I don't believe they would consider themselves to be a fork (and they shy away from incompatible changes).The word "delta" I think is just an attempt to soften the term (I think...).
The reason I would consider the telecom version a fork is that it has several features which are not found in the main branch, and from external observation it does not look like these will go back in. This is speculation though on my part, I have no direct knowledge of what they do/etc.
One other thought about your tree, I would put in the ancestors to MySQL, aka Unireg and MiniSQL. That piece of history that tends to be forgotten (though how much code/design was taken from MiniSQL... I doubt we will ever know).
October 29 2010, 03:56:27 UTC 1 year ago
Re: Thanks!
"I think distributions is a better word than Deltas."It seems like branches is the ideal semantic compromise to describe XtraDB and friends. It even works well for explaining the strange "InnoDB Plugin" situation. The branches have diverged from their parent, and replace parts of it, but without the permanent disconnect implied by a fork.
Thanks for the excellent summary post on the issue. The history was concise and the kind of stuff that's really useful.
August 17 2009, 16:16:57 UTC 2 years ago
Log Buffer #158
June 5 2010, 10:40:00 UTC 1 year ago
порно журналы 80 х годов
MESSAGEAnonymous
January 5 2011, 16:42:46 UTC 1 year ago
Транвеститы порно
[url=http://megafreeporn.ru/]порно изнасилование лезбианок[/url]
порно с помпой видео онлайн
малолетки 10 лет порно бесплатно
(http://megafreeporn.ru/)
Anonymous
January 22 2011, 05:37:01 UTC 1 year ago
Great Post
You certainly deserve a round of applause for your post and more specifically, your blog in general. Very high quality materialAnonymous
January 26 2011, 01:31:12 UTC 1 year ago
Good Blog VPS
I find myself coming to your blog more and more often to the point where my visits are almost daily now!Anonymous
March 22 2011, 19:16:05 UTC 1 year ago
EnhactJantWet
Very Interesting Information! Thank You For Thi Post!Anonymous
October 18 2011, 04:44:08 UTC 7 months ago
few questions about Percona
i have few questions about Percona that i would really appreciated if you help me with.Q. Does it run on Windows?
Q. Does it provide a JDBC driver to access them from within Java and optionally be accessible from PHP?
Q. Does it support the SQL standard?
Q. Does it have any problems managing 20 GB of data per table / 50 million rows per table?
Q. Does it support hot backup for huge databases (how to back up 50 GB of data without
shutting down the server / locking tables)
Q. Does it support foreign key constraints?
Q. Does it support transactions?
Q. Does it provide setup of replication? master/slave replication and easy failover (slave
becomes master if master fails
Q. Does it provide configuration of the server?
Q. Does it support triggers?
Link to source:
Q. Does it provide better tool support for SQL queries? N/A
Q. Does it support concurrent access?
Link to source:
Q. Does it support sub query performance
Q. Does it provide automatic intelligent query optimization ?(database analyses queries
over time and automatically creates indexes to improve performance).
October 18 2011, 12:10:47 UTC 7 months ago
Re: few questions about Percona
You really should be asking these questions on Stack Overflow / Percona's forum.Q. Does it run on Windows?
http://www.percona.com/mysql-support/po
Q. Does it provide a JDBC driver to access them from within Java and optionally be accessible from PHP?
Doesn't change from MySQL.
Q. Does it support the SQL standard?
Doesn't change from MySQL.
Q. Does it have any problems managing 20 GB of data per table / 50 million rows per table?
No (unless you do something stupid). From a database internals perspective "size" is only one metric which describes difficulty (concurrent access, all data being hot are much harder problems.)
Q. Does it support hot backup for huge databases (how to back up 50 GB of data without
shutting down the server / locking tables)
Yes (xtrabackup).
Q. Does it support foreign key constraints?
Yes, so does regular MySQL (innodb).
Q. Does it support transactions?
Yes, so does regular MySQL (innodb).
Q. Does it provide setup of replication? master/slave replication and easy failover (slave
becomes master if master fails
Not any more than regular mysql.
Q. Does it provide configuration of the server?
There are more configuration options than regular MySQL.
Q. Does it support triggers?
Not any more than regular mysql.
Q. Does it provide better tool support for SQL queries? N/A
Not any more than regular mysql.
Q. Does it support concurrent access?
Yes.
Q. Does it support sub query performance
No.
Q. Does it provide automatic intelligent query optimization ?(database analyses queries
over time and automatically creates indexes to improve performance).
No.