mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-22 06:44:16 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Put back in comparison with PostgreSQL, design philosophy and features.

Browse source
This commit is contained in:
unknown 2001-12-13 10:49:32 +10:00
parent 927b452823
commit d7d140913d
1 changed files with 360 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

361
Docs/manual.texi
View file

@ -233,6 +233,7 @@ security bug in MySQL, you should send an e-mail to
* MySQL Information Sources:: MySQL Information Sources
* Compatibility:: How Standards-compatible Is MySQL?
* TODO:: MySQL and the future (The TODO)
* Comparisons:: How MySQL Compares to Other Open Source Databases
@end menu
@ -3634,7 +3635,7 @@ decimals.
For platform-specific bugs, see the sections about compiling and porting.
@node TODO, , Compatibility, Introduction
@node TODO, Comparisons, Compatibility, Introduction
@section MySQL and The Future (The TODO)
@cindex ToDo list for MySQL
@ -4111,6 +4112,364 @@ Nothing; We aim towards full ANSI 92 / ANSI 99 compliancy.
@end itemize
@node Comparisons, , TODO, Introduction
@section How MySQL Compares to Other Open Source Databases
@cindex databases, MySQL vs. others
@cindex comparisons, MySQL vs. others
Our users have successfully run their own benchmarks against a number
of @code{Open Source} and traditional database servers. We are aware of
tests against @code{Oracle}, @code{DB/2}, @code{Microsoft SQL Server}
and other commercial products. Due to legal reasons we are restricted
from publishing some of those benchmarks in our reference manual.
This section includes a comparison with @code{PostgreSQL} as it is
also an Open Source database. If you have benchmark results that we
can publish, please contact us at @email{benchmarks@@mysql.com}.
For comparative lists of all supported functions and types as well
as measured operational limits of many different database systems,
see the @code{crash-me} web page at
@uref{http://www.mysql.com/information/crash-me.php}.
@menu
* Compare PostgreSQL:: How MySQL Compares to PostgreSQL
@end menu
@node Compare PostgreSQL, , Comparisons, Comparisons
@subsection How MySQL Compares to PostgreSQL
@cindex PostgreSQL vs. MySQL, overview
When reading the following, please note that both products are continually
evolving. We at MySQL AB and the PostgreSQL developers are both working
on making our respective database as good as possible, so we are both a
serious alternative to any commercial database.
The following comparison is made by us at MySQL AB. We have tried to be
as accurate and fair as possible, but because while we know MySQL througly
we don't have a full knowledge of all PostgreSQL features, so we may have
got some things wrong. We will however correct these when they come to our
attention.
We would first like to note that PostgreSQL and MySQL are both widely used
products, but with different design goals, even if we are both striving
towards ANSI SQL compliancy. This means that for some applications MySQL
is more suited, while for others PostgreSQL is more suited. When choosing
which database to use, you should first check if the database's feature set
satisfies your application. If you need raw speed, MySQL is probably your
best choice. If you need some of the extra features that only PostgreSQL
can offer, you should use @code{PostgreSQL}.
@menu
* MySQL-PostgreSQL goals:: MySQL and PostgreSQL development strategies
* MySQL-PostgreSQL features:: Featurewise Comparison of MySQL and PostgreSQL
@end menu
@node MySQL-PostgreSQL goals, MySQL-PostgreSQL features, Compare PostgreSQL, Compare PostgreSQL
@subsubsection MySQL and PostgreSQL development strategies
@cindex PostgreSQL vs. MySQL, strategies
When adding things to MySQL we take pride to do an optimal, definite
solution. The code should be so good that we shouldn't have any need to
change it in the foreseeable future. We also do not like to sacrifice
speed for features but instead will do our utmost to find a solution
that will give maximal throughput. This means that development will take
a little longer, but the end result will be well worth this. This kind
of development is only possible because all server code are checked by
one of a few (currently two) persons before it's included in the
MySQL server.
We at MySQL AB believe in frequent releases to be able to push out new
features quickly to our users. Because of this we do a new small release
about every three weeks, and a major branch every year. All releases are
throughly tested with our testing tools on a lot of different platforms.
PostgreSQL is based on a kernel with lots of contributors. In this setup
it makes sense to prioritise adding a lot of new features, instead of
implementing them optimally, because one can always optimise things
later if there arises a need for this.
Another big difference between MySQL and PostgreSQL is that
nearly all of the code in the MySQL server are coded by developers that
are employed by MySQL AB and are still working on the server code. The
exceptions are the transaction engines, and the regexp library.
This is in sharp contrast to the PostgreSQL code where the majority of
the code is coded by a big group of people with different backgrounds.
It was only recently that the PostgreSQL developers announced that their
current developer group had finally had time to take a look at all
the code in the current PostgreSQL release.
Both of the above development methods have their own merits and drawbacks.
We here at MySQL AB think of course that our model is better because our
model gives better code consistency, more optimal and reusable code, and
in our opinion, fewer bugs. Because we are the authors of the MySQL server
code, we are better able to coordinate new features and releases.
@node MySQL-PostgreSQL features, , MySQL-PostgreSQL goals, Compare PostgreSQL
@subsubsection Featurewise Comparison of MySQL and PostgreSQL
@cindex PostgreSQL vs. MySQL, features
On the crash-me page
(@uref{http://www.mysql.com/information/crash-me.php})
you can find a list of those database constructs and limits that
one can detect automatically with a program. Note however that a lot of
the numerical limits may be changed with startup options for respective
database. The above web page is however extremely useful when you want to
ensure that your applications works with many different databases or
when you want to convert your application from one database to another.
MySQL offers the following advantages over PostgreSQL:
@itemize @bullet
@item
@code{MySQL} is generally much faster than PostgreSQL.
@item
MySQL has a much larger user base than PostgreSQL, therefore the
code is more tested and has historically proven more stable than
PostgreSQL. MySQL is the much more used in production
environments than PostgreSQL, mostly thanks to that MySQL AB,
formerly TCX DataKonsult AB, has provided top quality commercial support
for MySQL from the day it was released, whereas until recently
PostgreSQL was unsupported.
@item
MySQL works better on Windows than PostgreSQL does. MySQL runs as a
native Windows application (a service on NT/Win2000/WinXP), while
PostgreSQL is run under the @code{Cygwin} emulation. We have heard
that PostgreSQL is not yet that stable on Windows but we haven't
been able to verify this ourselves.
@item
MySQL has more APIs to other languages and is supported by more
existing programs than PostgreSQL. @xref{Contrib}.
@item
MySQL works on 24/7 heavy duty systems. In most circumstances
you never have to run any cleanups on MySQL. PostgreSQL doesn't
yet support 24/7 systems because you have to run @code{VACUUM()}
once in a while to reclaim space from @code{UPDATE} and @code{DELETE}
commands and to perform statistics analyses that are critical to get
good performance with PostgreSQL. @code{VACUUM()} is also needed after
adding a lot of new rows to a table. On a busy system with lots of changes,
@code{VACUUM()} must be run very frequently, in the worst cases even
many times a day. During the @code{VACUUM()} run, which may take hours
if the database is big, the database is from a production standpoint,
practically dead. The PostgreSQL team has fixing this on their TODO,
but we assume that this is not an easy thing to fix permanently.
@item
MySQL replication has been thoroughly tested, and is used by sites like:
@itemize @minus
@item Yahoo Finance (@uref{http://finance.yahoo.com/})
@item Mobile.de (@uref{http://www.mobile.de/})
@item Slashdot (@uref{http://www.slashdot.org/})
@end itemize
@item
Included in the MySQL distribution are two different testing suites,
@file{mysql-test-run} and crash-me
(@uref{http://www.mysql.com/information/crash-me.php}), as well
as a benchmark suite. The test system is actively updated with code to
test each new feature and almost all reproduceable bugs that have come to
our attention. We test MySQL with these on a lot of platforms before
every release. These tests are more sophisticated than anything we have
seen from PostgreSQL, and they ensures that the MySQL is kept to a high
standard.
@item
There are far more books in print about MySQL than about PostgreSQL.
O'Reilly, SAMS, Que, and New Riders are all major publishers with books
about MySQL. All MySQL features are also documented in the MySQL on-line
manual, because when a new feature is implemented, the MySQL developers
are required to document it before it's included in the source.
@item
MySQL supports more of the standard ODBC functions than @code{PostgreSQL}.
@item
MySQL has a much more sophisticated @code{ALTER TABLE}.
@item
MySQL has support for tables without transactions for applications that
need all speed they can get. The tables may be memory based, @code{HEAP}
tables or disk based @code{MyISAM}. @xref{Table types}.
@item
MySQL has support for two different table handlers that support
transactions, @code{InnoDB} and @code{BerkeleyDB}. Because every
transaction engine performs differently under different conditions, this
gives the application writer more options to find an optimal solution for
his or her setup, if need be per individual table. @xref{Table types}.
@item
@code{MERGE} tables gives you a unique way to instantly make a view over
a set of identical tables and use these as one. This is perfect for
systems where you have log files that you order for example by month.
@xref{MERGE}.
@item
The option to compress read-only tables, but still have direct access to
the rows in the table, gives you better performance by minimising disk
reads. This is very useful when you are archiving things.
@xref{myisampack}.
@item
MySQL has internal support for fulltext search. @xref{Fulltext Search}.
@item
You can access many databases from the same connection (depending of course
on your privileges).
@item
MySQL is coded from the start to be multi-threaded while PostgreSQL uses
processes. Context switching and access to common storage areas is much
faster between threads than between separate processes, this gives MySQL
a big speed advantage in multi-user applications and also makes it easier
for MySQL to take full advantage of symmetric multiprocessor (SMP) systems.
@item
MySQL has a much more sophisticated privilege system than PostgreSQL.
While PostgreSQL only supports @code{INSERT}, @code{SELECT}, and
@code{UPDATE/DELETE} grants per user on a database or a table, MySQL allows
you to define a full set of different privileges on database, table and
column level. MySQL also allows you to specify the privilege on host and
user combinations. @xref{GRANT}.
@item
MySQL supports a compressed client/server protocol which improves
performance over slow links.
@item
MySQL employs a ``table handler'' concept, and is the only relational
database we know of built around this concept. This allows different
low-level table types to be called from the SQL engine, and each table
type can be optimised for different performance characteristics.
@item
All MySQL table types (except @strong{InnoDB}) are implemented as files
(one table per file), which makes it really easy to backup, move, delete
and even symlink databases and tables, even when the server is down.
@item
Tools to repair and optimise @strong{MyISAM} tables (the most common
MySQL table type). A repair tool is only needed when a physical corruption
of a data file happens, usually from a hardware failure. It allows a
majority of the data to be recovered.
@item
Upgrading MySQL is painless. When you are upgrading MySQL, you don't need
to dump/restore your data, as you have to do with most PostgreSQL upgrades.
@end itemize
Drawbacks with MySQL compared to PostgreSQL:
@itemize @bullet
@item
The transaction support in MySQL is not yet as well tested as PostgreSQL's
system.
@item
Because MySQL uses threads, which are not yet flawless on many OSes, one
must either use binaries from @uref{http://www.mysql.com/downloads/}, or
carefully follow our instructions on
@uref{http://www.mysql.com/doc/I/n/Installing_source.html} to get an
optimal binary that works in all cases.
@item
Table locking, as used by the non-transactional @code{MyISAM} tables, is
in many cases faster than page locks, row locks or versioning. The
drawback however is that if one doesn't take into account how table
locks work, a single long-running query can block a table for updates
for a long time. This can usually be avoided when designing the
application. If not, one can always switch the trouble table to use one
of the transactional table types. @xref{Table locking}.
@item
With UDF (user defined functions) one can extend MySQL with both normal
SQL functions and aggregates, but this is not yet as easy or as flexible
as in PostgreSQL. @xref{Adding functions}.
@item
Updates that run over multiple tables is harder to do in MySQL.
This will, however, be fixed in MySQL 4.0 with multi-table @code{UPDATE}
and in MySQL 4.1 with subselects.
In MySQL 4.0 one can use multi-table deletes to delete from many tables
at the same time. @xref{DELETE}.
@end itemize
PostgreSQL currently offers the following advantages over MySQL:
Note that because we know the MySQL road map, we have included in the
following table the version when MySQL should support this feature.
Unfortunately we couldn't do this for previous comparison, because we
don't know the PostgreSQL roadmap.
@multitable @columnfractions .70 .30
@item @strong{Feature} @tab @strong{MySQL version}
@item Subselects @tab 4.1
@item Foreign keys @tab 4.0 and 4.1
@item Views @tab 4.2
@item Stored procedures @tab 4.1
@item Extensible type system @tab Not planned
@item Unions @tab 4.0
@item Full join @tab 4.0 or 4.1
@item Triggers @tab 4.1
@item Constraints @tab 4.1
@item Cursors @tab 4.1 or 4.2
@item Extensible index types like R-trees @tab R-trees are planned for 4.2
@item Inherited tables @tab Not planned
@end multitable
Other reasons someone may consider for using PostgreSQL:
@itemize @bullet
@item
Standard usage in PostgreSQL is closer to ANSI SQL in some cases.
@item
One can speed up PostgreSQL by coding things as stored procedures.
@item
For geographical data, R-TREES makes PostgreSQL better than MySQL.
@item
The PostgreSQL optimiser can do some optimisation that the current MySQL
optimiser can't do. Most notable is doing joins when you don't have the
proper keys in place and doing a join where you are using different keys
combined with OR. The MySQL benchmark suite at
@uref{http://www.mysql.com/information/benchmarks.html} shows you what
kind of constructs you should watch out for when using different
databases.
@item
PostgreSQL has a bigger team of developers that contribute to the server.
@end itemize
Drawbacks with PostgreSQL compared to MySQL:
@itemize @bullet
@item
@code{VACUUM()} makes PostgreSQL hard to use in a 24/7 environment.
@item
Only transactional tables.
@item
Much slower @code{INSERT}, @code{DELETE}, and @code{UPDATE}.
@end itemize
For a complete list of drawbacks, you should also examine the first table
in this section.
@node Installing, Tutorial, Introduction, Top
@chapter MySQL Installation