MySQL to Get Injection of Google Code 195
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."
Re:MySQL? (Score:4, Informative)
Re:MySQL? (Score:5, Informative)
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.
Re:Hells yeah (Score:5, Informative)
We of course, try to contribute back all the changes we possibly can.
If you look around, you'll see we just don't publicize all the changes we contribute back (and we in fact, didn't publicize this one ourselves).
Re:Very Niiiice (Score:4, Informative)
JET (Access' database engine) is more of a data storage engine with SQL support than an RDBMS, which MySQL is (which could have been debatable until v.5 I guess, hehehe )
Re:Transplant to Postgres? (Score:1, Informative)
Re:Transplant to Postgres? (Score:3, Informative)
Good for you. Of course, your applications may very well be of a different class, and so perhaps Postgres is a better solution. But remember, if you're doing mostly reads, and not a ton of writes, mysql will blow the socks off virtually any other solution. And, coincidentally, that pretty well describes most web applications in general, and probably Google in particular.
Re:Very Niiiice (Score:2, Informative)
Re:Transplant to Postgres? (Score:3, Informative)
I have a site with 3GB of database, updated once daily, in bulk; the rest of the day it's doing several reads per second over the whole thing (indexed so that it can jump to the right parts for each query; but each query tends to hit a different 5-10% of the rows, so all the data is "active"). I found switching from mysql to postgres gave quite a noticable performance increase -- the whole server was no longer crying in pain and grinding to a halt under heavy load~
Note that the DB server only has 512MB RAM -- while the database was smaller than that, mysql was indeed the faster :3
Re:Very Niiiice (Score:3, Informative)
Re:Transplant to Postgres? (Score:3, Informative)
<?php
class Biz
{
// Internal Database Functions
static private $cs;
static function SetConnString($connstring)
{
Biz::$cs = $connstring;
}
static private function SendQuery($q)
{
$db = pg_connect(Biz::$cs);
$r = pg_send_query($db, $q);
return;
}
static private function SendParamQuery($q, $args)
{
$db = pg_connect(Biz::$cs);
$r = pg_send_query_params($db, $q, $args);
return;
}
static private function QueryForRow($q)
{
$db = pg_connect(Biz::$cs);
$r = pg_query($db, $q);
$a = pg_fetch_all($r);
return $a[0];
}
static private function ParamQueryForRow($q, $args)
{
$db = pg_connect(Biz::$cs);
$r = pg_query_params($db, $q, $args);
$a = pg_fetch_all($r);
return $a[0];
}
static private function QueryForRows($q)
{
$db = pg_connect(Biz::$cs);
$r = pg_query($db, $q);
$a = pg_fetch_all($r);
return $a;
}
static private function ParamQueryForRows($q, $args)
{
$db = pg_connect(Biz::$cs);
$r = pg_query_params($db, $q, $args);
$a = pg_fetch_all($r);
return $a;
}
static function AddJournalEntry($PersonID, $EntryTitle, $EntryDetails, $EntryDate)
{
$JournalEntry = Biz::ParamQueryForRow('SELECT * FROM addjournalentry($1, $2, $3, $4);', array($PersonID, $EntryTitle, $EntryDetails, $EntryDate) );
$JournalEntryID = $JournalEntry['addjournalentry'];
return $JournalEntryID;
}
static function GetJournalEntry($EntryID)
{
return Biz::ParamQueryForRow('SELECT * FROM getjournalentry($1);', array($EntryID) );
}
static function GetPersonJournalEntries($PersonID, $PageSize = 20, $PageNumber = 1)
{
return Biz::ParamQueryForRows('SELECT * FROM getpersonjournalentries($1, $2, $3);', array($PersonID, $PageSize, $PageNumber));
}
}
?>
Re:MySQL? (Score:5, Informative)
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.
Re:MySQL? (Score:2, Informative)
http://en.wikipedia.org/wiki/February_30 [wikipedia.org]
Re:Umm No... (Score:3, Informative)
I can't think of anything that is in MySQL that Standard Edition doesn't deliver. And if your looking at EE then really for $40k per CPU you'd be running
something that'd be using the EE features like Label Security or some of the Partitioning / OLAP stuff.
Admittedly as an OCP I might be biased but I wouldn't go near MySQL when there are things like PostgreSQL around, something about wanting my Data Integrity...
Postgres compares nicely to Standard Edition (well once you factor in the costs its pretty neat for the smaller / lower end stuff) but really EE is only competing with
DB2 and even then only DB2 on zOS (which rocks!)
Re:"Do no evil!" - Sweet (Score:3, Informative)
Re:Very Niiiice (Score:4, Informative)
It's a non-server public domain database library. Yes, really public domain. Its databases live in files and there's no server component whatsoever; it's intended for use by a single application (although it supports file locking so that multiple processes can access the same database).
I use it in one of my apps. It's awesome. It's tiny (about 300kB), it's simple (no messing about with starting servers), it's blazing fast (for some tasks, it's up to an order of magnitude faster than PostgreSQL or MySQL --- for others, it's slower, though: benchmarks [sqlite.org]). More and more programs are starting to use it simply as a document store. It's great.
If you find yourself wanting to use SQL in a situation where only a small number of apps at a time are going to want access, or even if you just want to teach yourself SQL (it's got an excellent command line shell), do check it out.
Re:MySQL? (Score:3, Informative)
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.