The benchmark you are refering to can't be repeated, was not open source and was very likely wrongly conducted.
You can find some comments about this at:
http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_benc hmarks.html
There are also some open source (repeatable) benchmark results at:
http://www.mysql.com/information/benchmarks.html and
http://acidlab.sourceforge.net/perf/acid_perf.html
That tells a completely different story.
The author apparently misinterpreted Marten Mickos statement. (That's
the problem with news stories that you are not allow to check before they are published).
The OpenSSL toolkit is licensed under a Apache-style licence which basically means that you are free to get and use it for commercial and non-commercial purposes.
One can use OpenSSL with GPL code without any problems.
MyISAM tables are not good in an environment where you are doing a lot of long running updates and selects on the same tables.
InnoDB tables doesn't however have this problem.
The benchmarks on the www.mysql.com page are still single users, but we are working on an open source multi user tests that will show how the different table handlers MySQL provides works under heavy multi-user load.
The single user benchmarks does however show the top speed for a database and the strength and weakness for each database, so they are still very useful on their own.
Regards,
Monty
PS: I agree that the benchmarks on the InnoDB web page are far from perfect.
Hi!
I agree that PostgreSQL has some fetatures that MySQL also has, but it's also true that MySQL has a lot of features that PostgreSQL doesn't have.
To not have to repeat myself over and over again, I have collected some information about this topic here
Speedwise I haven't seen any indication that PostgreSQL 7.1 would generally be faster than MySQL. All the tests I have myself run shows that it there is no big speed improvment between earlier PostgreSQL version and 7.1, if you run both with flushing of data disabled. (We will soon publish the results on our benchmark page)
For many applications, MySQL is in practice at least 3 times faster than PostgreSQL 7.1. If you applications needs the extra speed MySQL can give, PostgreSQL is not an option.
According to what I know, the InnoDB transaction handling engine in MySQL is
at least as good as the PostgreSQL transaction engine. (I would argue that is even better, as you never have to run a 'vacuum' on InnoDB!)
My simple message is that both MySQL and PostgreSQL has a place. One
can't generally say which is better, in the same way you can't say if
a hammer or a screw driver is the right tool, if you don't know what
it should be used for. For a lot of real world applications, MySQL is
simple the best choice. The same is true for PostgreSQL.
Hi!
I just wanted to point out a couple of simple faults in your posting
as a lot of your statements are based on beliefs, not facts. It's
always a good policy to check things up before starting to comment
on them
MySQL uses threads instead of processes, which are more scalable
when you have many connections.
We have users that runs one MySQL server with 2000 simultaneous
connections doing 400 queries per second. I think these numbers
speaks for themself.
MySQL's default table type MyISAM can mix inserts/selects without
locking problems.
With InnoDB tables in MySQL you get all the benefits you have with
the transaction safe tables in PostgreSQL, but without ever have to
run vacuum. InnoDB is a new addition to MySQL, but on the other
hand so is MVCC to PostgreSQL.
When it comes to queries, MySQL is usually 2-5 times faster
than PostgreSQL, with speed differences up to 100 times.
The important thing here is not which database is better, but when it's better. No database can
be good for everything and if anyone is claiming this, he doesn't
know what he is speaking about.
In comparison to ANY benchmark that I have seen posted for
PostgreSQL, the MySQL benchmark has been published in source
with an exact description of how to repeat the results.
It's true that the benchmarks on the MySQL web site doesn't cover
any tests with concurrent users, but this is something that we are
working on; It's not trivial to write a fair multi-user benchmark
that everyone can agree on and we have simple not have anyone
that has had time to do this. We did however just employ a person
to start working on this so things will change in the near future.
You can find a comparison between MySQL and PostgreSQL seen from
the other side at:
comparison
MySQL does have a completely different way to
make releases than PostgreSQL, so it no completely
fair to just compare a PostgreSQL 7.0 with
MySQL 3.22, even if MySQL 3.23 is marked as beta.
The reason is that if PostgreSQL would
follow the same release mechanism as MySQL, where there is one month without nothing but bug fixes between -alpha, -beta and -gamma releases, PostgreSQL 7.0 would still be marked -alpha.
I just wanted to clarify the above comment a little to avoid some common misunderstandings:
Older MySQL versions are released under the GPL license and this effectively makes MySQL open source. Newer MySQL versions, even if its available in source and free for most usage, are not compliant with the Open Source definition. We, the MySQL developers, wanted to have a license that would give us the same commercial benefits the GPL gives to a library, Unfortunately, there is no such license for client/server programs. We did the next best thing and let the MySQL Unix version be free as long as the media it is distributed on is redistributeable. All in-house, including commercial, usage is free. We don't mind if people say that we are not strictly open source, but we would appreciate if the people that criticize the current license would at least agree that we have a very decent license that is very close to the open source spirit.
The intention of our license is to ensure that we can have a group of developers spend full time improving MySQL and also give free support on our mailing lists without having to compromise our development time with work on the side on other projects (Note that the money we get for MySQL licenses and support is the only funding we have for this!)
MySQL doesn't support SELECT INTO... as this is not ANSI SQL. MySQL support however the ANSI SQL way to do the same thing: INSERT INTO... SELECT.
If the character column is defined as binary all LIKE operation on it will be case sensitive. In SQL, the speed overhead of doing a case sensitive compare is neglectable compared to fetching the data from the database. You can easily verify this by doing a LIKE search with and without BINARY.
To force -- to be followed by a white space was done to remove a lot of possible problems. As many SQL databases doesn't even support -- this isn't normally a big problem:)
As you may have noted on the MySQL crash-me page, most SQL databases are incompatible with eachother. If you are worried about incompatibles, you should never use Oracle (Oracle is big enough to have it own SQL standard).
I think my daughter, who is named My, and a lot of girls here in Scandinavia would be pretty upset if we forced them to change their names to 'Ours':) 'My' happens to be a common girls name in Scandinavia.
I just wanted to point at that you don't have any substantial proofs that one can't implement a large scale manufacturer system in PHP and MySQL.
The main reason MySQL was developed was that the common big databases couldn't handle big database system in a fast, efficient way. The core part of MySQL has been running in a big scale systems since 1985. We do infact since 10 years back run realtime datawarehousing on card transactions some of the largest corporations in Sweden with MySQL and perl and I can't see any reason why we couldn't substitute perl for PHP.
There is nothing in the MySQL or PHP model that talks against it, and a lot of things that talks for it. The free model of these products + the availability of source code makes these products much more suitable to build large scale applications than with systems for which you can't get access to the source. I don't know how many project we have had to abound just because of small bugs in products that we couldn't fix ourselves! It's a shame to have to spend a lot of money on a expensive commercial product just to in the final stage notice that it will not solve your original problem because it lacks some critical feature or is just not fast enough.
It seams that you have the illusion that a systems has to be around for many years to be usable. Even if Oracle has been around for Solaris for a long time, there is still problems in the implementation of Oracle that makes it unsuitable for projects that require really high throughput. I agree that Linux and SMP could be better, but we have now used Linux 2.2 since it come out and the SMP performance is generally excellent and we haven't had any problems with it!
We have previously been using Sun Sparc machines as our product machines, but lately we have been shifting to Linux just because we can get better SMP performance on them for a fraction of the money a Sun machine would cost us!
I don't know about your software and how it would work with MySQL on PHP, but if it wouldn't, this would only mean that you haven't designed it with MySQL and PHP in mind! In particular with MySQL you may have to do some extra work if your old design requires transactions from the start, but the speed benefit you get is usually worth it!
PHP is growing faster (both in users and features) than any other scripting language on the web and the main reason for this is that you can developer faster and better web applications in it than in any other language (except possible perl). I agree that a web interface is not always the best interface for an application, but if you are going to use the application over the web, then PHP is definitely one of the strong actors in this!
Slashdot Mirror
The benchmark you are refering to can't be repeated, was not open source and was very likely wrongly conducted.
c hmarks.html
l
That tells a completely different story.
You can find some comments about this at:
http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_ben
There are also some open source (repeatable) benchmark results at:
http://www.mysql.com/information/benchmarks.html
and
http://acidlab.sourceforge.net/perf/acid_perf.htm
The author apparently misinterpreted Marten Mickos statement. (That's
the problem with news stories that you are not allow to check before they are published).
You will find a lot of good GPL information at:
http://www.gnu.org/copyleft/gpl-faq.html
Regards,
Monty
There is no problem with the OpenSSL license.
From the RPM description:
The OpenSSL toolkit is licensed under a Apache-style licence which basically means that you are free to get and use it for commercial and non-commercial purposes.
One can use OpenSSL with GPL code without any problems.
Regards,
Monty
MyISAM tables are not good in an environment where you are doing a lot of long running updates and selects on the same tables.
InnoDB tables doesn't however have this problem.
The benchmarks on the www.mysql.com page are still single users, but we are working on an open source multi user tests that will show how the different table handlers MySQL provides works under heavy multi-user load.
The single user benchmarks does however show the top speed for a database and the strength and weakness for each database, so they are still very useful on their own.
Regards,
Monty
PS: I agree that the benchmarks on the InnoDB web page are far from perfect.
Both MySQL and PostgreSQL has a multi-versioning transaction engines.
Regards,
Monty
Hi! I agree that PostgreSQL has some fetatures that MySQL also has, but it's also true that MySQL has a lot of features that PostgreSQL doesn't have.
To not have to repeat myself over and over again, I have collected some information about this topic here
Speedwise I haven't seen any indication that PostgreSQL 7.1 would generally be faster than MySQL. All the tests I have myself run shows that it there is no big speed improvment between earlier PostgreSQL version and 7.1, if you run both with flushing of data disabled. (We will soon publish the results on our benchmark page)
For many applications, MySQL is in practice at least 3 times faster than PostgreSQL 7.1. If you applications needs the extra speed MySQL can give, PostgreSQL is not an option.
According to what I know, the InnoDB transaction handling engine in MySQL is at least as good as the PostgreSQL transaction engine. (I would argue that is even better, as you never have to run a 'vacuum' on InnoDB!)
My simple message is that both MySQL and PostgreSQL has a place. One can't generally say which is better, in the same way you can't say if a hammer or a screw driver is the right tool, if you don't know what it should be used for. For a lot of real world applications, MySQL is simple the best choice. The same is true for PostgreSQL.
Regards, Monty
CTO of MySQL AB
MySQL has had transactions and locking for a long time already.
The reason we have left subqueries out until now has mainly been that MySQL users have had higher demands for other features than these.
Regards,
Monty
Just a note about this: If you are using InnoDB, you will get foreign key support in MySQL 3.23.44 and 4.0.1.
For other table types, we will add full foreign key support for 4.1.
People that find cascaded delete very useful, will proably also like the new multi-table delete feature we arlready have in MySQL 4.0
Regards,
Monty
I just wanted to point out a couple of simple faults in your posting as a lot of your statements are based on beliefs, not facts. It's always a good policy to check things up before starting to comment on them
The important thing here is not which database is better, but when it's better. No database can be good for everything and if anyone is claiming this, he doesn't know what he is speaking about.
Monty
CTO of MySQL AB
MySQL does have a completely different way to make releases than PostgreSQL, so it no completely fair to just compare a PostgreSQL 7.0 with MySQL 3.22, even if MySQL 3.23 is marked as beta. The reason is that if PostgreSQL would follow the same release mechanism as MySQL, where there is one month without nothing but bug fixes between -alpha, -beta and -gamma releases, PostgreSQL 7.0 would still be marked -alpha.
I just wanted to clarify the above comment a little to avoid some common misunderstandings:
Older MySQL versions are released under the GPL license and this effectively makes MySQL open source. Newer MySQL versions, even if its available in source and free for most usage, are not compliant with the Open Source definition. We, the MySQL developers, wanted to have a license that would give us the same commercial benefits the GPL gives to a library, Unfortunately, there is no such license for client/server programs. We did the next best thing and let the MySQL Unix version be free as long as the media it is distributed on is redistributeable. All in-house, including commercial, usage is free. We don't mind if people say that we are not strictly open source, but we would appreciate if the people that criticize the current license would at least agree that we have a very decent license that is very close to the open source spirit.
The intention of our license is to ensure that we can have a group of developers spend full time improving MySQL and also give free support on our mailing lists without having to compromise our development time with work on the side on other projects (Note that the money we get for MySQL licenses and support is the only funding we have for this!)
Hi!
... as this is not ANSI SQL. MySQL support however the ANSI SQL way to do the same thing: INSERT INTO ... SELECT.
:)
Just for your information:
MySQL doesn't support SELECT INTO
If the character column is defined as binary all LIKE operation on it will be case sensitive. In SQL, the speed overhead of doing a case sensitive compare is neglectable compared to fetching the data from the database. You can easily verify this by doing a LIKE search with and without BINARY.
To force -- to be followed by a white space was done to remove a lot of possible problems. As many SQL databases doesn't even support -- this isn't normally a big problem
As you may have noted on the MySQL crash-me page, most SQL databases are incompatible with eachother. If you are worried about incompatibles, you should never use Oracle (Oracle is big enough to have it own SQL standard).
I think my daughter, who is named My, and a lot of girls here in Scandinavia would be pretty upset if we forced them to change their names to 'Ours' :) 'My' happens to be a common girls name in Scandinavia.
Hi!
I just wanted to point at that you don't have any substantial proofs that one can't implement a large scale manufacturer system in PHP and MySQL.
The main reason MySQL was developed was that the common big databases couldn't handle big database system in a fast, efficient way. The core part of MySQL has been running in a big scale systems since 1985. We do infact since 10 years back run realtime datawarehousing on card transactions some of the largest corporations in Sweden with MySQL and perl and I can't see any reason why we couldn't substitute perl for PHP.
There is nothing in the MySQL or PHP model that talks against it, and a lot of things that talks for it. The free model of these products + the availability of source code makes these products much more suitable to build large scale applications than with systems for which you can't get access to the source. I don't know how many project we have had to abound just because of small bugs in products that we couldn't fix ourselves! It's a shame to have to spend a lot of money on a expensive commercial product just to in the final stage notice that it will not solve your original problem because it lacks some critical feature or is just not fast enough.
It seams that you have the illusion that a systems has to be around for many years to be usable. Even if Oracle has been around for Solaris for a long time, there is still problems in the implementation of Oracle that makes it unsuitable for projects that require really high throughput. I agree that Linux and SMP could be better, but we have now used Linux 2.2 since it come out and the SMP performance is generally excellent and we haven't had any problems with it!
We have previously been using Sun Sparc machines as our product machines, but lately we have been shifting to Linux just because we can get better SMP performance on them for a fraction of the money a Sun machine would cost us!
I don't know about your software and how it would work with MySQL on PHP, but if it wouldn't, this would only mean that you haven't designed it with MySQL and PHP in mind! In particular with MySQL you may have to do some extra work if your old design requires transactions from the start, but the speed benefit you get is usually worth it!
PHP is growing faster (both in users and features) than any other scripting language on the web and the main reason for this is that you can developer faster and better web applications in it than in any other language (except possible perl). I agree that a web interface is not always the best interface for an application, but if you are going to use the application over the web, then PHP is definitely one of the strong actors in this!
Regards,
Monty