Please create an account to participate in the Slashdot moderation system


Forgot your password?
Databases Programming Software Data Storage The Internet IT

Slimmed Down MySQL Offshoot Drizzle is Built For the Web 370

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."
This discussion has been archived. No new comments can be posted.

Slimmed Down MySQL Offshoot Drizzle is Built For the Web

Comments Filter:
  • by mwilliamson ( 672411 ) on Wednesday July 23, 2008 @09:01AM (#24302703) Homepage Journal
    Back to a glorified (but uber-fast) filesystem it looks like.
  • by Jimmy King ( 828214 ) on Wednesday July 23, 2008 @09:05AM (#24302781) Homepage Journal

    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?

  • No views?! (Score:5, Insightful)

    by qoncept ( 599709 ) on Wednesday July 23, 2008 @09:08AM (#24302851) Homepage
    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!
  • by maz2331 ( 1104901 ) on Wednesday July 23, 2008 @09:11AM (#24302889)

    Uh, doesn't removing the query cache run counter to the goals of making it fast?

  • powered by... (Score:2, Insightful)

    by Anoraknid the Sartor ( 9334 ) on Wednesday July 23, 2008 @09:14AM (#24302949) Homepage

    LADP? DALP? PADL? (Up shit creek without, presumably...)

    Why "Drizzle"? What a damp, depressing, generally wet name....

  • by hardburn ( 141468 ) <[hardburn] [at] []> on Wednesday July 23, 2008 @09:21AM (#24303069)

    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.

  • by nvivo ( 739176 ) on Wednesday July 23, 2008 @09:24AM (#24303103)

    a database project aimed at powering websites with massive concurrency as well as trimming superfluous functionality from MySQL ... Akers 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."

    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.

  • by nvivo ( 739176 ) on Wednesday July 23, 2008 @09:27AM (#24303145)

    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?

  • by antifoidulus ( 807088 ) on Wednesday July 23, 2008 @09:48AM (#24303463) Homepage Journal
    Dude, I want what you are smoking!

    Seriously? Windows? Reliable? Easy to develop for(Nothing without a decent command line is "easy to develop for in my book) for? Easy to implement? Windows management tools are a joke compared to mac, and Linux has tons of really good tools that kick the crap out of the amalgam of XP tools that are functionally useless, confusing as hell, and ugly as sin to boot. Easy to support? Have you ever tried to repair a registry? Not fun.
  • by drinkypoo ( 153816 ) <> on Wednesday July 23, 2008 @09:50AM (#24303485) Homepage Journal
    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.
  • Re:Oh man. (Score:5, Insightful)

    by Jellybob ( 597204 ) on Wednesday July 23, 2008 @09:53AM (#24303537) Journal

    At first glance it's hard for me to see where Drizzle would fit where SQLite doesn't.

    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.

  • by Ngarrang ( 1023425 ) on Wednesday July 23, 2008 @09:53AM (#24303539) Journal

    Get on board MS! Why would anyone in their right mind set up a Web/SQL platform using MS products?

    Because, despite your prejudice, there is a business case for it. And business wins over OS zealotry. Besides, it is open source. Someone who is able to exercise common sense will simply port it to Windows.

    And stop telling me what platform I should use for my apps, darn it! I don't see your time and money here in front of me doing the work, so stfu and just give me the tools that will get the job done.

    OS Zealots are worse than spammers.

  • by maz2331 ( 1104901 ) on Wednesday July 23, 2008 @09:58AM (#24303591)

    Yep - it sounds like the Assembly Language version of a DB, built for massive speed but requiring very careful programming to avoid crashes.

    Sometimes that's just what you need. Sometimes it's exactly the worst possible approach.

    I say let the problem requirements decide which to use.

  • Old School! (Score:2, Insightful)

    by jrwilk01 ( 88081 ) on Wednesday July 23, 2008 @09:58AM (#24303605)

    I used something like this back in the late '90s. It was called "MySQL 3" and made by a Swedish company named "TcX AB."

    What is old is new again.

  • by Negatyfus ( 602326 ) on Wednesday July 23, 2008 @10:00AM (#24303635) Journal
    Of course I haven't RTFA, but what I gather from the summary is simply that they'll be removing these features from the core and making them accessible from modules. Why is that wrong? If you don't use prepared statements in your web application, you don't need to have them in your database server. Unless I missed something...
  • Re:Oh man. (Score:3, Insightful)

    by ricebowl ( 999467 ) on Wednesday July 23, 2008 @10:03AM (#24303673)

    I don't want to sound ungrateful, but is that the only reason? I accept that having one more secured web-server in the world is a righteous goal, and ethical too, but I was expecting rather more pros than just the one (albeit an important one).

    Thanks though, much appreciated. =)

  • by jellomizer ( 103300 ) on Wednesday July 23, 2008 @10:04AM (#24303699)

    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.

  • by AngryLlama ( 611814 ) on Wednesday July 23, 2008 @10:06AM (#24303727)

    I hope the database will run on Zune so I can squirt my Drizzle.

  • by tobiasly ( 524456 ) on Wednesday July 23, 2008 @10:07AM (#24303751) Homepage

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

  • Re:Oh man. (Score:3, Insightful)

    by Tim C ( 15259 ) on Wednesday July 23, 2008 @10:12AM (#24303827)

    As well as the security aspects of using prepared statements, they can also boost performance as the RDBMS doesn't have to keep parsing what is in fact the same statement time and again.

    Stored procedures can similarly increase security (when used right) and boost performance, depending on your application and architecture. For example if the DB is running on a different physical box then shifting some of the data processing there can take a load off the app/web server(s). On the other hand that increases the application's complexity, as you now have business logic in (at least) two places and (almost certainly, but not necessarily) two languages.

  • Re:Oh man. (Score:5, Insightful)

    by rasilon ( 18267 ) on Wednesday July 23, 2008 @10:17AM (#24303895) Homepage

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

  • by KingSkippus ( 799657 ) * on Wednesday July 23, 2008 @10:20AM (#24303935) Homepage Journal

    A lot of people think MySQL is great, but a lot of these same people have never worked on a "real" database that provides true ACID compliance, has powerful stored procedures, and instead of providing too many choices only have sensible options that all preserve data integrity.

    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.

  • by GooberToo ( 74388 ) on Wednesday July 23, 2008 @10:24AM (#24304003)

    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.

  • by nixNscratches ( 957550 ) on Wednesday July 23, 2008 @11:27AM (#24305103)
    I use MySQL and PostgreSQL every day and whenever I have a choice, and if it makes sense for the project, I reach for Postgres. MySQL may have better GUI tools and I'm sure that's important for some people, but PostgreSQL just works more like I want / need a database to work. For the kind of work I do (non trivial queries with a significant degree of write operations), it's as fast or faster than MySQL in any area that matters. If you don't see any perceived benefit to using a more robust, more compatible SQL implementation, then you probably aren't using a lot of what most RDBMS systems have to offer. And that's fine! There are plenty of places where people are using a database as a glorified storage box for object persistence where any fancy SQL stuff is almost a waste and that's a place where something like Drizzle makes a lot of sense.
  • by billcopc ( 196330 ) <> on Wednesday July 23, 2008 @11:51AM (#24305553) Homepage

    Frankly, MySQL is a lot greater than what 99% of users use it for.

    You're right! Most web tards should be using SQLite, but hey, that would remove the possibility of running 8-node DB farms to support their bloated ORM framework and its spurious queries. It's funny how, 6-7 years ago people were talking about hitting 1 million hits per day. In 2008, with our quad-core Ghz-pounding monsters, most popular sites are actually serving less traffic per box than we did back in the day, because nobody cares to optimize anymore. Large images, script-rendered stylesheets (!?), caching is largely ignored by a majority of weenie developers...

    The last thing this world needs is another half-assed DB that panders to these inept coders. How about a tightly-bound, SQL-free database connector ? How about an ORM that's built right into the server ? How about closing the big gaping holes all these noobs are too dumb or lazy to avoid ? If web developers don't need a full-blown SQL server, they probably don't need a hobbled one either. They need something completely different.

  • by Anonymous Coward on Wednesday July 23, 2008 @12:06PM (#24305815)
    Linux not being in the uptime listings is not because all those Linux machines are crashing, but because of the method used in Linux to measure uptime. In fact, NetCraft even has a FAQ on this here []. It's pretty much common knowledge at this point that Linux servers have better uptimes than Windows servers, and that BSD rules the roost (and that absolutely every VAX machine that ever booted VMS is still running!).

    That said, .Net is brilliant, and really makes complicated programming accessible to idiots (you can argue about whether this is a good thing or not!). For me, it comes down to "do I spend the cash on keeping Windows Server licenses up to date, keeping SQL server licenses, keeping techs paid to do the routine Windows maintenance, etc, but get away with hiring a cheaper, less skilled programmer" or "do I lay out more cash on a better programmer who can handle developing under Linux, but save the costs of licenses, (some) maintenance, etc"? The decision depends on the situation.
  • by Sancho ( 17056 ) * on Wednesday July 23, 2008 @12:22PM (#24306111) Homepage

    Most people could make an argument that any feature is important/easy enough to keep in the core. The truth, though, is that most people use MySQL as a data store. They don't care about data correctness, about views, about advanced features. They just want to be able to store data and look it up again.

    Of course, this is partially because the books on database programming don't stress these features, and such programming has become available to the masses who don't know any better. Real programmers understand the issues and use these features, but then, real programmers probably also understand that modularization can be very useful.

  • by Sancho ( 17056 ) * on Wednesday July 23, 2008 @12:24PM (#24306167) Homepage

    They're not removing features, they're moving features into modules. Don't use views in your app? That code doesn't get loaded. Honestly, once a program reaches a certain size, this is a necessary step.

  • by FishWithAHammer ( 957772 ) on Wednesday July 23, 2008 @01:07PM (#24307021)

    Assorted points that indicate that you do not know what you're talking about--

    -Why are you installing software that could corrupt the registry on your server machines? Sounds like incompetence to me.

    -Do you really mean to say that OS X has better server management controls than Windows? Really? Because if you are, I would like to know what mystery world you live in where "bad" became "good."

    -Linux does not have anything that approaches ASP.NET in terms of functionality, ease of programming, and feature completeness. Java Server Pages are horrible. Mono (who I do some work for) is only at ASP.NET 2. PHP/Python/Ruby? Please.

    -The Windows command line is poor, yes--but if you're working according to the platform's paradigm, that weakness is avoided because you don't use it. Besides, cygwin works fine if you insist on it. (I've started to use PowerShell, which is also quite nice.)

    -SQL Server is significantly superior to MySQL, faster than PostgreSQL, and for most businesses is cheaper than Oracle.

    The only one smoking anything here is you.

  • Re:Oh man. (Score:3, Insightful)

    by FishWithAHammer ( 957772 ) on Wednesday July 23, 2008 @01:12PM (#24307095)

    Um. That one alone is good enough reason to use them.

    It's not "important." It's fucking vital.

  • by ClientNine ( 1261974 ) on Wednesday July 23, 2008 @01:12PM (#24307107)
    The only time I have the database do the processing is when it's either vastly faster or vastly easier. To put it simply, it's cheap and easy to scale up my webserver farm, and difficult and expensive to scale up my database.

    In the real world, developer hours are the most expensive part of most IT projects. You are highly motivated to write code within your comfort zone that will not require heavy maintenance in the future. So yeah, that might mean doing a broad query and doing the sorting/filtering/analysis on the webserver. That puts the heavy lifting in Tomcat/Perl/PHP (and unlike SQL, those languages don't need to have their syntax extensively futzed with when the platform changes because this year's CTO is a Microsoft Fanboy and his predecessor was an Oracle Victim). If the webserver runs slow, fine-- I throw another webserver at it and check the "stateful http session" button on the load-balancer/firewall. Costs me about 5 grand and even gives me other bennies like redundancy. If that saves us a man-week of dev time over the next few years than it's a steal. (Infrastructure load? My boss doesn't care. That's the facilities budget, not IT, and the marginal cost of running one more PE1850 is negligible anyway.)
  • Ask yourself WHY, (Score:4, Insightful)

    by encoderer ( 1060616 ) on Wednesday July 23, 2008 @01:52PM (#24307885)

    It's funny how, 6-7 years ago people were talking about hitting 1 million hits per day. In 2008, with our quad-core Ghz-pounding monsters, most popular sites are actually serving less traffic per box than we did back in the day, because nobody cares to optimize anymore.

    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.

  • by Anonymous Coward on Wednesday July 23, 2008 @03:28PM (#24309513)

    I can live without all the items they've removed, except prepared statements. Without prepared statements most apps will accumulate massive parse-time waits for all their SQL.

    What do they gain by removing prepared statements?

  • by mlwmohawk ( 801821 ) on Wednesday July 23, 2008 @06:55PM (#24312275)

    But about MySQL: You're Missing The Point.
    I would bet my career that I am not, and most of my career is based on NOT missing the point.
    The VAST majority of apps deployed every day are NOT critical-mass applications. They are niche applications developed by (or for) Corporate IT Departments They are applications where the potential userbase is 30 people in an accounting department, or 100 people in a call center.

    True, but not relevant.

    For these applications, a table lock is truly NOT a big deal.


    Do the math. If you have 100 users, only a fraction will be simultaneous. And of those, how much actual server-side processing time is being spent? Even if a user is logged-in for 8 hours a day, what's the cumulative processing time? 2 minutes? 3?


    The end product is a very low probability that a race condition will occur due to a table lock. It might happen, what, once a day? And when it does, the user goes back, re-submits, problem solved.

    I define that as broken ESPECIALLY when there is fundamentally no reason for it to happen.

    You seem so hung-up on this "the company depends on my DBMS selection" mentality that it seems like you miss the boat entirely.

    I think you are missing the point entirely. Why do crappy work if you don't need to. Your defense is that you can squeak by with MySQL, but you've made no argument why you should use it in the first place.

Heuristics are bug ridden by definition. If they didn't have bugs, then they'd be algorithms.