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.
"According to the Drizzle FAQ, the database will be licensed under the GPLv2 and be available on Linux and OS X platforms. Aker stated that he is unwilling to support platforms without a proper GNU toolchain, such as Windows." Get on board MS! Why would anyone in their right mind set up a Web/SQL platform using MS products?
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?
Fo' shizzle!
A post a day keeps productivity at bay.
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
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.
...reinvented, but with security flaws. Awesome!
Uh, doesn't removing the query cache run counter to the goals of making it fast?
It just begs the question, Who is the Drizzle?
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
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)
One ring to bind them - should probably have more fiber and less rings in their diet.
So this is basically a client/server version of sqlite with better concurrency, minus a bunch of useful features like views?
Can I make a Beowulf cluster of those trimmed down mysql servers ?
LADP? DALP? PADL? (Up shit creek without, presumably...)
Why "Drizzle"? What a damp, depressing, generally wet name....
Find Japanese addresses in English on Google Maps Japan: http://diddlefinger.com/
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?
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.
For shizzle?
...perhaps I should considering using a database on my website. MySQL always was too fat.
FUCK SLASHDOT!
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.
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.
Whence? Hence. Whither? Thither.
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?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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 ;-)
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
This is something which can only further promote bad programming practices.
But then I'd never use MySQL anyway.
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.
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).
F' Shizzle?
Any technology distinguishable from magic is insufficiently advanced.
That's people writing triggers on every damn table!
I think "Vapor" would have been a better name. This is even lighter than SQLite which incidently does have views, triggers and prepared statements. I really fail to see the point or the market, unless they are aiming at the embedded sector... but the article says "powering websites".. FAIL!
Why not just use PostgreSQL and get away from the MySQL mess entirely?
... in a server meant for high concurrency use ... isn't that just shooting yourself in the foot or what?
---
"The chances of a demonic possession spreading are remote -- relax."
So basically they are going to re-release MySQL 3 under a new name.
Hooray for Launchpad!
Colin Dean Go a year without DRM
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.'"
Seriously, when I saw that views were likely to be cut I was going to ignore this product. But a line like that gets me onboard.
Nobody ever got fired for buying Microsoft, but that's only 'cause I don't make hiring decisions. Yet.
My turnips listen for the soft cry of your love
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.
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.
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.
Blessed are the pessimists, for they have made backups.
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.
These people want to remove prepared statements and stored procedures? When they are probably one of the best ways to prevent sql injection??
I think the invisible hand of the market has its middle finger extended
--A wise old fart named SC0RN
I hope the database will run on Zune so I can squirt my Drizzle.
Throw out Triggers???
Stop being racist you stupid American cunt
Seems like everyone is missing the point that the features aren't being completely removed, they're just being removed from the core and separated into modules.
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.
all I know is it's not Master Shake, although they are very close friends!
It's also proof that the creators never did understand views, stored procedures, referential integrity, triggers, ACID database properties and everything else that makes a true relational database like PostGreSQL.
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.
Really tiring... really... Still C++... should require C compiler complexity only ... well, should go for GIT instead.
Bazare is
And GPL for what, since we have to surrender our GPL rights to a for-profit organisation(Sun upper management and board) and in no case I would like to have my code in their closed proprietary forks...
We need a Linux-spirit-like SQL DB engine for God Sake!
I foresee many posts on thedailywtf about projects which implement this 'technology'...
If you don't like the feature set use the regular MySQL. This isn't meant to replace a general database, it's an architectural trade-off to solve a very specific high concurrency issue by optimizing both feature set, design, and code. If you don't like it or think you know better don't use it. Good Lord, they didn't take away your precious, just offered you another option.
and what the hell is the obsession with a "slimmed down" database for web apps? it's not like the client is downloading the database backend. make the database backend as feature full as you can to make your apps, you know, BETTER.
my prediction is dribble will be used by a few nob headed php programmers, who will shortly post on /. how the dribble database is 10x faster than regular mysql. they will also forget to mention that it fails at anymore more complex than select *
If you mod me down, I will become more powerful than you can imagine....
Master Shake: Drizzle here. ..have put Fat Albert in a can. ...Have put Fat Albert in a can..in your can.
Meatwad: Yes, Drizzle? Violent criminals have put.. what did you..Fat Albert?
Frylock: Prince Albert..
Meatwad:
Frylock: No, no. It's Prince. Prince Albert.
Meatwad: Oh, okay. Hang on.
Master Shake: I'll need precise coordinates, ma'am.
The wiki says there is no FULLTEXT support. TFA says no Prepared statements and no query cache. How is this supposed to be good for a web application?
Check out my cross-platform apps
Shake: [Answering phone] Drizzle here.
Meatwad: Hello, yes Drizzle. Violent criminals have put...Fat Albert, what, what it's...
Frylock: No, no, it's Prince Albert.
Meatwad: Oh, have put...Fat Albert in a can, in your can.
Shake: I'll need precise coordinates maam.
Meatwad: Oh okay, it's...it's in your butt, boy! It's in your butt! Did you hear me? It's in your butt.
Shake: Pranksters! Sons of-
But someone still has to write those sorts of triggers, for every database, every time the create one. Why isn't this sort of audit logging (changing, data changing, etc.) built in to the database engine automatically, with a few configuration options available?
Data and table change logging 'by default' would be immensely useful, and if it's done optimally by the db authors, you're going to avoid issues of poorly written useland triggers and stored procedures by people who aren't as intimately familiar with the core engine.
creation science book
It's hilarious how half the comments here are saying most of the processing should be done client-side for the sake of portability, and half are praising the merits of stored procedures and suchlike in the name of security and performance. If you understand abstraction, it's a painfully trivial matter to write your web app to support either method as the situation demands.
C'mon guys, this is basic first year Comp Sci stuff. You *can* have it both ways.
...but then again, I work with Oracle.
Advice: on VPS providers
http://www.youtube.com/watch?v=rZ5GXPg_gD8
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.)
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!
Let me show you an approximation of what this article looks like to some Slashdot posters, in their hurry to be frist pots. . .
"Builder AU reports that MySQL's director of architecture, has unveiled Drizzle, a database project. . .will have . . . code being removed from the Drizzle core. 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."
See, it all makes sense now.
modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists and some data types
Views: Most commercial grade systems use them to denormalize collections of data for frequent data transformations and easy reporting. In my experience they're not needed on smaller, simpler, or less normalized databases, but on very complex databases they're essential.
Stored procedures: Typically used to push the business rules for pure data manipulation into the server where they can be executed more efficiently. Again, smaller system don't need them, larger systems will scale better with the ability to put the processing where it can be done the quickest.
Query cache: I can't imagine why you'd throw out the execution plans for frequently used queries. This is simply a performance issue, and high concurrency systems will drag without caching.
And so on. And there's no support for a Windows version. In every instance, including the statement from the FAQ, "'This is not a SQL compliant relational...' Very true, and we do not aim to be that," it's obvious this isn't intended to be a commercial grade, common OS, broadly used, SQL compliant database engine. It's a hobby engine. While the author of the article lauds InnoDB, I honestly believe that the mindset is to produce a database engine microkernel, a la Linux, that will result in an organic, evolutionary model of distros, with various versions and feature sets arising with the fittest surviving.
Which just means I'll be using MySQL.
Sorry, but my software is database-agnostic, insofar as it expects SQL-92 compliance. I have no use for an extreme low end, non-scaleable out of the box, handicapped database engine. Why would I? MySQL gives me everything I need for doing any application I can come up with, and with the correct configuration it body-slams its best competitors.
Thanks, but no thanks.
*** *** You're just jealous 'cause the voices talk to me... ***
Argh, I had mod points yesterday, but not today when I needed them! :-(
Yes, views and trigger and stored procedures are good, and if you have a really competent DBA that is part of the development team and can take responsibility for those parts, and if you're ok with being tightly tied to a certain DB, then fine.
But most projects don't look like that, and most projects don't need that. If you want speed, then you want to hit the database as little as possible, and when you do, you want it to do as little as possible. Constraints, views, joins, transactions, all these things add up and you lose performance.
Scaling a database is really, really, hard. Shifting the work to the web server and adding a bunch more web servers is easy.
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.
A alimmed down version of MySQL?
Isn't that called Berkeley DB?
Just because it CAN be done, doesn't mean it should!
Sanitation is ridiculously easy. You just gotta - like - read your code. Or better yet, let your database driver do the sanitation for you.
INSERT INTO foo (stuff, morestuff) VALUES ($1, $2)
Piece of cake.
Like all pain, suffering is a signal that something isn't right
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).
Views solve that problem, and are easier to work with as things change over time.
Like all pain, suffering is a signal that something isn't right
For those of us who write sites that need to be able to scale to hundreds of database servers, this is exactly what we want.
When the database is very much behind a firewall on a tightly controlled set of servers, we don't care about access controls. Memcached is a good example of this: no username or password at all. It's not useful on a shared hosting system, but that isn't the goal.
When you're trying to partition your data across multiple database servers, joins, views, and triggers are pretty much useless, since data may very well be on a physically different machine.
When you're trying to do extensive caching (like with memcached) joins, views, triggers, and stored procedures are pretty useless, since you need to do it all client side anyway so you can keep your cache up to date. ORMs make this easier.
When you've got a high write/read ratio (mine is 50/50), query caching is useless.
For those of us writing code that does all the partitioning anyway, we care about speed and data consistency and little else. Everything else is bloat.
There's a reason google released their patches for mysql 4.x instead of 5.0 which was long since used in production.
Imagine this: Apache announces, that it will remove some of its features, like for example mod-php, mod-perl, mod-rewrite.. moved to modules! Gone - forever!
I have never ran into a problem that Mysql couldn't handle. You are living in the 'gotta have this specific feature that I will never really need' world. Seriously man, Mysql can handle 99.99999999% of the problems that arrive when coding an application in the enterprise world. Your database elitism just makes you look like an asshole. Take that shit somewhere else.
I don't understand why no one modded you off topic too. You flaming Mysql gets you uber mod points; way to go! How about either complimenting the project or just shut the fuck up and don't post? No one really cares what database you think is best.
But hey this is slashdot where the 'my * is bigger and better than yours!' attitude always reigns supreme.
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?
Because people don't try it, you don't realize how much better PostgreSQL really is.
If this were really true then a sufficient community of people looking to make it accessible would grow up around it. A common complaint is lack of easy tools to use with PostgreSQL - a reasonable complaint because there is no point in everyone wasting their time using backwards tools.
The fact of the matter is that MySQL does what the vast majority wants it to do, and has better accessibility. Only functionality that is an order of magnitude better is going to overcome that - and while PostgreSQL may be better, it's simply not that much better.
[Ego]out
patent trolls who try to 'drizzle in'....
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
It has nothing to do with a DBMS being "crappy" and has everything to do with higher-end features being supported one way on one DBMS, another way on another DBMS, and/or not at all on yet another DBMS, and the real-world situation that some of your customers/users run Oracle, some run MS SQL Server, some run DB2, some run PostgreSQL, some run MySQL, etc.
All of the above examples implement higher-end features differently. Even if two different DBMSes support some high-end feature, writing a stored procedure that works on Oracle is quite different than writing a stored procedure that works on MS SQL Server. Shoot, even something as stupidly simple as creating an auto incrementing column is implemented differently between Oracle and MS SQL Server, neither of which could be considered "crappy" in terms of high-end features.
So think what you will, but out in the real world, if I can code to the lowest common denominator to avoid writing three, four, or five different versions of my application, unless there's some pretty extreme performance to be gained, that's what I'm going to do.
Oh, and if I'm coding my application to work across MS SQL Server and Oracle without modification, there's a really good chance it will work on pretty much every DBMS, including MySQL.
I like the idea of just having a transparent layer in the language that wraps around whatever datastore you're using. I like the idea behind LINQ (Language Integrated Query), which is a Microsoft thing in C# 3.0 that basically lets you use SQL type queries on any "Set" of objects, be it a relational database table or tables, flat file or even arrays and data structures. Although it's kindof clunky, it might work for building prototypes because you don't have to worry about the data store, just the types. There is a similar project for Ruby called Ambition which looks pretty cool also.
Now, I know ODBC was supposed to do abstraction to a pretty full level, but to add arrays is the kicker for me. It's not efficient at all, but it make sense from a human perspective. That means it's easier to write code. I know Drupal and a few other CMS systems use a database abstraction layer (sort of), that will translate queries into whatever database you're using. It's not perfect, though. I know I'm always writing tons of functions in PHP to get the SQL the hell offa my page. Prepared statements and procedures are ok for that also. And if I want a lightweight SQL server, there's SQL Lite already!
Anyway, a better use of time would be to bring LINQ to this side of the street. I really think M$FT has something, for once. I mean, I saw a demo where they did a full AJAX app in about 10 minutes, you can run the query, joining a SQL query (adapter) with an array you already had, and maybe union that with an XML file and return the result as, well, you can return ANY data type you can bring in; so you could return a SQL resultset, or an array or XML or JSON or whatever you want. It handles MOST of the fuss for you. You have to do some mapping ahead of time but you can use XSD or a mapping array or a SQL JOIN table......... It's a universal adapter. BRING ONE TO PHP or at least RUBY. Or I could deal with a Python version.
Cool! Amazing Toys.
This time it's based on InnoDB
-- "As a human being I claim the right to be widely inconsistent", John Peel