Slashdot Mirror
MySQL to Get Injection of Google Code
inkslinger77 writes to mention that MySQL has published their software roadmap out through 2009 and it includes an injection of code from Google. Google remains relatively secretive about how their systems work but they are one of the largest users of MySQL. Earlier this year Google signed a Contributor License Agreement which provides a framework for them to contribute code to MySQL. "The search company has done a lot of work customizing MySQL to meet its special needs, which include better database replication, and tools to monitor a high volume of database instances, Axmark said in an interview at MySQL's user conference in Paris. MySQL will include some of those capabilities in future versions of its database, probably in point upgrades to MySQL 6.0, which is scheduled for general availability in late 2008, Axmark said."
Somehow when I put "SQL" and "injection" together, I don't like the result...
Well, except for when it involves Little Bobby Tables...
Bow-ties are cool.
Eat that, Oracle.
Seriously the database layer is being commoditized, and MySQL and PostgreSQL are leading the way.
My only question, was Google required to disclose these changes, or are they just doing the right thing (again)?
Make sure everyone's vote counts: Verified Voting
It's nice to see them giving back.
If only Microsoft would give back on all the mods it has made to the Unix tools. Example: http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
Probably because it's a decently-performing ISAM engine with builtin replication. It's not terribly safe (index file integrity is terribly brittle) or smart (it only recently learned there isn't such a date as Feb 30), but you can still at least write ad hoc queries to your tabular data. I doubt Google is using it for HR or CRM.
Done with slashdot, done with nerds, getting a life.
I prefer PostgreSQL but MySQL isn't crappy.
For years MySQL offered better write a few read a lot databases than PostgreSQL. It may still offer better performance for those types of operations. That is the way most websites used MySQL. It is a good tool for some applications. Slashdot is one of them.
Yes I think PostgreSQL is better but MySQL isn't crappy.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Sounds like a win win situation for everyone. I've always like MySQL better than Access, not just because its an M$ product. I don't know about all of you but I can't wait to download this and see these new updates. Hopefully it won't just be in the enterprise edition.
If you want news from today, you have to come back tomorrow.
I love MySQL and use it for my site but i'm still waiting for some bugs/request features that has been in the tracker for years, like "limit has to be a constant and can't be parameterized" which is very annoying if you're using a stored procedure to fetch a page of results...
Will it ever be solved?
I prefer Postgres to MySQL. I wonder whether these MySQL revisions will be generic enough to use to improve Postgres.
I also wish these two databases interoperated more. I'd like to use a MySQL proxy to my Postgres server, so apps depending on MySQL could still work, but use Postgres to actually process the data (or just serve as a master DB for replication). Porting apps between DBs, and huge projects to join across different apps' tables in different types of DB servers should be ancient history. Mixed DB-type clusters might not be high performance, but they'd get the iterative development started, after which performance could be just an optimization, which is the right way to do it anyway.
--
make install -not war
Mysql 5.1 has been in preproduction since November 2005 and still isn't available as a GA release (aka don't use it in production). Are they sure they can get a 6.0 GA release out by next fall?
This is really good of Google to contribute this back, I'm just wondering how long it will be before we all can utilize their changes. I hate to see the code stay stuck in the devel cycle for three years when Goggle is using it to their advantage right now at this very moment.
They are the changes mentioned here, I think. I guess the changes will be ported to MySQL 6 (if any porting needs to be done at all...who knows at this point).
df -h
SQL injection is useful! That's how I got my first million.
Damnit, Google is just like Microsoft. They always have to get their grubby little hands on everyone elses good stuff. Forkit, I'm forking it! :)
The comment in the article that foreign keys won't be supported until 6.1 speaks for itself. It might not be *crappy* to some but to me this alone makes it quite useless and this admission is only the tip of the iceburg. I sincerly hope that one day MySQL will graduate from the realm of being a toy DB.. That said toy DB's are quite useful for a number of applications, just not any I personally care about.
Wake me up when even a single financial institution uses it for transaction processing.
No no no, obviously the parent knows far more than a multi-billion dollar company that only specializes in high impact, ridiculous performance databases.
Duh.
Linus > Every Linux User. Ever.
Jobs > Everyone. Ever. We mean it. Seriously.
Ballmer > Duck! Incoming chair!
Bush > All you stupid smart people.
See? Now we can keep growing the list.
"Don't feel bad for me child; I'm the monster that hides under your bed."
They need to add a GOOGLE function to allow queries to be searched nicer.
SELECT * FROM articles WHERE GOOGLE('boobies');
something similar might be available but it is a PITA to list the fields to search and specify the operators etc
liqbase
Now when is somebody going to actually improve the DATA management aspects of MySQL, rather than the SERVER management? How about making more views updateable? Or at least allowing triggers on views? So I can refactor my databases? Nah, I guess that would require somebody who actually cracked open a book on database theory once.
So, does this, like, inoculate MySQL from Microsoft or something?
- RG>
Hey pal, this isn't a pleasantforest, so don't waste my time with pleasantries!
They know for their particular application, if they only return 47,000 hits, instead of 49,500, it's really no big deal. If they return some pages that aren't really relevant, also not a big deal.
That's kind of a rare use of a database.
When most of use use databases we need real exact numbers from it. Foreign key enforcement is a must. 'Strict' is not an option.
That's why they can use a crappy database, because their answers don't have to be complete or entirely correct. Crappy is 'good enough'
SQL has Google injections?
WTF are you guys talking about MySQL has foreign keys you douche bags.
You never saw "The Abyss," did you.
"Made up/misattributed quote that makes me look smart. I am on
MySQL cannot enforce foreign keys constraints on MyISAM tables. It 'kinda' can on Innodb tables.
Having them and enforcing them so they are actually useful are 2 different things.
And if you'd bother to RTFA, you would see that MySQL is moving to away from Innodb to 'falcon'. "but some InnoDB features, like foreign key support and full-text indexing, won't be supported until MySQL 6.1.".
So MySQL is moving away from the only table types that can actually 'kinda' enforce the use foreign keys at all.
I think that would make you the douche.
"That said toy DB's are quite useful for a number of applications, just not any I personally care about."
Like the one you are using right now?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
That's like saying PCs are toys, because banks use mainframes to handle your credit card transactions.
That a device or program isn't suited for a certain task doesn't mean it's a toy.
It's not terribly safe (index file integrity is terribly brittle) or smart (it only recently learned there isn't such a date as Feb 30)
http://en.wikipedia.org/wiki/February_30
You'd be wrong then. Have a look at the Oracle Store and you can get Standard One for $149 per user (5 User minimum @$745.00)
Or you could get unlimited users for $4995 per CPU....
Oracle is expensive, its just not that ridiculously expensive.
Once this stabilizes, I'll probably be using it. It's nice to see such a direct impact on my work from their contributions. Thanks guys!
You drank my drink, you drunk!
I could be wrong, because I am only posting anonymously, but I doubt they are using mysql to do the actual google search itself. Most likely they use it for the write operations involved with adwords and their other clickstream revenue services.
Even so, I bet they can make use of not requiring all of ACID through using replication, or just not caring to the last click that every click have to get to disk.
Probably some combination of query efficiency and inertia.
What do you mean 'kinda' it supports them. You get an error if you dont have a parent, you can't delete something if it has children, you have the ability to cascade your deletes/updates . . .
As far as MyISAM, if you choose it you are choosing it for the speed of its reads . . . you are opting to not have foreign keys. If you want foreign keys, you use InnoDB . . . So saying "MySQL doesn't support foreign keys" is wrong, because it does via InnoDB.
You use SQL Server dont you . . .
Oblig SQL Injection http://www.xkcd.com/327/
-1 not first post
MySQL has many 'gotchas'. Google around for many sites with lists of them. They are slowly cleaning them up, they have a very bad track record of not keeping data clean. Even their latest 'strict' rules still aren't all that strict. The gotchas have traditionally contained plenty of broken foreign key problems.
The latest versions of Innodb are much better, (earlier versions didn't do any of what you said very well) but now they are going to be moving away from even that.
I do use SQL Server, and Oracle, and Postgresql. Firebird looks interesting, but I haven't had time to play with it. I've had the unfortunate experience of having to work with some MySQL databases, but I refuse to work with that anymore. I prefer mature databases with a full set of database features. Broken databases written by folks who say idiotic things like 'You don't need transactions' don't interest me.
you think they're storing the entire interwebs in a MySQL database? last time I checked it was used for AdWords, where exact numbers are indeed really relevant.
I have heard a lot of scary stories from the bashers but this is a new one. MySQL has trouble counting rows now?
ps: murk loar
Stop Computers/Cars Analogies on S
You'll see a lot of this sort of astroturf when successful Open Source projects are discussed.
Bill Hilf's lab has to pay for itself somehow.
So your MySQL experience limits itself to "I read some stuff on the internet" and you have an expert opinion now? The parent was right, you are a fucking douchebag.
The main reason why most people do not use mainframes: The initial cost of buying.
Mainframes and similar systems are better than a PC in more or less every aspect.
Can't read eh? I said I've worked with MySQL.
If you are used to MySQL bashing, then you should realize the reason for the wrong number of rows is likely from bad data (random defaults put in if any out-of-bounds data is entered, lack of referential integrity from lack of foreign key constraint enforcement etc). It's not trouble counting rows. It's bad data that often results from a non-strict database.
This is rediculous. Even MySQLs own documentation states it doesn't even try and compete with the major players. They are going for good enough for many general purpose uses.
For my purposes their good enough does not cut it and this is what makes it a "toy" to me. When they stop producing releases missing absoultely vital features such as foreign keys I'll reevaluate my *opinion*. Which I have done for several years now it has gotten better over the years and I see no reason for that trend not to continue.
I have filed several bug reports for missing features and correction of non-complient behavior and several years later they are still unaddressed.
I've had quite enough of people quoting high performance of MySQL for trivial tasks and people spouting about all these *big name* companies who use it without having any understanding of the underlying issues or context... which make all the difference in the world.
I can perform thousands of queries against a 100TB CSV formatted text file per second with about 20 lines of code... so what?
I've found that foreign keys are only really useful for incompetent database designers.
As you can plainly see, MySQL works fine without them.
The biggest websites on the internet use it.
Ah so a incompetent monkey is playing with the code instead of MySQL being at fault?
Not familiar with MySQL gotchas eh? MySQL has a long history of not keeping your data intact. In a normal database, if there is a constraint on a column limiting it's values to the numbers 1-20, if you try to insert 21 the database will throw an error. For much of it's life, MySQL would silently change the 21 to a 20.
You can reinvent the wheel in your code if you want, (folks do it all the time, sometimes with success, sometimes having big holes in their code) trying to check things to make up for the fact that your database can't do the basic functions of a database, or you can use a real database that enforces constraints consistently as it should.
I actually at least partially disagree with you.
PostgreSQL used to be a pain to work with. hard to use, and had somewhat interesting problems with things like restoring backups. It is now extremely robust, solid, powerful, and has great performance.
MySQL is a good database where all you need is a simple interface to try to store data and where you dont care that much if what you get out isn't exactly what you put in. This means simple CMS needs, and simple storage needs. Google would fit that profile.
However, as an RDBMS, MySQL sucks badly. Yeah, that is like saying that a PC sucks as a mainframe, but...
LedgerSMB: Open source Accounting/ERP
I think we can all say that MySQL is pretty crappy at being an RDBMS, compared to PostgreSQL or even Firebird.
However at the time Google was evaluating versions, PostgreSQL's performance wasn't so great. It was a pain to use and develop for, and backups had a tendency of being dumped in the wrong order so the data could not properly be restored. (I have been using PostgreSQL primarily since 6.5.)
Firebird? It wasn't even around yet. Sure there was Interbase, but it was not open source.
And Google didn't need transactions scalable security management, or anything else where MySQL gets fundamentally failing grades. So what did they do? They chose what was the best database at the time as their needs required.
Today, PostgreSQL is a far better database (will continue to be even after the infusion of Google code since Google obviously isn't using it for anything where a real RDBMS is required), so I would think that if a startup like Google were starting today, a different choice might have been made. But for the time it was made, it wasn't a bad choice.
LedgerSMB: Open source Accounting/ERP
Note that JET is used by Access to store relational data, but it is also used by Exchange to store nonrelational data. There is no SQL support in JET. It is not like SQLite so much as like BDB.
LedgerSMB: Open source Accounting/ERP
PostgreSQL is BSD licensed, MySQL is GPL licensed.
But aside from that, it is unlikely that Google's code contributions go beyond general performance benefits, management of large numbers of systems, and maybe full text search.
PostgreSQL 8.3 already will have a great, mature full text search capability, is far easier to manage in large environments, and can handle more complex loads than MySQL can. So I don;t think that there is likely to be a lot of useful ideas which could be transplanted.
Finally, the architecture of the programs are entirely different. MySQL uses a single process, multithreading model (which has lead to nteresting cases where a thread can cause the entire service to stop working!) while PostgreSQL uses a forking process model.
THe two are fundamentally different.
LedgerSMB: Open source Accounting/ERP
Actually, there are several cases where you may think that MySQL has foreign keys when it doesn't. So the support of foreign keys is not entirely complete.
;-) ), you don't get foreign key enforcement. No warning. just no enforcement.
If innodb is not installed, you get a MyISAM table without the foriegn key enforcement and not even a warning is given on table creation (you do get a warning when you insert, but the application is unlikely to be watching).
CREATE TABLE table2 (
id int autoincrement primary key,
foreign_id int references table1(id),
test text
) type=innodb;
CREATE TABLE table2 (
id int autoincrement primary key,
foreign_id int,
test text,
FOREIGN KEY foreign_id REFERENCES table1(id)
) type=innodb;
In one of the above examples (won't say which one
Yes, MySQL has foriegn keys. It doesn't have them 100% but it does have them.
LedgerSMB: Open source Accounting/ERP
So have I. I have even written published papers introducing MySQL. And Lurker is right on pretty much all his points.
Now, all software has gotchas, but MySQL's ones are unusually severe.
I would also point out that once you have done serious work with a *real* RDBMS, you will tend to get frustrated when you have to go back to MySQL.
LedgerSMB: Open source Accounting/ERP
I write serious business applications. I have done serious work with MySQL, Firebird, and PostgreSQL. In general, I would say that PostgreSQL is the best of the three.
Now, contrary to your opinion, PostgreSQL is actually quite successful It is just not as visible because it has not historically been as good at the super-simple website app stuff. However, I would not trust any money-tracking applications (not even a shopping cart) to MySQL.
LedgerSMB: Open source Accounting/ERP
It allows you to access MySQL from within PostgreSQL. You can also access anything else you can reach via Perl's DBI interface.
LedgerSMB: Open source Accounting/ERP
Google will get a MySQL injection....
LedgerSMB: Open source Accounting/ERP
I get this time and time again, websites that are 99% reads, with a few scattered writes, yet people insisting we need a "proper" database for that. ACID? Transactions? Rollback? FOR WHAT!
Worsed example ever, simple webpage that allowed people to post their phone number to take part in a price draw. ANY kind of database is overkill for that and yet I had to argue against the proper IT guy wanting another oracle license for the server that would host it.
Geez, the only reason I used a database was to make it easier to search for duplicates, so I could tell the user if they had already entered.
Note that this post has how big business doesn't use MySql. Apparently google doesn't count.
Offcourse it makes sense, if you work in an enviroment where you boss wasted money on Oracle, his boss wasted money on Oracle, you are hardly likely to make them look like fools and use a free product. Costs savings? Yeah, the bosses will be into that, the moment they fire you and save your salary for making them look bad.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
It's interesting how a "database" means something much different than it did just a few years ago. Oracle has been selling their DB for years now not based on the relational data storage ability of the product, but on the other things you can do: monitoring, high availability, business intelligence queries, etc. For instance, one of the big selling points of Oracle 11g is the ability to build OLAP cubes within the database engine. That's a big leap from what I've traditionally thought of as "database functionality".
These additions to MySQL by Google shows that it's going the same way. Makes you wonder what "database" is going to mean 5 years from now.
Skip Franklin
It's always darkest just before it goes pitch black. -- despair.com
> I've found that foreign keys are only really useful for incompetent database designers.
Quoting from the official MySQL 3.x documentation are we? Funny how things like that would disappear once mysql got such a feature.
What I want to know is when will the INNODB engine get fixed from it's ticking timebomb of perpetual and irreversible expansion? I like the engine, but that's a WICKED flaw. I ran a test once which resulted in 40 gigs, then cleared the table, and the 40 gigs is STILL there. That's GOT to be fixed. At least POSTGRESQL doesn't have that problem.
The lack of your ability to install the InnoDB engine and user correct syntax doesn't mean it doesnt have foreign keys.
Yes, but it does mean that as a programmer, you can't count on your user having foreign key enforcement.
The issues are:
1) Only *some* MySQL servers have foreign keys
2) Valid SQL syntax for foreign keys is silently ignored.
#2 isn't a huge issue but it leads to bugs. #1 is the killer when you are distributing real software.
LedgerSMB: Open source Accounting/ERP
MySQL's default engine (since 5.0?) is innoDB, which supports foreign keys just fine (I have a database full of them). The article was talking about the new engine coming in MySQL 6 called Falcon, which doesn't have foreign keys support yet.
See, the way MySQL works, you can specify an engine for each table (MyISAM, InnoDB, MEMORY, etc.).
Different engines have different characteristics, so for example if you have a "connected sessions" or "active users" table, you can use MySQL's Memory Engine so that the entire thing is in memory all the time. I didn't use that specific engine before, but I believe you lose the data when you kill the mysqld process (I could be wrong).
I like the concept of having different engines since you can choose an engine that was designed to closely suit your needs for a particular table, and will probably help you squeeze more performance out of your database (along with query caching and what not).
I think Oracle has a similar feature, I'm not sure though since I'm not an Oracle DBA (Or a any DBA for that matter).
If you can't mod them join them.