Slashdot Mirror
MySQL 5 Production in November
thatoneguyfromphoeni writes "CIO.com is reporting that MySQL AB is eyeing Nov. for the production release of MySQL 5. 'The company is calling version 5 its most significant upgrade yet. It adds a handful of features considered important for enterprises that have long been available from market leaders Oracle Corp., IBM Corp. and Microsoft Corp. Chief among them are triggers, views and stored procedures.'"
MySQL has finally caught up to the state of the enterprise relational database industry...as it was in 1999. Points for effort, but everyone else is still ahead with core features like integrity, leaving them free to build on new and better features. Bundling with PHP will only get you so far.
Not everyone needs the same set of features in their database product. Some people want something that is very lightweight and fast.
Other people want bulletproof "unbreakable" databases with thousands of features. Some people want something right in the middle.
Having a variety of solid choices is not a bad thing. You should't be affraid of a little competition, as it is good for the entire market.
As much as I love (and use) mySQL, it's still not, nor will it likely ever be (never say never) an enterprise solution. Prove to me that mySQL is robust enough to be the backend service for a major bank's mortgage application, for example. It's simply not. As a previous poster already mentioned, mySQL has finally caught up to the base set of features that all major DBMS's had years ago. Now, after that rant, I will say this. mySQL is great at what it's designed to do. I use mySQL as the backend for personal websites and applications. It's (relatively) lightweight, simple, easy to administer, and, best of all, free as in beer (not withstanding products purchased from mySQL AB). So before you get all huffy about what I said in the first paragraph, just remember that mySQL is great at what it's made for, it's just not made to be an enterprise solution.
So they finally add features that postgresql has. And don't forget the more difficult to use licensing they have imposed compared to postgresql.
I was using all of these in PostgreSQL in 1999.
they never are, though.
it's probably more like "8 hits per second for 8 hours; 1 hps for 16."
which is still a joke for static content, but for dynamic, it's respectable.
So maybe people will clean up Oracle's _nightmarish_ security track record, because unfixed critical bugs for years is not an uncommon sight in Oracle land. I'd take security over features anytime.
Don't get me wrong, i know you're just a troll, although MySQL was/is lacking in some ways, as i'm perfectly aware of that, but nothing compares to not giving a sh*t about security especially in case of an enterprise level software costing so much in cash and resources.
These Oracle issues are well known as a lot of security experts prove it day by day.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Don't be silly. PostgreSQL has had this feature for ages (atleast since 7.x days) implemented via NOTIFY, which interested listeners can register to be notified of.
Thank you. But that is not what I meant. There should be a software mechanism that automatically identifies dependencies and resolves them. Leaving it to the programmer does not solve the problem because programmers come and go and may not be aware of old dependencies. The problem is especially annoying in legacy systems. Modifications made to a complex system can have unforeseen consequences if programmers are not aware of the dependencies.
One of the biggest advantages of enterprise level dbs is that they are not file based. That is there is one or more files that can store many table/indexes/etc.
Postgres recently added tablespaces, which allow you to specify a sub folder for these files. This is better then before, but not nearly where it needs to be.
There are advantages to having single files versus a larger file, but most are administrative in nature. It can also lessen the effect of corruption. A sinlge table might fail and would not effect others. If a big database file corrupts it can damage a lot of data.
Having a single files allows quite a few things.
First it greatly reduces File system level fragmentation. The file grows once and the sectors are right next to each other. When you have 10+ gigs of data this is a real concern.
Second it create a unified caching mechanism. The big file is broken into pages, generally 8k, which in turn store data rows. The data is not only user data, but indexes, system information. Other pages are used to store stats about other pages, and have header information about the file itself. Why is this important to caching, because you simply have a cache table, everytime a page is loaded it gets cached. Writing to page happens in memory and then written to disk. Enterprise dbs have huge caches. This is why 64 bit is so important for dbs, so we can have larger then 4 gig caches.
Third is backing up. Some might say the file backup is easier, I beg to differ. Especailly when it gets big. When you go to backup you backup each page in the file. You mark each one as being backedup. At the end of the backup you backup the write ahead log. This allows you to restore to exactly the time the backup finished. Lastly, a diff backup simple looks at each page that has changed since the backup and backs only those pages up. Diffs can be very fast and faster to restore then a write ahead log.
Also, single files on different drives arrays to increase performance. This is also capable with tablespaces. The good part is that the database knows only the file id that tables go on, and then file id corresponds to a file name on any path. With the right tool you can move the files around easily.
Replication is also easier because writes are to a file id and page id. The replica database can have files place on any drive at any map point as long as the data.
Both mysql and postgres got a way to go, but they are very nice products and one day can easily compete with the big boys. Although it will be a while before they are able to run high end clustered box with shared storage and super high speed interconnects, but if you need that kind of power, you've probably got the money...actually you absolutly do if you can afford the hardware.
"MySQL doesn't have triggers or stored procedures and views" to "Even if it does have triggers, stored procedures and views, it's still not a real database like Postgres/Oracle/SQLServer".
We have two websites, Boats.com and Yachtworld.com - Boats has an Oracle backend databsae, and YW has MySQL using the InnoDB engine.
The uptime is about the same for the two. We've had some issues on the Yachtworld database box due to 3ware drivers in Linux - they were corrupting pages in the database. Guess what? Innodb recovered without any lost data. Twice. This was a driver/hardware/linux issue, not a MySQL issue. We now appear to have a stable set of drivers, and I expect the MySQL database to hit 100% uptime pretty much every month.
Yachtworld gets several million distict page views per day, whereas Boats.com gets half a million.
Our MySQL database runs on a dual-opteron server, with 8 gig of RAM, with 6 gig of it allocated to the innodb block buffer pool (it caches row and index data so you don't have to go to disk).
Try doing that in Oracle 10g on Linux. The SGA (Shared Global Area) can't get larger than 1.7 gig unless you,
1) Use memory as a temporary file system so that Oracle can cache a bit more, and you also get the benefit of dicking around for several days, trying to configure your machine to try to take advantage of it (if it even can - we were never successful).
2) Remap all the shared libraries so that they load in a lower memory address, to squeeze another few hundred meg of memory.
Postgres (last I checked) preferred to let the OS do the data-caching. Thanks, but no thanks. And no 64-bit version (though I've read a few people have managed to compile one, I wouldn't trust it unless Postgres gave it the thumbs up).
MySQL with InnoDB is straighforward (it's use of tablespaces, replication, tuning, and even compiling from source - someone with mediocre Linux skills like myself can do it without issue every time).
MySQL with InnoDB is very fast, very reliable, and has awesome support via the MySQL mailing lists.
MySQL is very well documented, with lots of great third party books that don't cost an arm and a leg (unlike an Oracle library).
MySQL does not have stored procedures, triggers, and views in the current production version.
Here's what I think of that:
1) Triggers are hidden application logic that are very hard to debug, and are easily overlooked or forgotten by developers. Business logic (other than defensive logic like unique indexes, primary keys, foreign keys, not-null columns) does not belong in the database. They belong in the middle tier. They also make it much more difficult to move to another database.
2) Stored procedures are like PERL - it's very easy to make a mess unless you are very careful. They are also hidden logic, and very difficult to debug. And again, keep that logic out of the database. They also make it much more difficult to move to another database.
3) Views are a nice feature, but most often used to support business and reporting. I don't like managers connecting to the database to run queries (SELECT * FROM very_large_table_1, very_large_table_2; and suddenly you have cartesian join that results in tens of millions of rows coming back, bogging everything down). To do reports, views aren't necessary.
If you think MySQL is not a "real" database, it is, and has been since 4.0. As an Oracle (and now MySQL DBA), I can honestly say that I can't wait to dump Oracle and get the Boats.com website over to MySQL.
And for the few people who made comments like, "Do you really want your bank running on MySQL?": many banks run on old, legacy hardware and systems. Transactions are written out in many places (with geographic diversity) to ensure that a hardware or software crash is recoverable. There is no reason why you couldn't put MySQL in a situation like that, so long as the same precautions are taken.
Why would a non-expert on a topic write an whitepaper about it? Makes no sense... Sorry for being so picky, but I'm just a bit fed up with that kind of nonsense. Regardless of the intent, the result is malicious as such FUD on the net hangs around and is copied and quoted. Wouldn't you rather compete by focusing purely on the positive points that your own offering provides? Anyway, your image is yours to build or undermine. It's a choice. Space from deleted rows and old versions are automatically reused, no explicit maintenance is required for this. I don't know what that person was referring to; if he/she has a valid point, I'm sure they can be more specific about the matter.
You expect people to take your analyses seriously, but you don't feel like attempting to test...?. I suggest you leave serious comparison documentation to people who do feel like testing stuff. No offence intended.
-- Any sufficiently advanced technology is indistinguishable from a perl script.