Slashdot Mirror
MySQL 4 Declared Production-Ready
Simprini writes "After absolute ages of testing MySQL 4.0.x in various versions of BETA through GAMMA it looks like MySQL AB finally released MySQL 4.0.12 as ready for prime-time production use. I know my company has been waiting for a long time for this because our customers absolutely refused to use beta releases of this product. Query caching here we come."
Does MySQL still do table-level locks and no foreign keys? If so, I'll stick to using a real database.
Having had experience with Oracle, MySQL is still lacking a lot of the plush features that Oracle has. But, having run it for about 3+ years on my own slash type sites, the thing is ROCK solid. The feature set in MySQL increases with every version.
Now, look at the costs. Oracle - an Arm, leg, and your children. MySQL - Free. Gee, that is a no brainer.....
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
soloris and linux average 6-8 megs?
We are also using MySQL for many web projects, but to create a complex CMS the future features in MySQL (that also exist in other current database systems - like postgreSQL and probably others) are needed.
We have initially created Komplete - http://komplete.interakt.ro/ only for PostgreSQL, and our users attitude indicated us that MySQL should have been supported. So we are releasing now the Komplete Lite version (GPL), for MySQL - but it's a real pain to simulate subselects, real unions (emulated with temporary tables now), cascaded deletes and stored procedures.
The speed is quite similar, but PostgreSQL is still much better for complex web applications.
I work at at the tech development dept. of a major car company and this is great news. We are finally able to throw MySQL onto production servers and give Oracle the boot for small RAD webapps.
What I've heard from MySQL officials in person is that MySQL 5.0 is set to be released late Q4 this year. Then stored procedures, sub selects (4.1) and constraints should be ready for primetime, then we talk real heavy enterprise applications. Hope they keep the schedule! =)
Well, Monty and the rest, Good Job! Keep it up!
Girls are strange. They don't come with a man page.
-- Michael Mattsson
Foreign keys -- Pass
Replication -- Pass
Triggers -- FAIL
SO close.....
Software Wars
IMO, the very best new feature of MySQL 4 is multi-table deletes. No more having to query/for each in/delete type constructs across many-to-many relationship tables.
I've been using MySQL 4.0.5/PHP4 on RH8.0 without problems to date. Granted, only on a non-critical intranet for our small (70) office, but still, no problems.
There is no need to use a SlashDot sig for SEO...
What about integrity constraints, foreign keys, interval datatypes, full outer joins, subqueries, set operations, VIEWS for god's sake, and triggers? Too hard?
For cryin' out loud, half of these missing features put the "relational" in "relational database"!
any word on whether we have subselects yet. I couldnt see it in the change log. They are dearly missed..
The war with islam is a war on the beast
The war on terror is a war for peace
I am wondering about caparative processing speed myself. MySQL has always been the speed leader in Open Source databases. Now that they have added some industrial strenght features (like ACID compliant transactions and row level locking) via InnoDB, how well does the speed difference hold up? Is it still way faster, or just a little faster or not faster at all?
If the difference isn't significant then there is no reason to choose MySQL over PostreSQL for applications requiring high levels of data integrity. Especially when PostreSQL also brings you stored procedures, views and so on.
- -
Are you an SF Fan? Are you a Tru-Fan?
But of course it's probably just another thing mysqlers will claim that "90% of people would never use anyhow". Well, 100% of mysqler's, anyhow.
They don't know what they're missing.
What about integrity constraints, foreign keys, interval datatypes, full outer joins, subqueries, set operations, VIEWS for god's sake, and triggers? Too hard?
For cryin' out loud, half of these missing features put the "relational" in "relational database"!
First of all, kudos to the MySQL team for atleast getting as far as they have. Just because I'm not fond of thier product, doesn't mean they don't deserve credit.
I've been banging my head a little on this one too trying to figure out why so many people are pushing MySQL and not something stable and complete like PostgreSQL? After all, PostgreSQL has triggers, stored-procedures, functions, referential integrity, and tons of other features to make your life easier. You may not need all of these features now, but can you honestly say your app won't expand and require advanced features?
Is it the MySQL marketing engine? Does PostgreSQL sound intimidating? Are there actually technical advantages that MySQL have over PostgreSQL? If so, what are they?
The most common argument I've heard in defense of MySQLs lack of basic features is: "It's good enough for 90% of the problems out there." However, everytime they implement a basic feature that every other RDBMS has had for decades (like UNION), people respond as if MySQL is getting close to be taken seriously.
Secondly, In my experience, I've found that 90% of the applications I've worked on end up using those advanced features sooner or later. Those features usually save a tremendous amount of time I would have otherwise had to spend writing code to make my database jump through hoops. In addition to saving time, there a lot of features which simply allow me to make my applications more useful or intuitive to the end user, which is the whole point.
Am I missing something here, or is the Emperor not wearing any clothes?
"Communism is like having one [local] phone company " - Lenny Bruce
I don't mean to start a flame war here, but I have to ask... Why is MySQL so popular when PostgreSQL does more and is also open source and free like beer? Are there any real benefits to MySQL over PostgreSQL?
MySQL is developed mainly under Solaris and is known to work best there. Threaded performance under Solaris is said to be way better than under Linux.
This may of course not apply to your version of Solaris...but I can't make any qualified comments on this, really, as I have never even seen Solaris from up close.
I thought it was strange that the story submitter said, "I know my company has been waiting for a long time for this because our customers absolutely refused to use beta releases of this product." It's as if he's surprised that customers don't have the same standards as his personal linux box. Sure, they released a new tiny rev today, let's compile it and put it into production!
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
I've been extensively using MySQL 4 for over one year on very loaded production systems.
.
It has actually always been faster and more solid than the 3.23.x series.
I only had some small issues with InnoDB (the same issues were in 3.23.x as well). But the InnoDB maintainer, Heiki Turri, is someone that really cares about bug reports. All reported bugs were immediately fixed.
The query cache is efficient, and the fulltext indexing was greatly enhanced (if only it worked with InnoDB tables...)
I've not installed any 3.23.x version for a while, and I'll never go back.
Probably a lot of system administrators will wait. They will read that MySQL AB blessed 4.x as production-ready, but they will wait, as if it was an 1.0 version that still needs some maturity.
It's not. MySQL 4.x has already received a lot of testing, and it is already being used on large production sites. Just read the MySQL mailing-lists.
Upgrading from MySQL 3.x is also easy. You only need to run a little script to upgrade the grant tables (and even if you don't, everything will work). No need to export/reimport the databases. So upgrading is straight forward.
{{.sig}}
Maybe PostgreSQL justs a name change and a new PR department. Many people don't even know how to pronounce PostgreSQL. Consider the name's awkward evolution: Ingres --> Postgres --> PostgreSQL. They've already got a decent logo (the blue elephant). Presumably, the elephant never forgets your data?
Looks like the PostgreSQL team is taking an active role to update their PR: A Call for PostgreSQL Case Study Participants
cpeterso
Very interesting indeed!
It would be great if you could provide a bit more detail so others won't accuse you of configuring Linux/MySQL to perform at a crawl.
What exactly is the non-Windows OS are you dual-booting to? Assuming a Linux distro, what version of the kernel? What version of gcc was used and with which optimization settings? How large is your swap file & what file system did you use on that and on the other partitions? What are the optional file system options you're using?
Also, its possible that having compression enabled on the Win2k/XP could impact performance (especially on very fast processors). Also, the way the OS had cached some of the disk to memory can hugely impact performance--in other words, there are factors other than database itself that could heavily impact the benchmark results.
BTW, I'm not a MySQL fan. I happen to prefer PostgreSQL 7. Its just that I've seen other benchmarks comparing databases without considering relevant factors (which led to skewed results in favor of MySQL over PostgreSQL especially when PostgreSQL was running with default conservative performance/reliability settings).
I question the relevance of index creation benchmark. In most cases, index creation is done once and then it all just works with that index. Could you provide benchmarks for some big multitable select, update and calculations (averages, sums and that stuff)?
Same goes for unindexed select: avoid it, and give us indexed benchmarks.
zm
Sig ?
We run postgres and we're doing our damndest to get rid of it. We have some databases that get 50-100% data turnover rate daily, making hourly vacuums essential to not having the Ever Expanding Database problem. Not to mention that vacuum doesn't clean up indexes, so you'll also have to re-index periodically if you don't want those to grow to thousands of times their optimal size.
I should probably say that such reindexes require full table locks, so you could get contention issues under heavy load when reindexing your database. Mysql gets by this by making indexes in a temporary space, and switching when the index is done. This means I can select from a table, with full benefit of an existing index, even while I change an index, or even redo the index. Not that I have to... mysql doesn't require vacuum or reindex to avoid continuous linear bloat.
So... we don't like having to babysit our database to get good performance out of it. We're willing to work around lack of foreign keys to avoid having to do full database import/exports on a weekly basis, and multiple hourly cron jobs to make sure we don't randomly fill our disks. Faster? Slower? Who cares. Postgres is just too annoying to use in production.
Read: Rabbit Rue - Free serial nove
When I design a view in MSSQL, I can copy and paste the query in my code and use it. That is exactly what I always do. MySQL supports joins correct, so it it just that you cannot save the view that makes so many get their panties in a bunch? Can't these people just write the query? If you need it stored bad enough, can't you just write a function to call your 'view' sql query?
What?
3 = make the JDBC drivers GPLed to make developpers so confused about the differences between LGPL and GPL applied to Java code (there is no difference between static and dynamic linking in Java) that they have to buy a non-GPL version of the driver just to make sure they don't violate the GPL
to possibly replace some Oracle databases.
Any gurus (or detractors) want to list the downsides?
- no subqueries yet. Ok. Not the end of the world
- are multi-column primary keys still a performance dog?
- how is stability? That's probably what you hear most about w/regards to MySQL
- triggers and stored procs; back-end-logic==bad IMHO
I just ordered Mastering MySQL 4 to speed the jump between Oracle and MySQL. Anyone used that book?
I'd be really interested in hearing some frank and honest appraisals.
Can you explain, in layman's terms, what a "real relational database" actually is? And why MySQL isn't one, and what it would have to do to be one? And NOT by saying "well, it's got to have wvcsde and werdfskfk!" I mean, I don't know too much, but people have got to be able to explain these operations, and the theories behind the data structure, in better ways than most people here are doing, reffering to various features. Not all of us here are geniuses, or work with databases regularly. :)
But instead, there's stupid recurring garbage with idiots on both sides trying to explain that one database is better than another. Here's what I think the objective truth is - the fact of the matter is whatever works for you is fine.
If you like using stored procedures, triggers and constraints and think SQL compliance is important, then use Postgresql, and it will work fine for you. If you don't, and you like fast access to your data, use MySQL.
There are use scenarios that one can construct which will make either database look completely ridiculous and terrible (look at some of the comments for some examples). But it doesn't matter, if you can code for MySQL and think in MySQL, it will work fine. If you code for Postgresql and think in Postgresql, it will work fine. I've used both, in heavy and light production environments, and they both have their uses. I've also found scenarios where I can't use either, and have to go to something else.
To all those who say, "But...but...MySQL is just a fake SQL interface to the filesystem!" Well, fine. Where do you store your files, then? I presume, since a filesystem is such a terrible place to put your files, that it's not in a filesystem, eh?
And to those who say, "but, I can SELECT out of MySQL eight hundred bajillion times faster than Postgresql!" Well, fine, but what happens if you try to concurrently insert something? How's your data integrity hold up if some errant SQL inserts data that doesn't refer properly to other tables?
What I'm trying to say is that it's all relative, and trying to phrase things as, "This is the right thing to do, in all cases, for all scenarios" is narrow-minded and simplistic. Use what works for you - and note that a lot of this depends on how you think when you are writing your code. So two different programmers working on the same problem might solve the problem using different databases - and both be right.