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

Slimmed Down MySQL Offshoot Drizzle is Built For the Web 370

Posted by timothy
from the now-it-can-be-told dept.
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 Foofoobar (318279) on Wednesday July 23, 2008 @09:17AM (#24303013)
    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.
  • by PhrostyMcByte (589271) <phrosty@gmail.com> on Wednesday July 23, 2008 @09:31AM (#24303205) Homepage
    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.
  • by larry bagina (561269) on Wednesday July 23, 2008 @09:40AM (#24303335) Journal
    InnoDB (and BDB for that matter) is owned by Oracle.
  • Re:Oh man. (Score:5, Informative)

    by corbettw (214229) <.corbettw. .at. .yahoo.com.> 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:Shnizzle (Score:4, Informative)

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

    No, that's "self-deprecation". "Depreciation" is when something loses value.

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

  • by myz24 (256948) on Wednesday July 23, 2008 @10:18AM (#24303915) Journal

    Sounds like you are trying to spread FUD. I'm a Linux guy but I'm also a Mac guy and Windows guy. I use them all. In my 8 years of running Windows in a medium organization...I've never "repaired the registry." I also find Active Directory and Group Policy to be fantastic. You can install cygwin to get your proper shell fix but even PowerShell isn't all bad compared to command/cmd. I also find our handful of Windows Server 2003 boxes to be reliable.

    As for development, I prefer to develop on Linux for Linux but it's really whatever you're comfortable with.

  • 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 GooberToo (74388) on Wednesday July 23, 2008 @11:01AM (#24304621)

    Can you expand on what you mean? [postgresql.org] Some databases have a more expanded view of what partitioning means but PostgreSQL does support partitioning.

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

    by TheRaven64 (641858) on Wednesday July 23, 2008 @11:35AM (#24305249) Journal
    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) a few rows in that table. This blocks people doing SELECT * type things, but a lot of other reads can go ahead. With SQLite, only one process may be writing to the database, and this blocks any readers until the write has completed, but you can have any number of processes reading from the database.
  • Re:Shnizzle (Score:4, Informative)

    by JerkBoB (7130) on Wednesday July 23, 2008 @11:47AM (#24305453)

    google it fool

    Just admit it... You screwed up. Irrespective of the fact that there is a redirection from "self-depreciation" to "self-deprecation" in wikipedia, they are not synonyms.

    Deprecate [merriam-webster.com]: v, play down, belittle, disparage, etc.

    Depreciate [merriam-webster.com]: v, to lower in estimation or esteem, to lower the price or value of, etc.

    They are similar words. They both share the "de-" prefix, meaning "away, off, reverse, remove". After that, they have nothing in common, other than a similar spelling.

    The etymology of deprecate comes from the latin de- precari, "to pray against", which somehow morphed into the current usage of "to belittle", or "to make obsolete".

    The etymology of depreciate comes from the latin de- pretium, "lowered price".

    Your insistence that wikipedia is authoritative on this somehow just makes you look even more silly. Especially on /., where amateur linguists and grammar nazis roam unfettered. :P

  • Re:Shnizzle (Score:3, Informative)

    by JerkBoB (7130) on Wednesday July 23, 2008 @11:50AM (#24305539)

    UGH! How is this moderated "informative"?

    Is there a "mis-informative" mod? Some looser [sic] added a redirection from "self-depreciation" to "self-deprecation". They're not the same word, damn it!

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

    by jadavis (473492) on Wednesday July 23, 2008 @12:24PM (#24306161)

    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.

The one day you'd sell your soul for something, souls are a glut.

Working...