I got several comments and questions on my previous blog "The State of the MySQL forks". One question was "Why didn't you mention Drizzle?" So I will say something about Drizzle here before concluding with other remarks.
So why didn't you mention Drizzle?
Mainly because the post was already long and also I had to wrap up and call into a meeting.
But yes, it is also true that if something was to be cut out, not mentioning Drizzle can be justified in a couple of ways. It is true that Drizzle adoption is nowhere close to Percona Server and MariaDB, for instance. Also, Drizzle is different enough that it is not a drop-in replacement like the 3 other forks are of each other. So it is not possible to just mention it in passing as an equal alternative, it would in any case require more explanation to give an accurate picture.
How different?
Even though InnoDB is the underlying engine, the data format is different. With the other 3 forks you can just switch between them with an rpm/apt install, but to move to Drizzle you actually have to mysqldump (or rather, drizzledump) your data to put it into a drizzle database. Some small changes will be necessary in the migration, for instance you must convert the character set of your schema to UTF-8, which is the only character supported in Drizzle. Of course, you also need to get rid of unsupported features like views, triggers and procedures.
Other than that, it's not too much different. A MySQL user like myself will immediately feel at home in Drizzle. SHOW commands and INFORMATION SCHEMA are there, and the SQL syntax is the same. It's a comfortable choice and much easier to go to than, say, PostgreSQL.
So what is the big picture?
While the MySQL ecosystem is in many ways doing very well nowadays, my criticism of it usually falls under the umbrella of "I wish we could make it a sane open source community like Linux, Drupal, Libreoffice... basically any other open source project out there". To start with the positives, this is Drizzle's strong point. I remember when it was launched in 2008 it was like a breath of fresh air. Monty Widenius welcomed it with these words:
My personal reaction to Drizzle is that I am very enthusiastic for this new kid on the MySQL block. I don't agree with everything that is done, but most things makes a lot of sense. I am looking forward to a lot of very interesting discussions about solutions in Drizzle that will help improve both MySQL versions.
In 2008 Drizzle immediately gathered over 50 code contributors, which was a testament to the pent up demand for a more open fork that existed already back then. Today it is not quite as vibrant, but in terms of diversity it is still far more community oriented that either of the other forks. In the past Spring there were still around 30 different code committers. Many of those (roughly 20) are students driven by their interest to apply for Google Summer of Code. This way Drizzle serves as an excellent entry point for new young talent to join the wider MySQL ecosystem too.
In addition to the diversity of the developer pool (all other forks are primarily developed by employees of their vendor) Drizzle is also formally governed by a non-profit: Software in the Public interest.
Can you summarize Drizzle pros and cons?
The pros would be the re-factored, modern and modular code base. Last year I had a lot of dead time at work (months, in fact) so I ended up actually developing a few Drizzle plugins. (JavaScript support and JSON HTTP API.) It was really delightful experience.
It is also worth pointing out that Drizzle 7.1 is ok to use, even for production. During the time I have been involved I haven't seen any crashing bugs or data corruption bugs reported. Drizzle 7.0 (the first stable release) had several cases where it would crash during startup phase, such as when reading an invalid configuration file. But even that version didn't - as far as we know - have any instability once actually up and running.
On the con side the major issue is lack of polish, and lack of attention to actual end user needs. This was already apparent in the long time to market Drizzle took: The developers enjoyd rewriting the code base so much, they didn't produce a stable release for 3 years! MySQL too used to have a 3 year release cycle, but that was the good old days. Nowadays quite a lot happens in 3 years. So even if Drizzle was the earliest fork of the ones still alive, it was the last one to actually deliver a stable GA release. It is possible that in terms of getting end user adoption, Drizzle did lose the window of opportunity there.
The list goes on: Like I said, the 7.0 version actually wasn't that great in handling various error situations in configuration, and I know of cases were testers gave up on Drizzle due to those bugs. Still today there isn't an example configuration file that would get you easily started. Nor does the project offer binary tar or rpm packages, so unless you are on Debian or Ubuntu, you need to compile it from source yourself. MariaDB, Percona, even PostgreSQL (which used to be known as too geeky and unfriendly) provides packages in nice apt and yum repositories, MySQL provides packages but not a repository. Documentation and code comments, of course... So yes, sometimes I feel the Drizzle developers only did Drizzle for themselves, and they don't really care whether anyone is ever going to use Drizzle as an end user or not.
The other complaint is a bit surprising: Lack of open communication on behalf of the core developers. I don't know why, but almost all Drizzle core developers use exclusively off-list private emails or Skype. To an outside observer or newcomer this makes the project look either dead or closed. A case in point, except for myself and the student I was mentoring, the other 5 GSoC students have managed to complete their semester without a single email to the mailing list. It is somewhat ironic that the community friendly Drizzle comes out looking pretty bad here. For instance if you go and look at maria-discuss, maria-developers and #maria IRC channel, there is activity every day. The Drizzle developers should really kick themselves on this point.
So would you recommend Drizzle?
If you want to hack on something in the MySQL space, Drizzle is a good option. The code is easier to approach than the classic, backward compatbile MySQL forks where some dark corners of the code date back to early 90's, maybe 80's. Also for me personally it is more satisfying to work on a community project than to donate my code to a vendor who wants to own it - I know this is not an issue for everyone.
Also, if you are able to commit a lot of time, Drizzle offers a good opportunity to actually take on a lot of responsibility in a relatively big and high profile open source project. For instance one of our GSoC students is now responsible for release management - something to put on your CV for sure.
Drizzle is also quite ok to use for end users. But I would mainly see it attractive to the more geeky users, for instance those that actually enjoy or prefer compiling their software from source code. Or you might want to support Drizzle for "political" reasons if you prefer community developed open source projects over vendor controlled ones.
Finally, Drizzle certainly has a lot of potential. The refactoring took long, but it is done. The modular architecture provides a lot of possibilities for rapid innovation. If some organization is looking to invest in significant development on a MySQL codebase, Drizzle is certainly an option. And like I said, some players may prefer to choose a neutral community zone instead of picking a vendor fork.
In practice, Drizzle adoption is still clearly lower than either Percona Server or MariaDB, and most end users will simply follow the masses. This is a bit sad for everyone that believed that there was demand for a more open approach to MySQL development. But it also proves one important point: open is just one thing, you also need to deliver, and not just deliver but you need to deliver against the competition.
Those that know my views on this subject know how hard it is for me to say that in public, but I also always wanted to be objective, so there you have it. Drizzle has lots of potential, but not yet enough end user focus.
- Log in to post comments
- 20411 views
What is unfriendly on PostgreSQL?
Hello
can you say, what is unfriendly on PostgreSQL?
PostgreSQL Unfriendly, nah
I don't think he said unfriendly. Just "much easier to go to than, say, PostgreSQL".
To be fair, as a PostgreSQL user and not even having used Drizzle, I agree with him on that statement if you are a MySQL user. I think if you come from MySQL, Drizzle is probably much easier to understand if nothing more than the general commands etc you would use are much the same as MySQL. Of course having to compile my own code would turn me off and the fact that there are no windows binaries for Drizzle to my knowledge would also turn me off as a windows user.
I said "used to be known".
I said "used to be known". The traditional stereotype is that MySQL would contain a lot of non-standard small convenience features, perhaps the best known is the LIMIT clause. Postgres otoh used to be known for security and advanced features, but less focus on ease of use. As an example, when I used Postgres for the first time around 2000, it took me a really long time to figure out I need to "su - postgres" before I can "createuser" and finally login to Postgres. (With MySQL, you just login as root without password, which is simple and user friendly, but...)
To be clear: Postgres has improved on this point many years ago. My whole point in this blog post is that a modern open source project needs to focus on user friendliness to remain relevant at all. Postgres certainly is above that bar today.
Oh, now that I think about
Oh, now that I think about it, I've actually heard a MySQL oldtimer say that PostgreSQL community was elitist and unfriendly in early 90's when he wanted to engage with it - before MySQL even existed. (From what I understood, he meant in a similar way like linux kernel mailing list is considered hostile by many people.) I probably was thinking of this statement when I wrote this.
It's very true that I tried
It's very true that I tried to ask development questions on drizzle-dev IRC channel but got no responses with all my attempts, the email list has almost no traffic except 1-2 questions and blog post like yours.
I'm a very new comer to Drizzle and makes it really hard to contribute where as in other projects I always have someone to ask question about the code.
Do ping me directly on irc
Do ping me directly on irc (stewart) and if i'm around I can certainly help. Odds are, if it's during my work day, I have a Percona internal IRC open and may not see other general messages in other channels.
The silence on IRC is
The silence on IRC is understandable, when developers work on their free time and not office times. The silence on the mailing list is inexcusable.