Become a fan of Slashdot on Facebook


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.
    • Shnizzle (Score:2, Funny)

      by kjorn ( 687709 )

      You shnizzle dude, wizzle on my dizzle, like totally gansta. I is gunna pop a cap up your arse.

      Hey, I'm English and this is how all Americans talk on the telly ;-)

    • 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: (Score:3, Interesting)

        by ultranova ( 717540 )

        If you don't use prepared statements in your web application, you don't need to have them in your database server.

        Seeing how prepared statements are meant to make repeated queries faster, by allowing reuse of the plan, I'd say that this was a stupid thing to remove. Not as stupid as views, though, since those are basically just stored and named queries and as such trivial to implement/maintain.

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

    • Re: (Score:3, Interesting)

      by drew ( 2081 )

      That was exactly my thought. Hooray, we just jumped 10 years backwards. Hopefully this time they've fixed the database corruption issues that had me truncating table files once a week.

      Of course this just confirms my belief (and the reason I've never yet used MySQL in an environment where I was given the choice) that even when these guys added these features they either didn't understand them or didn't believe that they were ever important.

    • Re: (Score:3, Interesting)

      by mini me ( 132455 )

      Modern web frameworks these days just use it as a over-glorified hash store anyway. The other features are useless in that context. However, I feel we'll see a move to document databases, such as CouchDB, by those frameworks in the near future leaving MySQL out of the game completely.

  • 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?

    • Throw out Triggers???

      Junk-in and Junk-out with bloat code on top trying to validate and synchronize very thing.

      I guess it the '70s all over again.

    • Re: (Score:2, Funny)

      by mgmatrix ( 539969 )
      Moved != Removed. The functionality in question is being moved into a modulee..
  • Drizzle? (Score:5, Funny)

    by CheeseTroll ( 696413 ) on Wednesday July 23, 2008 @09:06AM (#24302803)

    Fo' shizzle!

  • 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!
    • Re:No views?! (Score:4, Interesting)

      by ghoti ( 60903 ) on Wednesday July 23, 2008 @09:42AM (#24303365) Homepage

      Which is exactly what the majority of CMSs do today. They treat the DB as dumb storage, and make very little use of its capabilities.

      • by Alpha830RulZ ( 939527 ) on Wednesday July 23, 2008 @10:07AM (#24303749)

        Which has the unfortunate side effect of making the application portable across DBMS's.

        I'm just sayin'...

        • Re: (Score:3, Interesting)

          by GooberToo ( 74388 )

          While kind of hackish (it uses dia as its GUI), cool projects like tedia2sql [] make it easy to develop a single schema which works on 8 or 9 major RDMS, for free. It's even possible to generate customized triggers and/or schema sections on a per RDBMS basis.

          I don't think it covers stored procedures. It has been a long time since I've used it, but regardless, considering stored procedures are often ignored, it may or may not be a factor for your next project.

    • "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!"

      I don't have to imagine that, you insensitive clod. Thanks for remembering me about what a messed-up crap my inherited code-base is.

  • Oh man. (Score:4, Interesting)

    by Hero Zzyzzx ( 525153 ) <dan@geek[ ] ['upr' in gap]> on Wednesday July 23, 2008 @09:09AM (#24302857) Homepage

    One man's "superfluous" is another man's key feature. No views? No prepared statements? Holy carp. Isn't MySQL crippled enough as it is?

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

    • Re:Oh man. (Score:4, Interesting)

      by ricebowl ( 999467 ) on Wednesday July 23, 2008 @09:44AM (#24303391)

      I realise that this is hugely off topic, but is there any chance anyone can highlight the benefits of prepared/stored statements? I've been trying to read around on the subject but it seems to be hard to pin down the benefits, and then I come across this: [], which offers an insight, but seems moderately biased against it "because he's never bothered with it yet, why bother with it now. And get off my lawn!"

      Thanks for any help with this...

      • Re: (Score:3, Interesting)

        by pjt33 ( 739471 )
        It's rather hard to do a successful SQL injection attack against a prepared statement. It's not trivial to validate your inputs so as to avoid an SQL injection attack without them. That is IMO the number one reason for using them.
        • Re: (Score:3, Insightful)

          by ricebowl ( 999467 )

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

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

        by corbettw ( 214229 ) on Wednesday July 23, 2008 @10:01AM (#24303651) Journal

        One of the big reasons they're popular is security. Without stored procedures, to allow a program (or the programmer who wrote it) access to a given data set, you'd have to grant it SELECT privileges on the table(s) containing that data. With a stored procedure, you just grant it permission to run that procedure, which might only return a subset of the data in the table(s).

        Quick example: you have two tables, employees and employee_reviews. The employee table contains a unique ID, the employee's name, their salary, their start date, and other data. The employee_reviews has a foreign key linked to the employee's unique ID, the score for their latest review, and the text of the review. Without using stored procedures, to provide access to a given program to display the employee's name and the text of the review, it would need SELECT access on both tables; that exposes the employee's salary, which (we'll assume for this example) violates company policy.

        With a stored procedure, though, you don't have this dilemma. The procedure would just select the appropriate columns and return them. This protects the employee's privacy and abiding by company policies.

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

        by hanshotfirst ( 851936 ) on Wednesday July 23, 2008 @10:07AM (#24303735)
        Prepared Statements:
        * You can avoid SQL injection (improved security)
        * You can use "bind variables" (improved DB performance, improved security - see above)

        Stored Procedures:
        * You can write a transaction API in the database, and leave all that "ghastly" SQL out of your Java/PHP/languageOfChoice.
        * Your data will outlive the cool-hip-language-of-the-day. Keeping that transaction API in the database means you don't have to rewrite all the data access/business rules when you want to change languages for your application.
        There are more reasons, but these are the big ones.
      • Re: (Score:3, Insightful)

        by Tim C ( 15259 )

        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 th

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

        by Mr. Shiny And New ( 525071 ) on Wednesday July 23, 2008 @10:15AM (#24303867) Homepage Journal

        You need to keep in mind the difference between a Prepared Statement and a Stored Procedure.

        A Stored Procedure is a function stored in the database that you call from the application. There are pros and cons, which I won't go into here. Personally I don't like them but I can see why some people love them.

        A Prepared Statement, however, is the most useful tool you can use to protect yourself from SQL injection and every program should use them all the time. If there were a way to get rid of NON-prepared statements I think that'd be the right thing to do but I'd never use a DB that didn't support prepared statements. Let me illustrate the difference (Java-like pseudo-code):

        Connection con = getConnection();
        Statement stmt = con.createStatement("Select * from users where username = '" + username + "' and password = '" + password + "');
        ResultSet rs = stmt.executeQuery();

        PreparedStatement pstmt = con.prepareStatement("Select * from users where username = ? and password = ?"); // bind parameters
        pstmt.setString(1, username);
        pstmt.setString(2, password);
        ResultSet rs = pstmt.executeQuery();

        The PreparedStatement example looks like more code to write, and it is (But you can write utility functions to simplify this if you want).
        But there are two advantages:
        1. You can re-use the PreparedStatement if you need to run the query more than once with different parameters and this saves processing.
        2. The bound parameters are automatically converted internally to parameters so that the SQL doesn't have to parse the parameters themselves. This protects you from SQL injection. If the query above had been used in the application's login module, anyone could log in if they typed in the administrator's username and the password ' OR 1 = 1; --

        The reason is that in the first example the password contains SQL code. The SQL parser can't tell the difference between your parameter (the password) and the code because you passed it in as all one string. In the second case the parser sees that there is a variable and binds the value to that variable during execution of the statement. The variable isn't parsed as code.

        Someone reading this is probably thinking "Just escape the parameters manually!", which helps, but by always using prepared statements and binding parameters you will never miss a parameter or have to worry about bugs in the escaping routine (PHP's mysql module has had several bugs in those routines).

        I can't stress this benefit of prepared statements enough. It is so critical that we don't hire people at my company who don't understand this problem.

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

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

      • Re: (Score:3, Informative)

        by TheRaven64 ( 641858 )
        Not quite. SQLite allows concurrent access, but it doesn't allow concurrent writes. This is not a problem for most web apps, which have a very high read-to-write ratio. It's really a question of granularity of locks. In the Bad Old Days, when data was stored in flat files, if you wanted to write something, you needed a write-lock on the file, which would block any readers and could not be acquired until all readers had closed the file. With a full RDBMS, you just need to lock a single table or (ideally
        • Re: (Score:3, Informative)

          by jadavis ( 473492 )

          With a full RDBMS, you just need to lock a single table or (ideally) a few rows in that table. This blocks people doing SELECT * type things, but a lot of other reads can go ahead.

          With some RDBMSs, like PostgreSQL, writers do not block readers at all.

  • by Anonymous Coward on Wednesday July 23, 2008 @09:11AM (#24302887)

    ...reinvented, but with security flaws. Awesome!

    • by spud603 ( 832173 )
      well, no. having not read tfa, it seems like drizzle is going for concurrency, which was never sqlite's strong point.
  • 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?

    • Re: (Score:3, Informative)

      by Foofoobar ( 318279 )
      Well yes and no. I have always told people never to use query cache except when they absolutely need it as it can quickly become overused. But it is extremely useful for small amounts of data that don't change often but get called ALOT! And without it, you are correct, it is definitely something that will be sorely missed by people who know what they are doing.
      • How exactly do you overuse a query cache? I mean, the more use of the cache, the better, no?

        Query caches on my machines ( with an approximate read:write ratio of 20:1 ) get hit about 88% of the time. That's a pretty major speed enhancement, I can tell you that, coming from 3.23 only a few years ago.

      • I agree on most of the advice you give, especially in light of the major performance gains that can be realized by writing smarter queries and properly indexing the fields used often in WHERE clauses. With well-written code, properly indexed tables, and good queries, the cache can be unnecessary.

        That said, the cache is still quite helpful if you do a lot of traffic that tends to hit the same datasets repeatedly. Blogs, news sites, and "informational" websites come to mind.

        For environments that are "write h

  • It just begs the question, Who is the Drizzle? []

  • Would this be a candidate for a light DB server for a mobile device? Perhaps for address books, media catalogs, etc... Could it find a niche beyond the web? BTW, IOANADBE (I obviously am not a database expert). IAANAAE (I am also not an acronym expert)
    • Re: (Score:3, Informative)

      stuff like sqlite, berkeley db, and sql server compact edition already serve this purpose well. an actual server on a mobile device would be far too expensive.
    • iPhone ships with SQLlite already, and I'm sure other devices ship with db servers too.
  • LADP? DALP? PADL? (Up shit creek without, presumably...)

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

  • SQLite? (Score:4, Interesting)

    by Anonymous Coward on Wednesday July 23, 2008 @09:15AM (#24302961)

    I always thought SQLite did a perfect job of filling in the space between the need for a full blown database and the weight it adds to the server setup. SQLite, as its name suggests, is very lightweight. Where exactly will Drizzle fit in?

    • Seems like Drizzle will fit between SQLite and MySQL - small and lightweight, but still using a DBMS.

      • by Firehed ( 942385 )

        Sounds more like a really gimped SQLite (which despite being flat-file based, actually supports lots of useful SQL features like views and transactions (I'm not sure about stored procs).

  • Is this just a stripped down MySQL? Or is it a fork that actually bring some interesting new scalability features to the table that are otherwise unimplementable in the current MySQL architecture?

    Maybe it's my pre-caffeine morning stupor, but the site seems void of any real details.

  • by kahei ( 466208 ) on Wednesday July 23, 2008 @09:18AM (#24303027) Homepage

    Finally, with even views removed, MySQL can move toward its original dream of having *no* features at all -- *no* separation of interface from implementation, *no* referential integrity, *no* bundling of logic with data to ensure data integrity, *no nothing*!

    After a period in the wilderness, during which versions 4 and 5 added hated so-called 'features' and 'functionality', we are now finally returning home.

    I look forward to Drizzle version 2 in which pesky 'tables', 'columns' and most of all the fancy and pointless 'select' statement are removed.

    Seriously, no *views*?

    So, what we actually have here is a thin wrapper around InnoDB. If Sun have turned MySQL primarily into a quick-start wrapper for their own product, that's actually pretty clever.

    • Re: (Score:3, Informative)

      InnoDB (and BDB for that matter) is owned by Oracle.
    • 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.

  • How is "massive concurrency" and the lack of these features compatible?

    What I want is massive concurrency in a full scale, disk based, highly available, highly scalable cluster. Can we get that right, please?

  • By slimmed down it means they've taken tranasactions and all the referential integrity checks out?
  • by hardburn ( 141468 ) <hardburn&wumpus-cave,net> 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 psbrogna ( 611644 ) on Wednesday July 23, 2008 @09:27AM (#24303151)
    Now if we could just get a hiearchical data model and associated standards based query language at the same time (XML, xquery, xupdate, etc) it truly would be Christmas come early. The potential of a FOSS, production ready NXDB is intoxicating (Exist-db, Monet, etc. are sooo close).
  • ... in a server meant for high concurrency use ... isn't that just shooting yourself in the foot or what?

  • by Rinisari ( 521266 )

    Hooray for Launchpad!

    • What?

      I may be replying to a troll, who knows, but I'm interested to know why you're cheering on Launchpad in a thread about MySQL.

  • 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.
  • Old School! (Score:2, Insightful)

    by jrwilk01 ( 88081 )

    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.

  • All for it (Score:5, Interesting)

    by spinkham ( 56603 ) on Wednesday July 23, 2008 @10:01AM (#24303649)

    From my point of view, this is MySQL finally embracing their target market.
    These features are great and important, but if you're doing small scale web programming through a framework that uses an ORM, or just very simple SQL, why not slim the program down?
    If you want real database features, you probably shouldn't be using MySQL in the first place in my opinion.

  • 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 mlwmohawk ( 801821 ) on Wednesday July 23, 2008 @10:35AM (#24304177)

    Sorry, it is incomprehensible that this sort of project would be started.

    The problem with MySQL, to BEGIN WITH, is that it doesn't support enough SQL or the SQL it does support well enough, to construct efficient queries. What ends up happening is that you move your "data logic" to your application and out of your database. This means the database handles simpler queries, but returns more data. While these simple queries appear faster, they hit more data on the disk and actually cause the system to become I/O bound.

    "Real" databases handle the "data logic" close to the data and can estimate the most efficient access to the data needed, thus REDUCING the I/O bottleneck, making more complex queries more efficient than simple queries. CPU time is virtually free with respect to data access.

    Every time I see some Java, PHP, or .NET guy go off about MySQL being faster, I just shake my head. Data access is a real science grounded in math and the physical realities of actual computers and storage devices. A "good" database has YEARS of research and unless you are a god (and you are not) it will be very hard for you to beat it.

    I've been in the business for about 28 years and I don't understand why software developers have this blind spot about databases. Maybe it is a "not written by me" attitude, but I just don't get it. A "good" database has so many facilities to make your data access efficient and fast as hell. Yet, most developers that I have to direct, simply refuse to learn about databases, specifically SQL. They go out of their way to write elaborate functionality in their language of choice that could have been constructed in a moderately interesting SQL query, that could be wrapped in a function and been more efficient.

    The "drizzle" product is just another avoidance of an important semester of computer science that people don't want to understand and will ultimately create even more poorly designed web sites.

  • by Jester998 ( 156179 ) on Wednesday July 23, 2008 @10:45AM (#24304361) Homepage

    I foresee many posts on thedailywtf about projects which implement this 'technology'...

  • by afabbro ( 33948 ) on Wednesday July 23, 2008 @12:38PM (#24306477) Homepage

    ...but then again, I work with Oracle.

  • by mw13068 ( 834804 ) on Wednesday July 23, 2008 @01:18PM (#24307191)
    Oh Hi! I'm a database admin/weirdo/geek and I have "big issues" (TM) with any and all database technology, and related discussion that does not fit with my myopic view of the world! This Drizzle does not make me happy. You kids! GET OFF MY LAWN!