Washington is nicknamed “The Evergreen State” because it sounds better than “The Incessant Nagging Drizzle State”. -Dave Barry
According to Brian Akers the Seattle weather did indeed play a part in naming the anorexic web-optimized MySQL refactoring called Drizzle.
Brian was the main attraction at the combined PHP/MySQL meetup on March 2nd where he brought everyone up to speed on the history, current status, and future of the Drizzle project.
The History
Want to grab my attention? Start your deck out with a slide of an Amiga, I have been lusting after one since the 80′s! Apparently one of the reasons MySQL is so bloated is that it is full of code to allow it to run on every single platform which ever existed, including the Amiga. Brian told an amusing anecdote from his time with MySQL AB on how difficult it was to remove a platform from their build farm. It was reminiscent of the PC LOAD LETTER scene of Office Space involving two Swedes, an Alpha, a baseball bat, and a cellphone. You could almost imagine the scene: circuit boards shattering in the snow with some Slagsmålsklubben in the background. Besides the platform bloat there is UNIREG code from the dawn of time and support for basic features deemed unecessary: ACLs, MyISAM engine and new additions of stored procedures, views, triggers and query caches.
The Current
Drizzle has been designed as a micro-kernel system, similar to the design of Apache. API’s are available for the user to build in the options they desire – e.g. authentication, replication. Stored procedures will be written in “real languages”. The target platform they are designing for are the systems of the near future with 16-120 cores, 64 bits, with at least 2 GB of RAM. Drizzle uses Innodb for an ACID-compliant engine, uses UUIDs, and only has the UTF-8 charset. A C99 compiler is required and it should run on modern POSIX systems. The C++ code is being written in a true Object-Oriented manner, not C++ written in the style of C. The Drizzle team is making good use in using existing libraries as much as possible with the thought that the codewill be thoroughly vetted through widespread use – think libxml2, Proto Buffers, and STL.
Features include using PAM for authenication, hardening against SQL injection, rejection of bad data, less primitives – e.g. only one type of blob, no TINYINT. There is a multi-threaded scheduler which can accept multiple requests and return data asynchronously. Built-in sharding which can be utilized by vendors like F5.
The Future
The future may bring distributed hash joins, a REST API, and replication similar to the row replication of MySQL 5.1.
Participating
Brian emphasized that code drives decisions regarding Drizzle. The developers consider Drizzle development taking place in the Bazaar and not the Cathedral like MySQL. The current development team is made up of five Sun Microsystems employees and over 50 independent developers.