The
primary advantage that MVCC has over locking is that MVCC does not block readers.
Since all update transactions are applied atomically, the database is always in a consistent
state. Pending transactions are stored as logs alongside the database to be written
upon commit, rather than being applied to the database in the middle of the transaction.
The most significant consequence of this is that reads never block, since they are
read from the database, which is always consistent.
It is important to realize that isolation for concurrent transactions usually trades off
against performance. MVCC uses more storage space than locking because it has to
store a snapshot for each in-progress transaction. And though MVCC never blocks
reads, the DBMS may roll back update transactions if they cause a conflict.
Database Management Systems | 99
to need it.??? Even transactions are not supported with the default storage engine
(MyISAM) to this day. In versions prior to 5.0, there were many bugs that would
silently discard incorrect data rather than raising an error. To be fair, new versions of
MySQL are addressing a lot of its issues. I would still recommend PostgreSQL as a
general rule where speed is not the primary criterion, since it has had enterprise-level
features for much longer. If you use MySQL, take these recommendations:
??? Use version 5.0 or later. Many of the issues that existed with previous versions
have been fixed or improved in 5.
Pages:
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155