*************************** 1. row ***************************
Message: ♥❤♥ Happy Valentine's Day ♥❤♥
1 row in set (0 sec)
I may be British, but I am no MI6 spy (and I'm certainly no Sean Connery). Although the 007 reference is still relevant because we are nearing the first GA release of Drizzle7.
This week is a special week for many reasons. First of all, probably the most obvious, it is Valentine's day (yes guys, the flower shop is still open, run before she finds out you forgot!).
Probably not quite as important, depending on your relationship status, is Drizzle's first RC release will be out over the next couple of days. The amount of work that has gone into Drizzle is staggering, even the 6 months I have been working on it full-time has seen an amazing amount of change. For those who don't know about the Drizzle project, here is a quick recap:
Drizzle is a microkernel database primarily aimed at web and cloud installations. It started life in 2008 as a fork of MySQL 6.0, since then it has gone through extensive changes such as migrating a lot of functionality into a new plugin architecture so that parts can be changed easily. It uses InnoDB as it's primary storage engine, much like MySQL 5.5 and has much the same SQL syntax to MySQL. There are many things that have been ripped out of Drizzle that are in MySQL as part of this process but also many more things that have been added in, mainly as plugins.
For example, Drizzle does not have stored procedures. That is not to say it cannot or won't have them, and with the plugin architecture it would be quite easy to add them, but we feel in a cloud environment that logic should be at the application layer. If we find many people need them or a developer wants to work on them, we would be happy for plugins to exist to implement this.
We have modified the parser so that it is a bit stricter, by this I mean if the database can't figure out what you mean it errors instead of making assumptions which can lead to bad data. UTF-8 is the only supported character set, supporting multiple character sets is very useful in some scenarios, but the web is pretty much all UTF-8 now and confusion and corruption could occur if character sets are not handled correctly.
There is a testing build of Drizzle made every two weeks which is basically just a tagged release of our trunk, we run a full regression and benchmark suite on every merge to the trunk to make sure that it is constantly stable, so the fortnightly tagging is not a mad fight to get things stable.
Speaking of which, I'd like to thank the many community users and Rackspace DBAs who has tested Drizzle so far, the feedback has been amazing and we have made many improvements to Drizzle and the documentation due to this.
Is Drizzle fast?
I'm not going to benchmark MySQL/Postgres/Oracle/etc... vs. Drizzle as I can probably make any database look favourable in any such benchmark, I'll leave that to unbiased third parties to decide. But we do benchmark every single build to check for any performance regressions and indeed improvements. This information can be found in our benchmarks mailing list. In my personal opinion, we should be very fast at most things.
So, what can you expect to see in Drizzle7 RC?
I have gone over many of these in previous blog posts but here is a recap of a few things:
- Drizzledump can do on-the-fly MySQL->Drizzle conversions without an intermediate file
- Microsecond precision for TIMESTAMP data types (note that it is the 6th anniversary of the MySQL feature request for this tomorrow) as well as all-new data types
- The framework for an entirely new and portable replication system
- Basic Catalogs support (much more to come here)
And this is just a few of the recent changes. Going over changelogs I could probably make this list many pages long of really exciting features. Don't just take my word for it though, try it for yourself!