ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life

More Drizzle thoughts

I am very glad to hear that Brian's vision for Drizzle seems to be quite pluggable. This hits home perfectly with my hopes .. well for Drizzle to be pluggable! While I have not had the time to install and play with Drizzle I did stumble over the list of what has been dropped from MySQL so far. I am not sure how complete this list is (for example VIEW's are not listed as having been removed, but it was said that they would be removed), but I assume that nothing on the list is on there falsely. So some brief observations:

1) No windows support, not really surprised about that one. First I assume that none of the developer are interested at this point to worry about Windows, nor do I think that there is much of a Drizzle target audience running Windows servers. That being said, plenty of developer are running windows on their laptops, and it was always tricky to deal with getting them up and running on an Oracle or whatever project. In one project I actually let the developers use MySQL for development using a DBAL. I then personally made sure that all queries would run on Oracle.

2) Apparently UNIX socket support was also dropped. This kind of surprised me. For all I know most people rely on fast connection creation using UNIX sockets to connect to a local slave, rather than hitting a central server via TCP.

3) Server level timezone support is out. Good, I presonally hate this crap that lets you configure timezone's and other locale stuff in the server. Leave that to the middleware. Would be nice to be able to store the timezone in DATETIME (or DATETIMETZ) though, so that I can do the work in the client.

4) FULLTEXT/Spatial indexes are out. Not sure what this really means. MySQL 5.1 has support for pluggable FULLTEXT indexes. So was this approach not good enough? Is the Drizzle team maybe pondering a rewrite of this code area? I thin pluggable index types could be quite useful for the workload that Drizzle is targeting.

Anyways, hope that sooner rather than later I get some quality time with Drizzle. What I found a bit odd is the location of the Drizzle wiki, or is it maybe not _THE_, but just _A_ Drizzle wiki? I do not really see the need to see big square ads on the Drizzle wiki. I am sure the community can afford an ad free wiki for Drizzle in case it did not fit into the Sun budget.


Re: More Drizzle thoughts


1) Windows Support. I believe that by the time we are done we will have Windows support. How? I am not really sure but I think we will have it.

2) The UNIX socket support was a mess. It was easier to drop it and add it back, then try to fix it. Once I have the full schedular loop finished it will go back in (it is not more then a few dozen lines). It will not come back in as he default connection method though. That caused several bugs in MySQL.

3) Thanks for the suggestion, I will keep this in mind. We will be adding subsection support as well, so extending the type further is easy. Though TZ support complicates the issue of sorting.

4) The MySQL support for this was only good for a few million rows at best. I also think we need global indexes here, not per table. Expect this to come back, but as something through a pluggable global index type.


Re: More Drizzle thoughts

1) The world of development is not what it used to be. Years ago, when I started web dev, I wanted Linux but had to stick to Windows - Browsers. MySQL ran on Windows, that was winning factor. Nowadays, there is virtualisation. VMWare is free, SUN's virtualisation is free and runs on MacOS. I have seen how a web dev turned to Linux and runs Windows in VMWare just for the browser testing. MySQL's GUI developers switched to MacOS and create our Windows Tools in virtualised environment. So, if the developers need to use Drizzle, it will be easier to create a small VMWare image, or whatever image, that has it prefconfigured and let them run it. This will be even make things closer to the real environment, where Drizzle will run on Linux/other POSIX system (table names problems strike me - the way MySQL encodes them on different FS).

Re: More Drizzle thoughts


As for 3), we will get pluggable custom data types for Drizzle anyways, right?

*nudge nudge*


Re: More Drizzle thoughts

4) MySQL 5.1 does not support Fulltext *Index* plugins. The actual index implementation used is always the same, what is pluggable with it though is the *parser* part that splits input into "words" so that you can e.g. uncompress (think "gzip") or decode (think "doc" or "pdf") text before letting it hit the index or even work with completely different concepts of "words" ... from basic stemming to completely different "alphabets" like e.g. DNA/RNA ...

Re: More Drizzle thoughts

<I>2) Apparently UNIX socket support was also dropped. This kind of surprised me. For all I know most people rely on fast connection creation using UNIX sockets to connect to a local slave, rather than hitting a central server via TCP.</I>

It shouldn't be surprising -- Drizzle is specifically designed for cloud computing and web applications. While it's possible that some web applications have databases local to the application, overwhelmingly there are many application/web servers that are separate from database servers.

As for no Windows support -- there just isn't anyone working on Windows stuff right now. That may (probably will) change in the future.

Re: More Drizzle thoughts

Hi Lukas,

It is _the_ drizzle wiki, and I agree with you that the banner ads are very much in your face and all over the place. Quite distracting.

I am sure you are right that someone out of the community would be willing to host an ad free wiki, maybe even us... :)

Re: More Drizzle thoughts


I was going to write I see dropping UNIX socket support is a good thing. It's simplifies the server (Which is goal of drizzle), and Drizzle is designed to be a database for the cloud and the web. That means a lot of databases on a lot of servers (and they will be dedicated servers) so your only socket connection would be client (which you would probably run centralized anyway, and then needing TCP), and mysqldump (Which is impractical for >5-20GB databases).

I see that Sheeri had already made my point.


Before you can post a comment please solve the following captcha.

your name: