3 ms·

Drizzle, Simplified MySQL Fork

17 points by sant0sk1 18y ago

jacquesm 18y ago
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 18y ago
  > 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 18y ago
    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 :)
- revorad 18y ago
  >>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. Can you please give any specific reasons for having that opinion?
  - jacquesm 18y ago
    Sure, the author says he has removed: "No modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts" Some of which have been recent - and much requested - features of mysql. Then he has added "DDL transactions (maybe), or faster subqueries" That sounds like a good bit of major functionality was ripped out wholesale to make one feature possible (and that with a 'maybe'), and to speed up one other feature which was already present in the original program. To me that's clearly a very very bad reason to fork. Go and spend the time to help optimize subqueries for everybody and try to add your 'maybe' feature in to the original codebase, which probably will be harder but much more useful in the long run. Especially if you find out half a year down the line that those stored procedures were pretty good after all and you need them now.
    - amix 18y ago
      The main problem with features is that they make a lot of things MUCH more complex. Making Drizzle super small and super fast by removing not-that-used features and cleaning up some of MySQL's mess is a very good fork - - and doing such a thing would enable the authors to focus on other things, such as creating a distributed database (which for me would be much more valuable than triggers or stored procedures). Hell, they could even remove joins - if they added the ability to do hot backups and scale by just adding hardware :p
      - jacquesm 18y ago
        True enough, now imagine the same features added to the mysql code base, either by allowing a more modular approach (such as the transition that apache went through) or by adding a series of switches to disable the functionality that you think is an impairment to getting the performance you require. One of the reasons development of any project slows down after a while is that you have to keep a few important items in view: - installed base - compatibility - standards requirements Mysql has done a pretty good job in this respect, slowly and over time they've added the features that were still missing in order to make it in the 'big league', now all of a sudden along comes drizzle that guts mysql back to pre-3.23 and adds features that we'd all like to see in the main distribution. That makes for a very hard choice at a later date, mysql -> more or less standards compliant, accepted and tested vs drizzle, probably lightning fast, competing with mysql for the same customers and backed by some other powerful parties (such as Google and Sun). If one of those 'not so often used features' is on your requirements list then you won't be able to profit from all the work done. I see only losers here, no winners.
- wallflower 18y ago
  An exception but Firefox was probably one of the most successful forks (of the open source beast Mozilla) ever.
mdasen 18y ago
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?
jacquesm 18y ago
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 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.
derwiki 18y ago
Are there any performance statistics? I'm interested to see how it compares to MySQL/SQLite for light to heavy workloads.

17 points by sant0sk1 18y ago

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 18y ago
> 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 18y ago
  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 :)
revorad 18y ago
>>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. Can you please give any specific reasons for having that opinion?
- jacquesm 18y ago
  Sure, the author says he has removed: "No modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts" Some of which have been recent - and much requested - features of mysql. Then he has added "DDL transactions (maybe), or faster subqueries" That sounds like a good bit of major functionality was ripped out wholesale to make one feature possible (and that with a 'maybe'), and to speed up one other feature which was already present in the original program. To me that's clearly a very very bad reason to fork. Go and spend the time to help optimize subqueries for everybody and try to add your 'maybe' feature in to the original codebase, which probably will be harder but much more useful in the long run. Especially if you find out half a year down the line that those stored procedures were pretty good after all and you need them now.
  - amix 18y ago
    The main problem with features is that they make a lot of things MUCH more complex. Making Drizzle super small and super fast by removing not-that-used features and cleaning up some of MySQL's mess is a very good fork - - and doing such a thing would enable the authors to focus on other things, such as creating a distributed database (which for me would be much more valuable than triggers or stored procedures). Hell, they could even remove joins - if they added the ability to do hot backups and scale by just adding hardware :p
    - jacquesm 18y ago
      True enough, now imagine the same features added to the mysql code base, either by allowing a more modular approach (such as the transition that apache went through) or by adding a series of switches to disable the functionality that you think is an impairment to getting the performance you require. One of the reasons development of any project slows down after a while is that you have to keep a few important items in view: - installed base - compatibility - standards requirements Mysql has done a pretty good job in this respect, slowly and over time they've added the features that were still missing in order to make it in the 'big league', now all of a sudden along comes drizzle that guts mysql back to pre-3.23 and adds features that we'd all like to see in the main distribution. That makes for a very hard choice at a later date, mysql -> more or less standards compliant, accepted and tested vs drizzle, probably lightning fast, competing with mysql for the same customers and backed by some other powerful parties (such as Google and Sun). If one of those 'not so often used features' is on your requirements list then you won't be able to profit from all the work done. I see only losers here, no winners.
wallflower 18y ago
An exception but Firefox was probably one of the most successful forks (of the open source beast Mozilla) ever.

mdasen 18y ago

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?

jacquesm 18y ago

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 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.

derwiki 18y ago

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