Drizzle: Rethinking the MySQL Database Kernel

Drizzle is a re-thought and re-worked version of the MySQL kernel designed specifically for high-performance, high-concurrency environments. In this exclusive article, MySQL guru Jeremy Zawodny takes an inside look at the goals and state of Drizzle development.

What’s New?

The old MySQL protocol and the client libraries have been re-thought and re-implemented.  The protocol work itself is now part of the libdrizzle sub-project that’s used by both the server and client utilities, as well as any other projects that wish to talk to Drizzle servers.  Aside from simply being more efficient, the protocol allows for checksums on data, has built-in sharding support, and support for connecting via TCP, UDP, and Unix Domain Sockets.  When used over TCP or UDS, the protocol is “full-duplex”, which means that the  client and server can preempt otherwise long operations to cancel them or provide additional information (errors, warnings, and the like).

To ease migration, libdrizzle completely supports the MySQL protocol as well, so you can build applications using libdrizzle that talk to either Drizzle or MySQL servers. If you ever move from MySQL to Drizzle, this feature will be invaluable. If you’d like to know more, have a look at the Drizzle protocol draft.

The on-disk format for table definitions (.frm files) has been replaced with a representation based on Google Protocol Buffers. This removes a lot of custom code from the server and makes it easier for other tools to understand table definitions as well.

While not an end-user feature, the development model around Drizzle is new, too. It’s completely open (unlike MySQL) and is very easy to get involved with. Testing is a big focus for the Drizzle team. When the team compiles Drizzle, every compiler warning is treated as an error, and each new build is checked against previous builds for any performance regressions.  When a regression occurs, no new code is committed to the trunk until the source of the regression has been identified and fixed. A recent example involved the tcmalloc library.

Brian Aker discusses some of the testing philosophy in Drizzle, State of Testing.

Getting Involved

As noted earlier, Drizzle has a very open and approachable development model. The first thing you’ll probably want to do is check out and build a copy of the source code. That means building and installing both libdrizzle and Drizzle itself.

You’ll need a few prerequisites, many of which are probably already on your system, but the configure script will notify you of any omissions.  The most problematic tends to be Google Protocol Buffers. You may need to build and install the package from source if the package repository for your distribution doesn’t have an up-to-date version available.

Once you have the prerequisities, the builds are simple enough.

$ bzr branch lp:libdrizzle
$ cd libdrizzle
$ ./config/autorun.sh
$ ./configure
$ make
$ make test
$ sudo make install

$ bzr branch lp:drizzle
$ cd drizzle
$ ./config/autorun.sh
$ ./configure
$ make
$ make test

The commands yield an installed copy of libdrizzle and a locally-built Drizzle server that you can start (without installing) by simply running drizzled/drizzled --datadir=/tmp.

And then you’re off and running. You can connect to the Drizzle server and use it in much the same way you use MySQL today.

To get move involved, here are some links to visit:

Keep in mind that the Drizzle team does not believe that Drizzle is ready for prime-time yet. However, that hasn’t stopped some people from using it on a daily basis.

Nonetheless, the project is still evolving at a rapid pace, so if you do plan to use Drizzle soon, it’s best to stay informed about what’s going on in the project. And, by all means, report any bugs you find!

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62