Christian Smith wrote:
On Tue, 6 Dec 2005, John Stanton wrote:
Christian Smith wrote:
On Fri, 2 Dec 2005, C C wrote:
Basically, it'd be too complex (IMHO) to implement in a 'lite' database
engine.
The virtue of MVCC is that it does not use locking, instead it maintains
serialized versions of the data.
The btree must still be accessed and updated in a serialized fashion to
prevent corruption. MVCC removes the need for locks on whole databases,
tables or rows. But the metadata still requires locks for updating.
It is these metadata updates that would slow down throughput that a
centralized db doesn't suffer from. The centralized db can use regular
locking primitives to coordinate metadata updates (such as mutexes and
condition variables.) SQLite does not have that option except within a
single process.
The whole point of the "lite" in
Sqlite is that it does not use those heavyweight DBMS methods which make
a DBMS capable of handling thousands of concurrent transactions.
Agreed.
The massive overhead of MVCC is pointless when the DBMS is in a small
scale application with at most a handful of concurrent transactions.
Sqlite's locking method is quite appropriate at that level.
Having never implemented a MVCC database (nor any database, for that
matter:) I couldn't authoritively comment, but MVCC doesn't strike me as
being particularly high overhead. A couple of extra hidden columns per
row, tracking transaction id's and the odd vacuum every now and then. What
could be simpler:) Certainly not massive overhead, and probably easier
than table or row level locking (think deadlocks.)
JS
Christian
What could be simpler? Implementing transactional integrity by means of
locks rather than multiple versions of data and complex housekeeping,
particularly if the intended application doesn't depend upon MVCC for
performance with a large number of concurrent users. Dr Hipp is very
clear in advising not to use Sqlite for enterprise applications.
If you follow this mail list you will see that Sqlite is in some ways
too "heavy" for some of the embedded applications where it is used.
Options to create an "Sqfeatherlite" would be more useful than
attempting to create yet another general purpose, full function RDBMS.
