
Drizzle, Simplified MySQL Fork - sant0sk1
http://adam.blog.heroku.com/past/2009/2/3/drizzle_simplified_mysql_fork/
======
jacquesm
Ok, here is a point-by-point on Monty's list of items that drizzle is supposed
to be solving:

(list and interesting article about the 'fork' here: <http://monty-
says.blogspot.com/2008/07/what-if.html>)

    
    
        * It opens up MySQL development for the community; You
          no longer have to wait years to get your patches and 
          resonable extensions into the server.
    

This is not a reason to fork a project, it is an excellent reason to review
the processes at MySQL.

    
    
        * Critical bugs that have existed for years can finally
          get fixed as the development is no longer constrained 
          by unrealistic release schedules that put artificial 
          constraints on things that can be fixed.
    

See above, with a cherry on top.

    
    
        * Drizzle will put some MySQL server differentiation on 
          a true test; A bit like Fedora does to RedHat.
    

I don't quite understand this point, Fedora is a community supported os
targeted at personal users, whereas RedHat, is geared towards businesses using
it commercially. Do I interpret this now to mean that either drizzle or mysql
will be targeted to individuals (unlikely) or does that mean that mysql is
trying to enlist the community with drizzle and will eventually take the best
developments from drizzle and backport them to MySQL ?

    
    
        * Drizzle has created new excitement in the MySQL 
          developer community; A lot of people seem to be very 
          enthusiastic to work on it in a true community-
          oriented manner.
    

That could have been done by a more responsive attitude at MySQL.

    
    
        * Developers working on Drizzle is doing drastic 
          refactoring of the server, something that MySQL 
          planned to do years ago but never happened.
    

Again, procedural issues at MySQL.

    
    
        * Development decisions is again driven by people that 
          are using the server daily; This will ensure that 
          Drizzle will be faster and more stable than what can 
          be done with current MySQL development model
    

Why ? Change the development model ! If the result is to get a product that is
more stable and faster than that would be the appropriate response.

    
    
        * Drizzle will target the MySQL core users, the web 
          users, whose requirements have been ignored for years 
          while the core MySQL developers have added features 
          that they don't need.
    

_that_ is an excellent point, but now we will be on two roads at the same
time, _some_ users will need those features that others don't need and vice
versa, and some users (and those are the unfortunate ones) will need some from
both.

    
    
        * In addition Drizzle will include the latest InnoDB 
          code; You don't have to wait for MySQL 6.0 or go to 
          the trouble of annually downloadoing and installing 
          the InnoDB plugin from Oracle just to get access to 
          the latest and fastest InnoDB version.
    

And that could be fixed in MySQL in the same timeframe.

Now, I'm not going to second guess the likes of Monty, but my suspicion is
that there are other and not so well documented reasons for this split, it
sounds more like a divorce to me.

~~~
sachinag
Can PG or a mod delete/reformat this post? Fixed width is looked down upon for
anything that's not a short code snippet here.

~~~
jacquesm
Thanks, I didn't realize the cut & paste messed up the formatting so badly. I
fixed it.

------
jacquesm
That's a neat project, but I always figure that if you're going to fork an
open source project instead of contribute to the original you really have to
make a very strong case for doing that, and in my opinion in this case that
has not happened.

Everybody - including the author - would be better served by extending the
original package to include the functionality that they are missing, to fork
and drop a bunch of features so that it becomes easier to add the things that
are missing is not going to help in the long term. Unless it is done as a case
study on how to attack the problem, but that does not seem to be the case
here.

Fragmentation because of excessive forking of projects is one of the biggest
problems in the open source world.

~~~
tome
> Fragmentation because of excessive forking of projects is one of the biggest
> problems in the open source world.

Can you give some examples? Here are some examples where I think the fork has
actually achieved a great benefit, and fragmentation has not persisted:

* GCC/EGCS * Xorg/Xfree86 * SSH/OpenSSH

GNU Emacs/Xemacs would be the most obvious example of continuing fragmentation
that springs to mind. What are the others?

~~~
jacquesm
Not of the top of my head, but the interesting bit in the drizzle / mysql fork
to me is that drizzle is forked _by itself_ , in other words the people behind
mysql are now spreading themselves thinner than before across two projects
that share a very large piece of code.

I'm quite curious to see how this will all turn out in the long term, if at
some point the 'fork' will be reabsorbed back in to mysql or if the two forks
will continue to exist next to each other.

Another - scary - possibility is that by forking they will take enough
momentum away from the mysql development that both will suffer.

I think that now having to choose between 'mysql cluster', 'mysql regular' and
'drizzle' is all too much of a good thing.

50 brands of bottled water can't all be that much different :)

------
mdasen
I'm left wondering, does Drizzle have that much value? When creating
applications, I know that the things I worry more about are replication,
sharding, federation, etc. I don't worry about the speed of an individual
query or even the utmost performance on a single box. I'm more interested in
how I can scale it beyond that. Now, many of those things are rarely needed,
but similarly it is rare that MySQL or PostgreSQL won't handle your load on a
single box.

So, why put the work into optimizing speed rather than scalability?

------
derwiki
Are there any performance statistics? I'm interested to see how it compares to
MySQL/SQLite for light to heavy workloads.

