Log in

No account? Create an account

New in Drizzle, 2009.10.1178

« previous entry | next entry »
Oct. 13th, 2009 | 09:22 am

Welcome to the metronome, every two weeks we drop a release of Drizzle.

Which makes it sort of boring to blog about each release since they are consistent :)

But no two releases are really the same, and this last one had a bit of fun in it:

drizzle> CREATE TABLE A (a int) ENGINE=Archive;
Query OK, 0 rows affected (0 sec)

drizzle> create table B like A ENGINE=innodb;
Query OK, 0 rows affected (0 sec)

drizzle> show create table B;
| Table | Create Table                                              |
| B     | CREATE TABLE `b` (
   `a` int DEFAULT NULL
1 row in set (0 sec)

Being able to specify an engine when doing a CREATE TABLE LIKE has been long on the list of things to do to make the server more orthogonal for a while now. You would think it would have been easy to do, but it never really was. In MySQL we didn't have a data dictionary so a command like the above was just a "copy the frm file in place/tell the engine it exists". Which does work, but it didn't make it very simple to manipulate. Sure, it could have been done, but it wasn't all that simple.

For Drizzle we just ask the StorageEngine factory "find the engine with this definition and had it back to me as a proto". Once we have the proto we just make any changes we want to it, and then tell the StorageEngine factory "go create this". After that? It gets sent to whatever engine is supposed to create the table and the table gets created. How the data is stored is up to the engine. The advantage of the federated data dictionary is that engines own their own table information. No 2PC is required for creation and network based engines are free to track their own changes. Pretty handy :)

Another thing that is changing is our parser. Drizzle's parser no longer knows or confirms engines. It simply parses the statement and lets the execution system validate the state or existence of the engine (this is making way longterm for the future where parsers just parse... validation belongs elsewhere in the execution pipe). Our execution system no longer exists as a giant switch/case system. Instead we just generate an object and pass that along for execution. A big advantage we were able to realize because of this was that all of our DDL structures are no longer included in the global Lex structure.

Gearman functions were updated with this release, so we have up two date functionality happening with our integration there. Replication is continuing to evolve and as of this version we now have information schema tables that report on the state of whatever memcached cluster we are attached too. Memcached support that is built into the server didn't make it in this release, but I expect to see it in next week's.

Latest version of Bell, our current release milestone, can be found here:

Link | Leave a comment | Share

Comments {1}


(no subject)

from: raa
date: Oct. 15th, 2009 05:58 am (UTC)

Brian, one of the things I'd like to have in MySQL/Drizzle is table cache optimization for "equal" shard tables with the only difference in names. When you have lot of these tables (which is usual for sharded environment - especially on backup servers) your table cache may eat up to 50% of the buffer pool which is so ridiculous. Are you going to implement this in Drizzle?

Reply | Thread