Slashdot Mirror
Slimmed Down MySQL Offshoot Drizzle is Built For the Web
Incon writes "Builder AU reports that Brian Aker, MySQL's director of architecture, has unveiled Drizzle, a database project aimed at powering websites with massive concurrency as well as trimming superfluous functionality from MySQL. Drizzle will have a micro-kernel architecture with code being removed from the Drizzle core and moved through interfaces into modules. Aker has already selected particular functionality for removal: modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists and some data types."
Back to a glorified (but uber-fast) filesystem it looks like.
This is stupid. Removing prepared statements and access control lists? Don't we have enough trouble with people writing insecure web apps when we provide them with the tools easily make them secure?
I can't imagine what logical reason there is for removing views, unless queries are removed too. Then I'd see where he's really going with this.
And removing stored procedures seems to be more accomidating to the way developers actually write rather than the way they should. Just think how great it will be when all of the processing on every web page is done by php rather than in the database!
Whale
Proof that when MySQL originally added those materials, they still didn't know why they were important. Some of these aren't even going to slow you down much. Prepared statements can speed you up in some cases.
In this state, it occupies a spot that SQLite does just fine.
Not a typewriter
I have been developing for the web during the past years and that's why MySQL has been off my list for serious development for some time in favor of Postgresql. It took about a decade to implement basic features like views and foreign keys that even Access 2.0 had in 93. Even sqlite has views for god sake!
Today, even for the most simple projects I cannot think about not using views, stored procedures, and triggers. Not because there is no way to do the job, but because they are important for organization, security, data integrity, etc.
It is like they have no idea that web sites are getting more complicated, and more and more data is involved everyday. I can't think of someone creating a big website with massive concurrency using this. Sounds more like an alternative to Sqlite for very simple tasks.
Why would anyone in their right mind set up a Web/SQL platform using MS products?
Because it is reliable, easy to develop, implement and support?
If you're going to pull out all the functionality, why not just use sqlite? I personally use an InnoDB setup so I can use Drupal's "related content" module so I won't be switching, but the next drupal is reputed to use sqlite as a backend and if I weren't using this feature I'd go to that. Simpler, lighter. Always present with PHP5.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Anywhere you need concurrent access - SQLite is not designed as a high performance database, it's designed as a simple to implement, single file database.
This shows a big problem.
Most people don't understand rational databases. As most colleges CS programs don't even touch SQL except for perhaps as an elective. There is a huge knowledge and a lot of miss use of SQL. They treat JOINs and Views as advanced features while they are actually still very quite basic features. Because of this a lot of people use SQL as a replacement for reading a flat file poorly designed with duplicated data, no indexing etc... etc... etc...
These features that seem to make it seem slow actually improve speed, for a lot of cases. eg. a View that takes 1 second to load could take 2 seconds total for the application to select 5 or 6 different tables then try to use logic to put the information together as the application say php or python are a higher level language then a C/c++ written database server. Also there is the additional coding time as it is much easier to reuse or extend on views then to modify code. So yes using a complex view or stored procedure will slow down the database server however if it doesn't slow down the database server it will often end up slowing down the web server instead. being the Web Server is end user facing its speed espectially for usually fast to load simple pages that are use most often are more important then waiting the little extra time for the database to get back from your complex or large request.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Traditionally MySQL was just the toy database for non-critical stuff that you wanted speed out of (and little else). If Drizzle accomplishes that, then I don't see a real place for the mainline MySQL anymore. Drizzle if you want speed, PostgreSQL if you want features/stability, and Oracle if you gots money to spend.
The thing that people always seem to discount when comparing MySQL to PostgreSQL is community mindshare and comfort level. That's why it's called a LAMP stack. If products always won on technical merits, 90% of PCs would run OS/2 instead of Windows.
I'll admit, even though I "know" that PG is supposed to be a better database, anytime I'm starting a new web app I go for MySQL. It's what most of the frameworks and toolkits support first and/or best. It's what more tech support guys at the web hosting companies are familiar with. Plus MySQL has *much* better GUI tools than PG.
If both products were starting from scratch, then yeah maybe PG would have a good shot. But MySQL isn't bad enough, and PG isn't better enough, to make me or others like me feel like switching. I'm not comfortable with the PG toolset because I'm not familiar with it, and I have better things to do with my time than learn it, because for me the perceived potential benefit isn't worth it.
Of course, none of this is to say that Sun won't f*ck up MySQL enough to make me change my mind...
He seems to have a tendency to represent the worst possible uses of various things as typical usage, and ignore a number of useful things.
For example, he claims that the security uses of stored procedures have been replaced by role based access control. That's incorrect. If you want to audit changes to a table using RBAC then the user not only needs access to the audit table but must always update it themselves. A user could easily cover up changes by simply omitting the audit row, or adding false data. The use of triggers and stored procedures can enforce the audit, and protect it from malicious update.
His claim that triggers are a bad idea because a novice DBA once disabled them on a production database, not realising that they existed, is just silly. The fix is to ensure that people get a clue before they get superuser access! Triggers are a standard part of every big modern database, and a standard part of any training program.
I could go on, but I don't really fancy debunking every silly thing people write about databases...
That's because most of these people are writing their applications to be cross-platform applications, or at least with the intention of them being cross-platform at some point without re-writing the whole thing. If you don't know that you're going to be hitting against a DMBS that provides true ACID compliance and that has powerful stored procedures, it's probably a good idea not to depend on those features for critical functionality.
Also, you're forgetting who most of the databases we're talking about are aimed at: hobby or small-scale web developers. If you're writing something like Joomla! or phpBB or MediaWiki or whatever, it's pretty safe to assume that the people who are using your software won't have access rights to create things like powerful stored procedures (that, if written poorly, can <censored> up everyone using that database) even if they are supported by your DBMS. Such is the nature of $4.99 a month hosting plans; you typically don't get much more than INSERT and DELETE and SELECT.
Frankly, MySQL is a lot greater than what 99% of users use it for. Drizzle is targeted at 80% or so of those 99% to provide an even faster and better back-end. If your application is such that it needs features that aren't supported by Drizzle or even MySQL, by all means, use whatever it is you need. But really, I don't see much use in basically telling people, "You're not using it right!" when it does exactly what they want it to.
If both products were starting from scratch, then yeah maybe PG would have a good shot. But MySQL isn't bad enough, and PG isn't better enough, to make me or others like me feel like switching.
And that's the problem. Because people don't try it, you don't realize how much better PostgreSQL really is. It really is more "better enough". ;) Until you give it an honest try, you really don't realize what you're missing out on.
Ask yourself WHY that is.
It's simple: Hardware is MUCH cheaper today than it ever was before, and it'll be even cheaper tomorrow.
You know what ISN'T cheaper? Software developers.
It makes a lot more sense to optimize for the DEVELOPER than it does to optimize for the machine.
I can add another web server for $5000. Adding a developer is at least an order of magnitude more expensive.