Slashdot Log In
Slimmed Down MySQL Offshoot Drizzle is Built For the Web
Posted by
timothy
on Wed Jul 23, 2008 09:00 AM
from the now-it-can-be-told dept.
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."
Related Stories
[+]
Interviews: Ask Database Guru Brian Aker 232 comments
Brian Aker is Director of Architecture for MySQL AB. He has also worked on the code (and database) that runs Slashdot, and is well-known in both Apache and Perl circles. Outside of the arcane world of open source "back-end" programming, though, hardly anyone has heard of him. This is your chance to ask Brian (hopefully after looking at his blog and Wikipedia listing) about anything you like, from Perl to database architecture to open source philosophy to upcoming events in Seattle. We'll send Brian 10 of the highest-moderated questions approximately 24 hours after this post appears. His (verbatim) answers will appear late this week or early next week.
[+]
MySQL Founder Monty Quits Sun (Or Not) 148 comments
Paul Boutin writes "A reliable source tells Valleywag that MySQL inventor Michael Widenius, better known as Monty, has resigned from Sun. Sun bought Monty's MySQL company in a billion-dollar deal last January. Brian Aker, who forked the Web 2.0-friendly Drizzle SQL database (and former Slashdot engineer!), remains at Sun." Kaj Arnö and Sheeri Cabral share their thoughts.
[+]
What an IBM-Sun Merger Might Mean For Java, MySQL, Developers 292 comments
An IBM-Sun merger is a tantalyzing possibility; snydeq writes "Fatal Exception's Neil McAllister suggests that an IBM/Sun merger could crown Big Blue king of enterprise software development. 'Acquiring Sun would make IBM the clear leader in Java, as it would become the caretaker of the open source reference implementation of the JRE,' which, along with GlassFish, would become entry-level gateways to IBM's WebSphere stack. Moreover, MySQL would give IBM's database division a significant entry-level hook, and NetBeans/Eclipse would unify IBM's front against Visual Studio. 'All in all, this move would solidify IBM's role as "the developer company,"' McAllister writes. 'In other words, if this merger goes through and you're an enterprise developer and you're not an IBM customer now, get ready — because you soon will be. Better bring your wallet.'"
And blackbearnh writes with a short interview with Brian Aker (who came to Sun as MySQL's director of architecture, and is now the lead for MySQL fork Drizzle) about what life would be like under Big Blue's control.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
anotherwards, MySQL 3.x... (Score:5, Insightful)
Re:Shnizzle (Score:5, Funny)
That's not how that English guy on House talks.
Parent
Re:Shnizzle (Score:5, Funny)
Parent
Re:Shnizzle (Score:5, Funny)
Your humour depreciates? I guess I'll have to check this thread out in a year or two to see if it's still funny.
Parent
Re:Shnizzle (Score:5, Funny)
Parent
Great, even more insecure web apps (Score:5, Insightful)
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?
Re:Great, even more insecure web apps (Score:5, Interesting)
Parent
Drizzle? (Score:5, Funny)
Fo' shizzle!
Re:Drizzle? (Score:5, Funny)
Microsoft, of course, was busy "revolutionizing" the look-n-feel of MS Access.
Parent
No views?! (Score:5, Insightful)
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:5, Funny)
Which has the unfortunate side effect of making the application portable across DBMS's.
I'm just sayin'...
Parent
So it's like SQLite... (Score:5, Funny)
...reinvented, but with security flaws. Awesome!
Giant leap toward the MySQL dream (Score:5, Funny)
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.
For Crying Out Loud (Score:5, Insightful)
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.
Removing all the useful things... (Score:5, Insightful)
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.
All for it (Score:5, Interesting)
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.
People don't understand rational databases. (Score:5, Insightful)
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.
Re:Love the lack of Windows support ! (Score:5, Funny)
Why would anyone in their right mind set up a Web/SQL platform using MS products?
My name is Maximus Decimus^W^WBill Gates, ex-commander of the Armies of Redmond, General of the MS Legions, loyal servant to the true emperor, Steve Ballmer. Father of a murdered operating system. Husband of a bloated Office Productivity Suite. I shall have my vengeance, in this web or the next.
Parent
Re:Love the lack of Windows support ! (Score:5, Interesting)
Why would anyone in their right mind set up a Web/SQL platform using MS products?
You'd be surprised. Our web team recently got on an "I love MS!" kick for some reason. They'd been on Linux for years but a lot of the new/shinny buzzword stuff that they wished to install wanted Active Directory, IIS, and other non-sense. Because the Linux setup didn't lend itself well to installing all that proprietary stuff, and because they convinced themselves (somehow) that the most popular software is always the most insecure anyways (so Apache being the most popular webserver is the most insecure), they switched to Windows + IIS (+MySQL, but SQL Server is being pushed hard) to host the website.
Now I've even had pressure to convert my servers from Linux to Windows where possible to "standardize".
On a more on-topic note though, I'm not sure where this leaves MySQL itself. As a "real" database, it naturally can't compare to SQL Server or Oracle, but even competing in the free segment, PostgreSQL blows it away. 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.
Parent
Re:Love the lack of Windows support ! (Score:5, Insightful)
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...
Parent
Re:Love the lack of Windows support ! (Score:5, Insightful)
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?
Parent
Re:Oh man. (Score:5, Insightful)
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.
Parent
Re:Oh man. (Score:5, Informative)
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.
Parent
Re:Oh man. (Score:5, Informative)
* 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.
Parent
Re:Oh man. (Score:5, Informative)
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.
Parent