There has been some great discussion lately about internal database schedulers and I/O handling on the Drizzle mailing list, and I thought I’d blog about it to summarize and see what others thought. These are ideas we’re toying around with for Drizzle, but they could be interesting for other databases (or other types of servers). The key things we are focusing on are modularity and concurrency. We also need well defined interfaces to allow anyone to come along and write/rewrite a component for their own needs.

History

First, a little background for those not familiar with Drizzle or MySQL internals. In MySQL, a client is accepted, assigned to a THD (thread) object, and is given an actual thread to run in. The client basically sits in a loop of reading a command, parsing it, executing it, and writing the result back. This works fine when …

I’ve spent the past couple weeks ripping out the old client library (based on libmysql) from the Drizzle client utilities (drizzle, drizzledump, drizzleadmin, …). I’ve replaced it with new code that uses the new libdrizzle. Brian merged this patch into the trunk yesterday, so we are one step closer to being rid of the old library! It is still used internally within the server, so my next task is ripping it out from there.

This means that the old library is no longer installed, so all new client and application development needs to use the new libdrizzle. It also means libdrizzle is now required to be able to build Drizzle. While I’ve done my best to convert the old utilities, I’m sure I’ve missed a few things. Please report any bugs you find with them. …

Reading “Test Center: Slacker databases break all the old rules” has finally inspired me to write this post, which I’ve been meaning to do for a while. The title of my post may be bold, but it is just one version of how things may go moving forward (and was meant to grab your attention). :)

First off, a few issues I have with the article mentioned above:

• “…tacking the two letters “db” onto a pile of code that breaks with the traditional relational model.” - Since when does a database need to be relational? Sure, relational databases are the most popular, but they are only a subset of all the possible database types (let’s not forget hierarchical or tuple stores).
• “None of them is right for everyone, and all of them are completely …

UPDATE developer_day_signup
SET name=YOU!
WHERE (attending_mysql_uc=True OR attending_percona_conference=True)
      AND shape_future_database=True;

This Sunday I’ll be flying down to the bay area for my final week of work at Concentric. The following week I’ll be starting as a full-time Drizzle/Gearman developer with Sun Microsystems. This was the position Brian Aker mentioned back in January.

Over nine years ago I was flying to the bay area for my job interview at Concentric. It’s been a great run and I’ve learned a tremendous amount there, writing everything from customized, multi-threaded HTTP and DNS servers to a clustered, hierarchical object database with a full query language. The environment at Concentric feels like a family, probably because a number of co-workers have been there even longer than me. It was a tough decision to make, and I …

Thanks to those of you who came to listen in on the webinar. I’ve posted the slides here if you want them. If you have any follow-up questions, check out #gearman on irc.freenode.net.

Living in Portland, OR, I was sad to see O’Reilly move OSCON to San Jose this year (don’t they have enough with MySQL, Velocity, …?). So what did the Portland locals do? Start their own:

Open Source Bridge (we have a lot of bridges here in Portland).

It looks like they just opened up their call for papers recently, quoting from their page: “Open Source Bridge is accepting proposals now through March 31st for our 2009 conference, which will take place June 17–19 at the Oregon Convention Center in Portland, OR.”

Tomorrow I’m going to be giving a free webinar on Gearman through MySQL. I’ll be describing the basics of Gearman and then look at a few common use cases. I’ll even be touching on some more advanced topics such as Map/Reduce and persistent queues.

Click here to sign up now!

I’ve been wanting to try something with libdrizzle since I added the server protocol interface. After an hour or two of hacking, I came up with:

lap> sqlite3 farm
SQLite version 3.5.9
sqlite> CREATE TABLE animals (
   ...>   name  VARCHAR(255) NOT NULL,
   ...>   sound VARCHAR(255));
sqlite> INSERT INTO animals VALUES ("Cow", "Moo");
sqlite> SELECT * FROM animals;
Cow|Moo
sqlite>

Next, using a new program I hacked together in the libdrizzle examples directory:

./sqlite_server -m -v farm 54321

Now, in another terminal:

lap> mysql -h 127.0.0.1 -u root -P 54321
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: libdrizzle+SQLite

mysql> INSERT INTO animals VALUES ("Sheep", "Baa");
Query OK, 0 rows affected (0.14 sec)

mysql> SELECT * FROM animals;
+-------+-------+
| name  | …

Building on top of my last post, the PHP extension for the new client and protocol library is ready as well! You can download the tarball on the Launchpad download page. The PHP extension exposes the same set of client functions that the C library provides currently, and is mostly just a wrapper to provide the PHP specific handling. To install, you’ll need the PHP development packages installed (if you have ‘phpize’ command you’re all set). After extracting the tarball, just run:

phpize
./configure
make
make install

And then add the following line to your php.ini:

extension=”drizzle.so”

I realize there is no documentation at this point, we’re working on that (please get in …